Problema con Browse, cláusula ON CHANGE

[triumvirato]

Tengo definido un browse con su cláusula ON CHANGE, que retroalimenta varios objetos SAY. Cuando el browse toma el foco, no ejecuta la primera vez dicha cláusula ON CHANGE (como entiendo es lógico), por lo que me veo obligado a, o bien repetir las mismas líneas de código cuando toma el foco y en la cláusula ON CHANGE, o bien asignar el mismo bloque de código a la data bGotFocus.

Alguien tiene idea de como hacer esto, para que cuando el browse tome el foco evalúe la cláusula ON CHANGE? Alguna otra sugerencia de como hacerlo más elegante?
Ahora lo tengo del siguiente modo:

Code: Select all  Expand view

    REDEFINE LISTBOX oBrowPed;
             FIELDS ....;
             HEADERS ...;
             COLSIZES ...;
             ID 90 OF oDlg_GenAut ALIAS "pedido" UPDATE;
             ON CHANGE (  oSayPenSer:SetText( Ala->Ala_pes ),;
                                   oSayPenRec:SetText( Ala->Ala_Per ) )                      

    oBrowPed:bGotFocus := oBrowPed:bChange
 

Muchas gracias.

[Raymundo Islas M.]

triumvirato,

Ya probaste :

Code: Select all  Expand view

oBrowPed:bGotFocus := { || eval( oBrowPed:bchange ) }

Acabo de apagar mi pc de desarrollo, asi que no puedo checar bien la sintaxis, pero creo te debe funcionar.


Saludos

[triumvirato]

Raymundo,

Muchas gracias, efectivamente funciona correctamente y más "elegante" por decirlo de algún modo.

Gracias.

[andresreyes_mzt]

triumvirato,

No se en realidad a que te refieras con "ELEGANTE"

Code: Select all  Expand view

oBrowPed:bGotFocus := oBrowPed:bChange
 

La forma como resuelves el problema que te planteas con este código, es perfectamente correcta y entendible

Code: Select all  Expand view

oBrowPed:bGotFocus := { || eval( oBrowPed:bchange ) }
 

Pero lo que si te puedo decir de esta código, es que es totalmente una pésima practica de programación, te lo voy a explicar de la siguiente manera, al utilizar la segunda opción lo que estas haciendo simplemente es crear un bloque de código que evaluara un segundo bloque de código ... Lo único que estas haciendo con esto primero ... es usar mas recursos al crear un bloque de código innecesario ... y segundo ... perdiendo unas milésimas de segundo en la velocidad de tu programa ... ya que la función EVAL ... es llamada 2 veces al ejecutar el Bloque de código oBrowPed:bGosFocus y todo por crear un bloque de código innecesario.

Un consejo como programador. Deberías poner una poco mas atención en optimizar el código que el hacerlo mas "ELEGANTE".

Saludos,

Andres Reyes

[triumvirato]

Andrés,

Con elegante, me refiero a: entendible, "limpio" y por supuesto OPTIMIZADO, como bien sugieres con razón. En este caso para mí lo elegante es que el Browse por sí mismo, la primera vez que toma el foco, evaluase el ON CHANGE, sin tener que hacer estos "apaños".
La decisión de adoptar esa otra alternativa frente a la mía, es por el simple motivo de que permite ampliar con más acciones el bGotfocus. Me permite hacer esto que me es también necesario:

Code: Select all  Expand view

oBrowPed:bGotFocus := { || eval( oBrowPed:bchange ), MsgInfo( "Actulizado" ), oBtnActCms:Enable() }
 

... Que sinceramente, soy novato en Fivewin, no veía manera mejor de hacerlo con el método que yo proponía. Seguramente existan muchas más alternativas, unas más optimizadas, otras menos y unas resolverán un caso concreto y otras otros, por lo que me parece que "tildar" de "pésima programación" una metodología para la solución de un problema, me parece poco prudente, pues en este caso hemos resuelto varias cosas, a falta de una alternativa mejor, que seguro 100% existe.
Por otro lado, sigues teniendo mucha razón en que programar no es solo ponerse a teclear, pero creo que todos tratamos siempre de optimizar al máximo posible nuestro código y cuando algo no nos parece "elegante" o no soluciona el problema 100%, tenemos estos foros en los que compañeros nos ayudan con sus experiencias como es tu caso y el de Raymundo, por lo que, sinceramente, os estoy muy agradecido a ambos.

Muchas gracias!

[Raymundo Islas M.]

Andres,

Sin la mas minima intencion de crear algun tipo de discrepancia, considero que es mas "pesima practica" el criticar que el intentar ayudar.

Triumvirato buscaba una solucion no una clase de programacion, fue lo primero que se me ocurrio y lo comente y textualmente dice "creo que te debe funcionar" mas no dice que es la manera correcta de hacerlo.

Ahora, como bien dices hay que intentar hacer el codigo lo mas depurado y preciso posible, a lo que yo me pregunto :

Que pensaras/diras de los que no hacemos uso "correcto" de todas las funciones/parametros/clases/metodos/etc/etc que nos ofrece FWH ?

Como he dicho en varias ocasiones anteriormente, no es mi fuerte el manejo directo de las clases en tu caso, todos sabemos de tu capacidad con ellas.

Te aseguro que todos ( o casi todos ) cometemos errores todos los dias en nuestro codigo, bueno, hasta en la misma definicion/asignacion de las variables por usar ya ni se diga en los procesos.

Saludos

[Patricio Avalos Aguirre]

Hola

Pienso que la mejor optimización sería en ON INIT

Code: Select all  Expand view

ACTIVATE DIALOG ON INIT eval( oBrowPed:bchange )

ya que solo se ejecutaria la primera vez y no n veces que pases por el control, ya que es procesado por ON CHANGE

[triumvirato]

Patricio,

Efectivamente es una solución, pero en este caso el problema es que es un fichero temporal del que se hace el browse y que se genera a partir de unos parámetros introducidos en varios GET en el mismo diálogo, por lo que a la hora de iniciar el diálogo, el fichero está vacío. Luego, cuando toma el foco, los SAYS del diálogo no se actualizan la primera vez, cuando ya te mueves por el browse es cuando lo hacen sin problema, por lo que el problema en sí es en el momento que el browse toma el foco por primera vez.
No creo que haya otra solución que hacerlo cuando toma el foco.

Muchas Gracias. Saludos!