Xailer & OZ Software

Hola,
si hago en mi clase derivada de Twincontrol ¿existe algún problema?
METHOD Create(oNumSender) CLASS TMiControl
Local oSender
oSender := Super:Create(oNumSender)
............ lo que yo quiera iniciar
Return oSender
¡Necesito iniciar y destruir cosas en mi clase derivada sin tener que
definirlo en el form, sino internamente como métodos nuevos!.
Un Saludo,
Joaquín

Joaquin,
Es más sencillo:
METHOD Create( oParent ) CLASS TMiControl
Super:Create( oParent )
...............
RETURN Self
Un saludo,
"Joaquín Martínez" <jmartial@interbook.net> escribió en el mensaje
news:42277ada$[email=1@ozsrv2.ozlan.local...]1@ozsrv2.ozlan.local...[/email]
> Hola,
>
> si hago en mi clase derivada de Twincontrol ¿existe algún problema?
>
> METHOD Create(oNumSender) CLASS TMiControl
> Local oSender
> oSender := Super:Create(oNumSender)
> ............ lo que yo quiera iniciar
> Return oSender
>
>
> ¡Necesito iniciar y destruir cosas en mi clase derivada sin tener que
> definirlo en el form, sino internamente como métodos nuevos!.
>
> Un Saludo,
> Joaquín
>
>

Joaquín,
para completar lo que te ha dicho Ignacio, te comento los principales
métodos que tiene la clase TControl y todas sus derivadas que puedes /
tienes que sobreescribir:
- New( oParent ): Este método es el que se encarga de instanciar el objeto,
no el control en sí. Si te fijas en algún .xfm verás que siempre se llama a
New(), a continuación se establecen las propiedades y por último se llama a
Create(). También es muy importante que llames a Super:New() en algún punto
de este método. Siempre tiene que retornar Self.
- Create( oParent ): Este método se encarga de crear el control a nivel de
windows. Una vez que todas las propiedades están asignadas, lo único que
queda es registrar el control, crear el cursor, el brush, el font, etc., y
crearlo. Salvo casos muy especiales (en todo Xailer el único caso es TForm),
deberás llamar a Super:Create() para crear el control, en vez de llamar a
CreateWindow() directamente. Si necesitas obtener recursos que no están
presentes en las clases padre (p.ej. otras fonts) deberás hacerlo en este
método, antes o después de llamar a Super:Create() según sea necesario.
Siempre tiene que retornar Self.
- Free(): Este método es ejecutado directamente por Xailer cuando se
destruye el objeto (que no el control), y es precísamente aquí el mejor
sitio donde liberar los recursos que hayas necesitado. Es importantísimo que
termines el método con un "RETURN Super:Free()", para permitir liberar otros
recursos que se hayan obtenido en clases anteriores de la jerarquía.
Por otro lado, cuando eres tú quien está escribiendo un nuevo control, no
deberías en ningún caso sobreescribir los eventos (todos aquellos métodos
que comienzan por On: OnCreate, OnClose, etc.; estos están destinados al
usuario). En vez de eso, deberás sobreescribir los métodos correspondientes
a los mensajes de windows. Aclaro que el núcleo de Xailer se encarga de
reenviar los mensajes de windows directamente a la clase correspondiente,
llamando a aquel método que se llame exactamente igual que el nombre del
mensaje pero sin el guión de subrayado. P.ej. cuando se produce el mensaje
WM_SETFOCUS, Xailer llamará automáticamente al método WMSetFocus() del
control al que va destinado el mensaje.
De esta forma, para pintar tu control lo único que tienes que hacer es
sobreescribir el método WMPaint() en tu clase, y hacer ahí todo el proceso
de pintado.
No obstante, algunos de estos mensajes es conveniente redirigirlos a la
clase padre; p.ej. si en WMSetFocus() no llamas a Super:WMSetFocus(...), lo
más seguro es que después no te funcione bien el manejo del foco en tu
control, o que incluso que deje de funcionar al navegación entre controles
del formulario. Pero claro, saber qué mensajes entran en esta categoría es
casi imposible "a priori", y sólo te queda probar de una forma y de otra o
consultárnoslo.
Y una última cosa: al tratarse de mensajes de windows que están siendo
procesados en la clase, es muy importante el valor de retorno de estos
métodos. En cada caso tendrás que consultar la documentación del API, pero
hay una regla general: si retornas Nil, Xailer llamará a DefWindowProc() o
al procedimiento de ventana original del control en el caso de los controles
de windows. Y si retornas cualquier otro valor, Xailer dará por procesado el
mensaje, y no llamará a windows para nada.
Espero haberte aclarado un poco más este tema. De todos modos intentaremos
escribir una guia de "Cómo hacer controles y componentes para Xailer" lo
antes posible.
--
Un saludo,
José F. Giménez

