Escribiendo eventos...

[joseluis]

Hola...
Parece ser que hay un orden establecido por Xailer a la hora de escribir
los eventos
Si primero escribes el método y luego lo asignas a un evento Xailer te
duplica la entrada del método y te crea un método en blanco (duplicado).
Si se escribe primero el evento en el inspector de eventos todo va bien...
¿Va a tener que ser así­?
Luego he notado que si escribes ese evento. Lo asignas a varios
controles y luego los 'des-asignas'. Entonces el método desaparece
literalmente sin que te des cuenta. ¿NO podrí­a avisar antes de zamparse
20 minutos de trabajo?
Saludos,
José Luis Capel

[jfgimenez]

José Luis,
> Parece ser que hay un orden establecido por Xailer a la hora de escribir
> los eventos
>
> Si primero escribes el método y luego lo asignas a un evento Xailer te
> duplica la entrada del método y te crea un método en blanco (duplicado).
>
> Si se escribe primero el evento en el inspector de eventos todo va bien...
>
> ¿Va a tener que ser así?
En realidad lo que determina que un método concreto sea reconocido por el
IDE al asignar un evento es tanto el nombre como los parámetros. Me explico:
si creas un método Button1Click() sin más, el IDE no lo reconoce como método
de un evento. El método correcto sería Button1Click( oSender ).
Además, si te fijas, cuando despliegas el combo del inspector donde se pone
el evento, aparecen todos aquellos métodos que coinciden completamente en
todos sus parámetros. Eso permite compartir un mismo método para varios
eventos, incluso de distintos controles, pero evita que asignes p.ej. un
método de un evento OnKeyDown a un evento OnExit.
> Luego he notado que si escribes ese evento. Lo asignas a varios controles
> y luego los 'des-asignas'. Entonces el método desaparece literalmente sin
> que te des cuenta. ¿NO podría avisar antes de zamparse 20 minutos de
> trabajo?
Se elimina cuando ya no queda ningún evento ni control que apunte a ese
método. No obstante, si te das cuenta de que te lo ha eliminado y querías
conservarlo, sólo tienes que pulsar Ctrl+Z en el editor de código.
--
Un saludo,
José F. Giménez

[CapelSoft]

José,
Gracias por tu respuesta... No obstante pienso que se deja a Xailer que
borre código muy fácilmente. Aunque haya posibilidad de recuperarlo.
Pero... y si te das cuenta después de cerrar Xailer ?
Saludos y gracias,
José Luis Capel
Jose F. Gimenez escribió:
> José Luis,
>
>
>>Parece ser que hay un orden establecido por Xailer a la hora de escribir
>>los eventos
>>
>>Si primero escribes el método y luego lo asignas a un evento Xailer te
>>duplica la entrada del método y te crea un método en blanco (duplicado).
>>
>>Si se escribe primero el evento en el inspector de eventos todo va bien...
>>
>>¿Va a tener que ser así­?
>
>
> En realidad lo que determina que un método concreto sea reconocido por el
> IDE al asignar un evento es tanto el nombre como los parámetros. Me explico:
> si creas un método Button1Click() sin más, el IDE no lo reconoce como método
> de un evento. El método correcto serí­a Button1Click( oSender ).
>
> Además, si te fijas, cuando despliegas el combo del inspector donde se pone
> el evento, aparecen todos aquellos métodos que coinciden completamente en
> todos sus parámetros. Eso permite compartir un mismo método para varios
> eventos, incluso de distintos controles, pero evita que asignes p.ej. un
> método de un evento OnKeyDown a un evento OnExit.
>
>
>
>>Luego he notado que si escribes ese evento. Lo asignas a varios controles
>>y luego los 'des-asignas'. Entonces el método desaparece literalmente sin
>>que te des cuenta. ¿NO podrí­a avisar antes de zamparse 20 minutos de
>>trabajo?
>
>
> Se elimina cuando ya no queda ningún evento ni control que apunte a ese
> método. No obstante, si te das cuenta de que te lo ha eliminado y querí­as
> conservarlo, sólo tienes que pulsar Ctrl+Z en el editor de código.
>

[jfgimenez]

José Luis,
> Gracias por tu respuesta... No obstante pienso que se deja a Xailer que
> borre código muy fácilmente. Aunque haya posibilidad de recuperarlo.
>
> Pero... y si te das cuenta después de cerrar Xailer ?
Actualmente (y siempre que no se cambie en la configuración) se está
guardando un .bak cada vez que se graba. Lo que podríamos hacer es guardar
p.ej. hasta 10 versiones .bak de un fichero, más o menos como hace el MED.
De esta forma tendríamos más copias donde poder recuperar un trozo de código
que hayamos borrado.
Me lo anoto para hacerlo cuando podamos.
--
Un saludo,
José F. Giménez

[CapelSoft]