Gracias por tu tiempo y vuestra explicación, ya lo tengo bastante más claro,
pero, ¿ me podrías mandar a mi e-mail un fuente de lo que se pueda ver de un
control de xailer, para ver exactamente algún ejemplo que funciona?
En Madrid me comentaste como crear el WMpaint desde c usando el doble
buffer, ¿hay alguna manera de hacer lo mismo desde prg, sin perder lo del
doble buffer? Es que luego es un engorro para el pintado de cada objeto
tener que definir cada vez el OnPaint y además que el programador tenga que
crear un método en el Tform que llame al método de pintado en la clase
TMiControl a nivel de prg.
No se si me he explicado.
Un Saludo,
Joaquín
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:42283723$[email=1@ozsrv2.ozlan.local...]1@ozsrv2.ozlan.local...[/email]
> Joaquín,
>
> para completar lo que te ha dicho Ignacio, te comento los principales
> métodos que tiene la clase TControl y todas sus derivadas que puedes /
> tienes que sobreescribir:
>
> - New( oParent ): Este método es el que se encarga de instanciar el
objeto,
> no el control en sí. Si te fijas en algún .xfm verás que siempre se llama
a
> New(), a continuación se establecen las propiedades y por último se llama
a
> Create(). También es muy importante que llames a Super:New() en algún
punto
> de este método. Siempre tiene que retornar Self.
>
> - Create( oParent ): Este método se encarga de crear el control a nivel de
> windows. Una vez que todas las propiedades están asignadas, lo único que
> queda es registrar el control, crear el cursor, el brush, el font, etc., y
> crearlo. Salvo casos muy especiales (en todo Xailer el único caso es
TForm),
> deberás llamar a Super:Create() para crear el control, en vez de llamar a
> CreateWindow() directamente. Si necesitas obtener recursos que no están
> presentes en las clases padre (p.ej. otras fonts) deberás hacerlo en este
> método, antes o después de llamar a Super:Create() según sea necesario.
> Siempre tiene que retornar Self.
>
> - Free(): Este método es ejecutado directamente por Xailer cuando se
> destruye el objeto (que no el control), y es precísamente aquí el mejor
> sitio donde liberar los recursos que hayas necesitado. Es importantísimo
que
> termines el método con un "RETURN Super:Free()", para permitir liberar
otros
> recursos que se hayan obtenido en clases anteriores de la jerarquía.
>
> Por otro lado, cuando eres tú quien está escribiendo un nuevo control, no
> deberías en ningún caso sobreescribir los eventos (todos aquellos métodos
> que comienzan por On: OnCreate, OnClose, etc.; estos están destinados al
> usuario). En vez de eso, deberás sobreescribir los métodos
correspondientes
> a los mensajes de windows. Aclaro que el núcleo de Xailer se encarga de
> reenviar los mensajes de windows directamente a la clase correspondiente,
> llamando a aquel método que se llame exactamente igual que el nombre del
> mensaje pero sin el guión de subrayado. P.ej. cuando se produce el mensaje
> WM_SETFOCUS, Xailer llamará automáticamente al método WMSetFocus() del
> control al que va destinado el mensaje.
>
> De esta forma, para pintar tu control lo único que tienes que hacer es
> sobreescribir el método WMPaint() en tu clase, y hacer ahí todo el proceso
> de pintado.
>
> No obstante, algunos de estos mensajes es conveniente redirigirlos a la
> clase padre; p.ej. si en WMSetFocus() no llamas a Super:WMSetFocus(...),
lo
> más seguro es que después no te funcione bien el manejo del foco en tu
> control, o que incluso que deje de funcionar al navegación entre controles
> del formulario. Pero claro, saber qué mensajes entran en esta categoría es
> casi imposible "a priori", y sólo te queda probar de una forma y de otra o
> consultárnoslo.
>
> Y una última cosa: al tratarse de mensajes de windows que están siendo
> procesados en la clase, es muy importante el valor de retorno de estos
> métodos. En cada caso tendrás que consultar la documentación del API, pero
> hay una regla general: si retornas Nil, Xailer llamará a DefWindowProc() o
> al procedimiento de ventana original del control en el caso de los
controles
> de windows. Y si retornas cualquier otro valor, Xailer dará por procesado
el
> mensaje, y no llamará a windows para nada.
>
> Espero haberte aclarado un poco más este tema. De todos modos intentaremos
> escribir una guia de "Cómo hacer controles y componentes para Xailer" lo
> antes posible.
>
> --
> Un saludo,
>
> José F. Giménez
>
>

Joaquín,
> Gracias por tu tiempo y vuestra explicación, ya lo tengo bastante más
> claro,
> pero, ¿ me podrías mandar a mi e-mail un fuente de lo que se pueda ver de
> un
> control de xailer, para ver exactamente algún ejemplo que funciona?
Te lo preparo esta tarde y te lo envio.
> En Madrid me comentaste como crear el WMpaint desde c usando el doble
> buffer, ¿hay alguna manera de hacer lo mismo desde prg, sin perder lo del
> doble buffer? Es que luego es un engorro para el pintado de cada objeto
> tener que definir cada vez el OnPaint y además que el programador tenga
> que
> crear un método en el Tform que llame al método de pintado en la clase
> TMiControl a nivel de prg.
Precísamente lo que te enseñé en Madrid era el esqueleto del método
WMPaint() en C, que a su vez llamaba al método Paint() de la clase. De esa
forma, sólo tenías que desarrollar el método Paint() en prg, y ya te venía
pintado tanto el borde como el fondo, y con el doble buffer activado.
Revísalo, y si no te aclaras me lo dices.
--
Un saludo,
José F. Giménez

Jose,
En C llamabas al "OnPaint" lo que me obliga al crear mi clase derivada a
hacer OnPaint := "MiOnPaint" y ese método lo tengo que definir en el TFORM,
con cada control que quiera crear, y mi idea es que el método paint sea uno
dentro de mi control y ya está, y que el programador no tenga que definirlo
cada vez como un método del Tform.
Espero haberme explicado ahora,
Gracias,
Joaquín
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:422859ee$[email=1@ozsrv2.ozlan.local...]1@ozsrv2.ozlan.local...[/email]
> Joaquín,
>
> > Gracias por tu tiempo y vuestra explicación, ya lo tengo bastante más
> > claro,
> > pero, ¿ me podrías mandar a mi e-mail un fuente de lo que se pueda ver
de
> > un
> > control de xailer, para ver exactamente algún ejemplo que funciona?
>
> Te lo preparo esta tarde y te lo envio.
>
>
> > En Madrid me comentaste como crear el WMpaint desde c usando el doble
> > buffer, ¿hay alguna manera de hacer lo mismo desde prg, sin perder lo
del
> > doble buffer? Es que luego es un engorro para el pintado de cada objeto
> > tener que definir cada vez el OnPaint y además que el programador tenga
> > que
> > crear un método en el Tform que llame al método de pintado en la clase
> > TMiControl a nivel de prg.
>
> Precísamente lo que te enseñé en Madrid era el esqueleto del método
> WMPaint() en C, que a su vez llamaba al método Paint() de la clase. De esa
> forma, sólo tenías que desarrollar el método Paint() en prg, y ya te venía
> pintado tanto el borde como el fondo, y con el doble buffer activado.
> Revísalo, y si no te aclaras me lo dices.
>
> --
> Un saludo,
>
> José F. Giménez
>
>

Joaquín,
> En C llamabas al "OnPaint" lo que me obliga al crear mi clase derivada a
> hacer OnPaint := "MiOnPaint" y ese método lo tengo que definir en el
> TFORM,
> con cada control que quiera crear, y mi idea es que el método paint sea
> uno
> dentro de mi control y ya está, y que el programador no tenga que
> definirlo
> cada vez como un método del Tform.
Ok, no me acordaba exactamente.
Lo que tienes que hacer es cambiar OnPaint por Paint en la función en C, y
después añades el método Paint en la clase. Este método sólo debería recibir
el hDC donde tienes que pintar.
--
Un saludo,
José F. Giménez

Perfecto Jose,
¿Puedo conservar en el esqueleto en C después de llamar a paint, llamar a
OnPaint para que al programar también tener disponible ese evento, o
enlentecerá el pintado?
Un Saludo,
Joaquín
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:[email=422867be@ozsrv2.ozlan.local...]422867be@ozsrv2.ozlan.local...[/email]
> Joaquín,
>
> > En C llamabas al "OnPaint" lo que me obliga al crear mi clase derivada a
> > hacer OnPaint := "MiOnPaint" y ese método lo tengo que definir en el
> > TFORM,
> > con cada control que quiera crear, y mi idea es que el método paint sea
> > uno
> > dentro de mi control y ya está, y que el programador no tenga que
> > definirlo
> > cada vez como un método del Tform.
>
> Ok, no me acordaba exactamente.
>
> Lo que tienes que hacer es cambiar OnPaint por Paint en la función en C, y
> después añades el método Paint en la clase. Este método sólo debería
recibir
> el hDC donde tienes que pintar.
>
> --
> Un saludo,
>
> José F. Giménez
>
>

Joaquín,
> ¿Puedo conservar en el esqueleto en C después de llamar a paint, llamar a
> OnPaint para que al programar también tener disponible ese evento, o
> enlentecerá el pintado?
Siempre consumirá algo de tiempo en llamar a OnPaint, pero no creo que debas
preocuparte por eso. Cuando el evento no esté asignado será muy rápido. Y
cuando esté asignado... pues dependerá de lo que tenga el evento
--
Un saludo,
José F. Giménez