José,
> Actualmente (y siempre que no se cambie en la configuración) se está
> guardando un .bak cada vez que se graba. Lo que podrí­amos hacer es guardar
> p.ej. hasta 10 versiones .bak de un fichero, más o menos como hace el MED.
> De esta forma tendrí­amos más copias donde poder recuperar un trozo de código
> que hayamos borrado.
Estaba pensando (después de pasar esta noche con fiebre de un gripazo de
un dí­a) que podrí­as , cuando detectas que ya no hay ningún control que
apunte a un evento, marcalo con **. Así­, ese código es consultable en
cualquier momento, y si se vuelve a utilizar ese evento, se desmarcan
los ** y se propone el evento que creaste en su momento. Así­ el
usuario puede optar por reutilizarlo o borrarlo.
Saludos,
José Luis Capel

[jfgimenez]

José Luis,
> Estaba pensando (después de pasar esta noche con fiebre de un gripazo de
> un día) que podrías , cuando detectas que ya no hay ningún control que
> apunte a un evento, marcalo con **. Así, ese código es consultable en
> cualquier momento, y si se vuelve a utilizar ese evento, se desmarcan los
> ** y se propone el evento que creaste en su momento. Así el usuario
> puede optar por reutilizarlo o borrarlo.
Me parece rizar el rizo demasiado. En mi opinión, si estás escribiendo el
código de los eventos en un formulario, lo normal es que lo pruebes en ese
momento. De esa forma, si eliminas eventos de los controles y se borra el
método, lo lógico es que te des cuenta enseguida. Pero aún así, si no te das
cuenta y cierras el IDE y ya no puedes "deshacer", la posibilidad de tener
varios .bak de cada fichero te permitiría no perder ese código.
Lo que no soy partidario es de lo que propones, simplemente porque si
escribes eventos de controles, y después eliminas esos controles porque ya
no los necesitas, o porque lo vas a hacer de otra forma o simplemente porque
estabas haciendo alguna prueba, si se queda ese código al final te puedes
encontrar con un montón de código inútil. Y si ese código se comenta, pues
igualmente te vas a encontrar con un montón de líneas que vas a tener que
borrar a mano en la mayoría de los casos.
--
Un saludo,
José F. Giménez

[joseluis]

José,
>
> Me parece rizar el rizo demasiado. En mi opinión, si estás escribiendo el
> código de los eventos en un formulario, lo normal es que lo pruebes en ese
> momento. De esa forma, si eliminas eventos de los controles y se borra el
> método, lo lógico es que te des cuenta enseguida. Pero aún así­, si no te das
> cuenta y cierras el IDE y ya no puedes "deshacer", la posibilidad de tener
> varios .bak de cada fichero te permitirí­a no perder ese código.
>
> Lo que no soy partidario es de lo que propones, simplemente porque si
> escribes eventos de controles, y después eliminas esos controles porque ya
> no los necesitas, o porque lo vas a hacer de otra forma o simplemente porque
> estabas haciendo alguna prueba, si se queda ese código al final te puedes
> encontrar con un montón de código inútil. Y si ese código se comenta, pues
> igualmente te vas a encontrar con un montón de lí­neas que vas a tener que
> borrar a mano en la mayorí­a de los casos.
>
Son diferentes puntos de vista. Para mi es más lógico tener ese código
comentado y para ti tenerlo en un .bak. Ya me parece ambos dos
correctos aunque puestos a preferir... prefiero tenerlo comentado el .prg.
Saludos y gracias por tu tiempo.
José Luis Capel

[joseluis]

José,
>
>
> En realidad lo que determina que un método concreto sea reconocido por el
> IDE al asignar un evento es tanto el nombre como los parámetros. Me explico:
> si creas un método Button1Click() sin más, el IDE no lo reconoce como método
> de un evento. El método correcto serí­a Button1Click( oSender ).
>
> Además, si te fijas, cuando despliegas el combo del inspector donde se pone
> el evento, aparecen todos aquellos métodos que coinciden completamente en
> todos sus parámetros. Eso permite compartir un mismo método para varios
> eventos, incluso de distintos controles, pero evita que asignes p.ej. un
> método de un evento OnKeyDown a un evento OnExit.
>
>
>
He seguido tu consejo al pie de la letra. He definido un evento (a
mano) correctamente. Por ejemplo
METHOD MiraEstado( oSender )
Luego he escrito el método a mano. Por ejemplo:
METHOD MiraEstado( oSender ) CLASS tFrmZonas
RETURN ::lAlta .OR. ::lModi
Y luego me he ido al control al evento OnCheckState y efectivamente,
aparece MiraEstado. Hago click y me duplica la definición del método y
crea otro método.(Ver imágenes)
¿Qué me he dejado por medio?
Saludos y gracias por vuestro tiempo.
José Luis Capel
--

[joseluis]

José,
>
> he estado probandolo de varias formas, y siempre me lo ha hecho bien... si
> seleccionas uno de los métodos desplegando el combo, usa ese método, y no se
> crea ningún otro. Por favor, espera unos dí­as a que publiquemos la PR5a y
> vuelve a probarlo.
>
Claro que espero!!!
Saludos y gracias por tu tiempo.
José Luis Capel

[jfgimenez]

José Luis,
he estado probandolo de varias formas, y siempre me lo ha hecho bien... si
seleccionas uno de los métodos desplegando el combo, usa ese método, y no se
crea ningún otro. Por favor, espera unos días a que publiquemos la PR5a y
vuelve a probarlo.
--
Un saludo,
José F. Giménez