Xailer & OZ Software

Estimado Ignacio. Nos conocimos en la reunión de Madrid del pasado mes de
Octubre y nos volvimos a ver en la última de Murcia. Soy José, compañero de
trabajo de J. Alfonso Suarez en Sevilla. Espero me recuerdes.
Por fin he encontrado tiempo y he comenzado a probar vuestro producto, y
debo reconocer que me está dejando impresionado. Os felicito y os doy la
enhorabuena para que sigáis poniéndole las ganas que hasta ahora. Pero como
entiendo que vosotros solos no podeis hacerle frente a todo, a continuación
os detallo una serie de puntos que creo que os pueden ser de utilidad y que
a mi me tienen un poco desesperado:
1.- Los atributos de una clase declarados como DATA no se visualizan en el
arbol del debugger. En mi caso me ocurre con una clase "Formulario" que
hereda de TForm. No creo que eso influya pero por si acaso lo comento. No lo
he probado con otra clase. En definitiva. He creado unas DATA a mano en
dicha clase, y para poder visualizarlas en el debugger, las tengo que poner
como COMPONENT, si no, no aparecen en el arbol. Entiendo que,
independientemente de lo que sean, si en definitiva, son atributos de la
clase, debo poder verlos en el debugger.
2.- El atributo nMaxLength de un oDBEdit o de un oDBMaskEdit con valor a 0
no se comporta como se especifica en las ayudas. Según estas, si lo dejo a
0, dicha propiedad adquiere la longitud del primer valor con que se rellene
el objeto. Al parecer con DBF va bien (yo no le he probado), pero con
TADODataSource y TSQLQuery sobre una tabla MySQL, no hace caso, y se queda a
ilimitado, pudiendo por tanto escribir todos los caracteres que el usuario
desee y no ajustandose a lo establecido en el diseño de la tabla MySQL.
3.- Como intento de solución al punto anterior y teniendo en cuenta que lo
que estoy programando está basado ("copiado") en el sample de Xailer del
ExplorerBar, he probado a hacer lo siguiente:
METHOD FirstCreate( oSender ) CLASS TFormClinica
oSender:nMaxLength := oSender:oDataField:nLen
oSender:oDataSet := ::oParent:oSQLQueryFullCurrent
RETURN Nil
Pero mi sorpresa, al meter el debugger es que oSender:oDataField NO ES UN
Objeto, sino un CARACTER. Entiendo lo de que pongamos un caracter como
"acceso rápido", pero cuando pregunto por oDataField en el código, a mi
entender debería ser un objeto como indican las ayudas e incluso su propia
preposición "o", ¿no?
4.- Mi mayor problema y en el que de verdad no entiendo qué me está pasando.
Te pongo en situación. El ejemplo del ExplorerBar de los samples de Xailer
construye un TDBBrowse a partir de un TDbfDataSet y lo muestra, permitiendo
mediante opciones en la ExplorerBar insertar, elimiar y editar registros de
él en una segunda ventana. Bien. Yo he "ampliado" ese ejemplo poniendo al
comienzo de la explorerBar un Combobox referente a sobre qué fichero quiero
mantener en la ventana, de forma que su TDBBrowse correspondiente se oculta
o muestra cuando el combobox lo indique. Para ello, he declarado unas DATAS
(las del punto 1) en dicha clase que hacen referencia en todo momento a:
DATA oSQLQueryRelationCurrent (TSQLQuery actual utilizada para mostrar el
browser (Solo tiene los datos a mostrar en el browser))
DATA oSQLQueryFullCurrent (TSQLQuery actual cuyo Select obtiene todos
los campos de la misma tabla que oSQLQueryRelationCurrent del registro en el
que esta última esté posicionado. Inicialmente el lOpen está a falso y antes
de ponerlo por código a True, construyo la Select poniendole un WHERE ID=ID
actual de oSQLQueryRelationCurrent. Cuando finalizo, vuelvo a poner su lOpen
a falso.).
DATA oDBBrowseCurrent (TDBBrowse actual que se está mostrando y que está
creado sobre oSQLQueryRelationCurrent)
Así, cuando pulso las opciones en la ExplorerBar de Añadir, Editar o
Eliminar un registro, siempre lo haré sobre oSQLQueryFullCurrent. Pues el
problema es que: Cuando añado o edito por primera vez, todo va genial
(Realmente la eliminación aún no la he implementado). Pero cuando lo intento
hacer por segunda y posteriores veces, la aplicación no hace nada y la
ventana del debugger me da los siguientes mensajes:
#6: XAILER Warning: Incorrect type on field Codigo
#7: XAILER Warning: Incorrect type on field RazonSocial
#8: XAILER Warning: Incorrect type on field Domicilio
#9: XAILER Warning: Incorrect type on field Poblacion
#10: XAILER Warning: Incorrect type on field Provincia
#11: XAILER Warning: Incorrect type on field DP
#12: XAILER Warning: Incorrect type on field NIF
#13: XAILER Warning: Incorrect type on field Mail
#14: XAILER Warning: Incorrect type on field Web
#15: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#16: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#17: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#18: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#19: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#20: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#21: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#22: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#23: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#24: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#25: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#26: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#27: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#28: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#29: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#30: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#31: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#32: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
#33: HEAP[lpd.exe]:
#34: Heap block at 00233268 modified at 0023327A past requested size of a
#35: HEAP[lpd.exe]:
#36: Invalid Address specified to RtlFreeHeap( 00150000, 00233270 )
Te detallo algunas cosas a destacar de este cuarto punto. Estoy trabajando
con ADO (ya lo has visto) y MySQL. He notado que, a pesar de cambiar la
Select tal y como te he comentado en cada adición/edición de registro para
poner el WHERE, su propiedad aFields (Que para la primera vez es un array
vacio y por lo tanto se rellena automáticamente) no varia ya, por mucho que
cambie la Select. No creo que este sea el problema ya que he probado a
vaciar dicho array al salir, a sacar una copia antes y restaurarla, etc.. y
nada, pero.. ¿eso debe ser así? ¿Qué pasa si establezco, tras un lOpen:=.F.
una Select que se traiga unos campos distintos a los de la primera select
indicada? ¿No sería lógico que si cambio la propiedad SELECT de un SQLQuery,
su propiedad aFields (inclusive otras) se "resetearan"? No sé si quizás
estoy divagando demasiado. Pero en principio me parecería lo razonable,
¿no?.
Siento si esto es un poco engorroso porque sé que estás bastante liado, pero
te invito a que reproduzcas estos puntos (es muy facil de hacer modificando
el sample que te comento) ya que creo que te pueden resultar interesantes.
La intención con la que escribo el mensaje es de ayuda mutua. Espero que al
final no sea que estoy haciendo algo mal y no me he dado cuenta porque
sentiría haberte molestado por algo así. Pero créeme. Lo he intentado todo,
llevo varios días. He mirado las ayudas, las noticias y los blogs y nada.
Vaya. Que antes de recurrir a tí, me lo he currado. Pero no he sido capaz de
dar con la solución a ninguna de estas cosas.
Espero que podamos ayudarnos mutuamente.
Quedo a la espera de algún comentario.
Un saludo.
José Francisco Rangel Serrano.

José Francisco,
> Por fin he encontrado tiempo y he comenzado a probar vuestro producto, y
> debo reconocer que me está dejando impresionado. Os felicito y os doy la
> enhorabuena para que sigáis poniéndole las ganas que hasta ahora.
Muchas gracias por tus palabras.
> 1.- Los atributos de una clase declarados como DATA no se visualizan en el
> arbol del debugger. En mi caso me ocurre con una clase "Formulario" que
> hereda de TForm. No creo que eso influya pero por si acaso lo comento. No
> lo he probado con otra clase. En definitiva. He creado unas DATA a mano en
> dicha clase, y para poder visualizarlas en el debugger, las tengo que
> poner como COMPONENT, si no, no aparecen en el arbol. Entiendo que,
> independientemente de lo que sean, si en definitiva, son atributos de la
> clase, debo poder verlos en el debugger.
Sí, es cierto, y está hecho así a propósito. Sólo aparecen en el debugger
las COMPONENT (en negrita) y las PROPERTY. Entendemos que lo que debe
aparecer en el debugger es lo relevante, no un montón de datas que en el 99%
de los casos sólo sirven para estorbar.
> 2.- El atributo nMaxLength de un oDBEdit o de un oDBMaskEdit con valor a 0
> no se comporta como se especifica en las ayudas. Según estas, si lo dejo a
> 0, dicha propiedad adquiere la longitud del primer valor con que se
> rellene el objeto. Al parecer con DBF va bien (yo no le he probado), pero
> con TADODataSource y TSQLQuery sobre una tabla MySQL, no hace caso, y se
> queda a ilimitado, pudiendo por tanto escribir todos los caracteres que el
> usuario desee y no ajustandose a lo establecido en el diseño de la tabla
> MySQL.
La diferencia principal es que en DBF las longitudes de los campos son
fijas, es decir, si un campo es 'character 40', entonces siempre tendrá 40
caracteres, que será el texto que introduzcas rellenado con espacios hasta
completar dicha longitud. En cambio, en SQL, lo más común es que una cadena
ocupe exactamente lo que tiene introducido. Mi consejo es que asignes
expresamente la longitud del control.
> 3.- Como intento de solución al punto anterior y teniendo en cuenta que lo
> que estoy programando está basado ("copiado") en el sample de Xailer del
> ExplorerBar, he probado a hacer lo siguiente:
>
> METHOD FirstCreate( oSender ) CLASS TFormClinica
>
> oSender:nMaxLength := oSender:oDataField:nLen
> oSender:oDataSet := ::oParent:oSQLQueryFullCurrent
>
> RETURN Nil
>
> Pero mi sorpresa, al meter el debugger es que oSender:oDataField NO ES UN
> Objeto, sino un CARACTER. Entiendo lo de que pongamos un caracter como
> "acceso rápido", pero cuando pregunto por oDataField en el código, a mi
> entender debería ser un objeto como indican las ayudas e incluso su propia
> preposición "o", ¿no?
Bueno, la propiedad oDataField es una cadena de caracteres con el nombre del
campo mientras el dataset esté cerrado. Cuando abres el dataset, entonces es
cuando se convierte en un objeto con todas sus propiedades. Esto es así
porque dichas propiedades no están definidas con el dataset cerrado.
Podríamos haber provocado un error al acceder a esta propiedad en este caso,
pero preferimos que al menos contuviera el nombre del campo.
> 4.- Mi mayor problema y en el que de verdad no entiendo qué me está
> pasando. Te pongo en situación. El ejemplo del ExplorerBar de los samples
> de Xailer construye un TDBBrowse a partir de un TDbfDataSet y lo muestra,
> permitiendo mediante opciones en la ExplorerBar insertar, elimiar y editar
> registros de él en una segunda ventana. Bien. Yo he "ampliado" ese ejemplo
> poniendo al comienzo de la explorerBar un Combobox referente a sobre qué
> fichero quiero mantener en la ventana, de forma que su TDBBrowse
> correspondiente se oculta o muestra cuando el combobox lo indique. Para
> ello, he declarado unas DATAS (las del punto 1) en dicha clase que hacen
> referencia en todo momento a:
>
> DATA oSQLQueryRelationCurrent (TSQLQuery actual utilizada para mostrar
> el browser (Solo tiene los datos a mostrar en el browser))
> DATA oSQLQueryFullCurrent (TSQLQuery actual cuyo Select obtiene todos
> los campos de la misma tabla que oSQLQueryRelationCurrent del registro en
> el que esta última esté posicionado. Inicialmente el lOpen está a falso y
> antes de ponerlo por código a True, construyo la Select poniendole un
> WHERE ID=ID actual de oSQLQueryRelationCurrent. Cuando finalizo, vuelvo a
> poner su lOpen a falso.).
> DATA oDBBrowseCurrent (TDBBrowse actual que se está mostrando y que está
> creado sobre oSQLQueryRelationCurrent)
>
> Así, cuando pulso las opciones en la ExplorerBar de Añadir, Editar o
> Eliminar un registro, siempre lo haré sobre oSQLQueryFullCurrent. Pues el
> problema es que: Cuando añado o edito por primera vez, todo va genial
> (Realmente la eliminación aún no la he implementado). Pero cuando lo
> intento hacer por segunda y posteriores veces, la aplicación no hace nada
> y la ventana del debugger me da los siguientes mensajes:
>
> #6: XAILER Warning: Incorrect type on field Codigo
> #7: XAILER Warning: Incorrect type on field RazonSocial
> #8: XAILER Warning: Incorrect type on field Domicilio
> #9: XAILER Warning: Incorrect type on field Poblacion
> #10: XAILER Warning: Incorrect type on field Provincia
> #11: XAILER Warning: Incorrect type on field DP
> #12: XAILER Warning: Incorrect type on field NIF
> #13: XAILER Warning: Incorrect type on field Mail
> #14: XAILER Warning: Incorrect type on field Web
> #15: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #16: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #17: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #18: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #19: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #20: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #21: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #22: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #23: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #24: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #25: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #26: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #27: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #28: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #29: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #30: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #31: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #32: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
> #33: HEAP[lpd.exe]:
> #34: Heap block at 00233268 modified at 0023327A past requested size of a
>
> #35: HEAP[lpd.exe]:
> #36: Invalid Address specified to RtlFreeHeap( 00150000, 00233270 )
>
> Te detallo algunas cosas a destacar de este cuarto punto. Estoy trabajando
> con ADO (ya lo has visto) y MySQL. He notado que, a pesar de cambiar la
> Select tal y como te he comentado en cada adición/edición de registro para
> poner el WHERE, su propiedad aFields (Que para la primera vez es un array
> vacio y por lo tanto se rellena automáticamente) no varia ya, por mucho
> que cambie la Select. No creo que este sea el problema ya que he probado a
> vaciar dicho array al salir, a sacar una copia antes y restaurarla, etc..
> y nada, pero.. ¿eso debe ser así? ¿Qué pasa si establezco, tras un
> lOpen:=.F. una Select que se traiga unos campos distintos a los de la
> primera select indicada? ¿No sería lógico que si cambio la propiedad
> SELECT de un SQLQuery, su propiedad aFields (inclusive otras) se
> "resetearan"? No sé si quizás estoy divagando demasiado. Pero en principio
> me parecería lo razonable, ¿no?.
Por favor, envíanos el ejemplo con el que estás probando para comprobarlo.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Ante todo José, muchisimas gracias por la rápidez. Me habeis vuelto a
impresionar. No sé si me recordarás, pero estuvimos juntos en la reunión de
Murcia. En fin, respecto a lo que me comentas, así lo haré.
Simplemente comentarte que ahora no puedo probarlo porque no lo tengo aquí,
pero que si el punto 2 lo puedo resolver tal y como lo hago en el 3 una vez
que abra el DataSet, por mí, perfecto. Respecto al cuarto punto, te mandaré
lo que tengo hecho. Es muy sencillo de entender el código y espero que
puedas ver algo porque estoy realmente perdido.
Respecto al primer punto, entiendo lo que me dices, pero, (y siempre como
critica constructiva y hasta con reparo porque como comprenderás, no voy a
llegar de novato intentando arreglar el mundo) a mi entender, un debugger
debe permitirme siempre poder acceder a cualquiera de las variables que
poseo en ese instante ya que a mi entender, pierde potencia. Quizás sería
bueno el que preguntaseis si se desean mostrar todos los tipos o solo las
COMPONENT y las PROPERTY, ¿no?
Muchas gracias de nuevo y un fuerte saludo.
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:[email=46a4760f@ozsrv2.ozlan.local...]46a4760f@ozsrv2.ozlan.local...[/email]
> José Francisco,
>
>> Por fin he encontrado tiempo y he comenzado a probar vuestro producto, y
>> debo reconocer que me está dejando impresionado. Os felicito y os doy la
>> enhorabuena para que sigáis poniéndole las ganas que hasta ahora.
>
> Muchas gracias por tus palabras.
>
>
>> 1.- Los atributos de una clase declarados como DATA no se visualizan en
>> el arbol del debugger. En mi caso me ocurre con una clase "Formulario"
>> que hereda de TForm. No creo que eso influya pero por si acaso lo
>> comento. No lo he probado con otra clase. En definitiva. He creado unas
>> DATA a mano en dicha clase, y para poder visualizarlas en el debugger,
>> las tengo que poner como COMPONENT, si no, no aparecen en el arbol.
>> Entiendo que, independientemente de lo que sean, si en definitiva, son
>> atributos de la clase, debo poder verlos en el debugger.
>
> Sí, es cierto, y está hecho así a propósito. Sólo aparecen en el debugger
> las COMPONENT (en negrita) y las PROPERTY. Entendemos que lo que debe
> aparecer en el debugger es lo relevante, no un montón de datas que en el
> 99% de los casos sólo sirven para estorbar.
>
>
>> 2.- El atributo nMaxLength de un oDBEdit o de un oDBMaskEdit con valor a
>> 0 no se comporta como se especifica en las ayudas. Según estas, si lo
>> dejo a 0, dicha propiedad adquiere la longitud del primer valor con que
>> se rellene el objeto. Al parecer con DBF va bien (yo no le he probado),
>> pero con TADODataSource y TSQLQuery sobre una tabla MySQL, no hace caso,
>> y se queda a ilimitado, pudiendo por tanto escribir todos los caracteres
>> que el usuario desee y no ajustandose a lo establecido en el diseño de la
>> tabla MySQL.
>
> La diferencia principal es que en DBF las longitudes de los campos son
> fijas, es decir, si un campo es 'character 40', entonces siempre tendrá 40
> caracteres, que será el texto que introduzcas rellenado con espacios hasta
> completar dicha longitud. En cambio, en SQL, lo más común es que una
> cadena ocupe exactamente lo que tiene introducido. Mi consejo es que
> asignes expresamente la longitud del control.
>
>
>> 3.- Como intento de solución al punto anterior y teniendo en cuenta que
>> lo que estoy programando está basado ("copiado") en el sample de Xailer
>> del ExplorerBar, he probado a hacer lo siguiente:
>>
>> METHOD FirstCreate( oSender ) CLASS TFormClinica
>>
>> oSender:nMaxLength := oSender:oDataField:nLen
>> oSender:oDataSet := ::oParent:oSQLQueryFullCurrent
>>
>> RETURN Nil
>>
>> Pero mi sorpresa, al meter el debugger es que oSender:oDataField NO ES UN
>> Objeto, sino un CARACTER. Entiendo lo de que pongamos un caracter como
>> "acceso rápido", pero cuando pregunto por oDataField en el código, a mi
>> entender debería ser un objeto como indican las ayudas e incluso su
>> propia preposición "o", ¿no?
>
> Bueno, la propiedad oDataField es una cadena de caracteres con el nombre
> del campo mientras el dataset esté cerrado. Cuando abres el dataset,
> entonces es cuando se convierte en un objeto con todas sus propiedades.
> Esto es así porque dichas propiedades no están definidas con el dataset
> cerrado. Podríamos haber provocado un error al acceder a esta propiedad en
> este caso, pero preferimos que al menos contuviera el nombre del campo.
>
>
>> 4.- Mi mayor problema y en el que de verdad no entiendo qué me está
>> pasando. Te pongo en situación. El ejemplo del ExplorerBar de los samples
>> de Xailer construye un TDBBrowse a partir de un TDbfDataSet y lo muestra,
>> permitiendo mediante opciones en la ExplorerBar insertar, elimiar y
>> editar registros de él en una segunda ventana. Bien. Yo he "ampliado" ese
>> ejemplo poniendo al comienzo de la explorerBar un Combobox referente a
>> sobre qué fichero quiero mantener en la ventana, de forma que su
>> TDBBrowse correspondiente se oculta o muestra cuando el combobox lo
>> indique. Para ello, he declarado unas DATAS (las del punto 1) en dicha
>> clase que hacen referencia en todo momento a:
>>
>> DATA oSQLQueryRelationCurrent (TSQLQuery actual utilizada para mostrar
>> el browser (Solo tiene los datos a mostrar en el browser))
>> DATA oSQLQueryFullCurrent (TSQLQuery actual cuyo Select obtiene todos
>> los campos de la misma tabla que oSQLQueryRelationCurrent del registro en
>> el que esta última esté posicionado. Inicialmente el lOpen está a falso y
>> antes de ponerlo por código a True, construyo la Select poniendole un
>> WHERE ID=ID actual de oSQLQueryRelationCurrent. Cuando finalizo, vuelvo a
>> poner su lOpen a falso.).
>> DATA oDBBrowseCurrent (TDBBrowse actual que se está mostrando y que
>> está creado sobre oSQLQueryRelationCurrent)
>>
>> Así, cuando pulso las opciones en la ExplorerBar de Añadir, Editar o
>> Eliminar un registro, siempre lo haré sobre oSQLQueryFullCurrent. Pues el
>> problema es que: Cuando añado o edito por primera vez, todo va genial
>> (Realmente la eliminación aún no la he implementado). Pero cuando lo
>> intento hacer por segunda y posteriores veces, la aplicación no hace nada
>> y la ventana del debugger me da los siguientes mensajes:
>>
>> #6: XAILER Warning: Incorrect type on field Codigo
>> #7: XAILER Warning: Incorrect type on field RazonSocial
>> #8: XAILER Warning: Incorrect type on field Domicilio
>> #9: XAILER Warning: Incorrect type on field Poblacion
>> #10: XAILER Warning: Incorrect type on field Provincia
>> #11: XAILER Warning: Incorrect type on field DP
>> #12: XAILER Warning: Incorrect type on field NIF
>> #13: XAILER Warning: Incorrect type on field Mail
>> #14: XAILER Warning: Incorrect type on field Web
>> #15: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #16: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #17: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #18: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #19: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #20: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #21: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #22: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #23: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #24: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #25: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #26: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #27: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #28: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #29: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #30: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #31: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #32: XAILER: TDBEdit:oDataField is not a valid TDataField Object (NIL)
>> #33: HEAP[lpd.exe]:
>> #34: Heap block at 00233268 modified at 0023327A past requested size of a
>>
>> #35: HEAP[lpd.exe]:
>> #36: Invalid Address specified to RtlFreeHeap( 00150000, 00233270 )
>>
>> Te detallo algunas cosas a destacar de este cuarto punto. Estoy
>> trabajando con ADO (ya lo has visto) y MySQL. He notado que, a pesar de
>> cambiar la Select tal y como te he comentado en cada adición/edición de
>> registro para poner el WHERE, su propiedad aFields (Que para la primera
>> vez es un array vacio y por lo tanto se rellena automáticamente) no varia
>> ya, por mucho que cambie la Select. No creo que este sea el problema ya
>> que he probado a vaciar dicho array al salir, a sacar una copia antes y
>> restaurarla, etc.. y nada, pero.. ¿eso debe ser así? ¿Qué pasa si
>> establezco, tras un lOpen:=.F. una Select que se traiga unos campos
>> distintos a los de la primera select indicada? ¿No sería lógico que si
>> cambio la propiedad SELECT de un SQLQuery, su propiedad aFields
>> (inclusive otras) se "resetearan"? No sé si quizás estoy divagando
>> demasiado. Pero en principio me parecería lo razonable, ¿no?.
>
> Por favor, envíanos el ejemplo con el que estás probando para comprobarlo.
>
> --
> Un saludo,
>
> José F. Giménez
> http://www.xailer.com
> http://www.xailer.info
>

Hola de nuevo, José.
Aquí te adjunto el ejemplo del cuarto punto que te indicaba. Tan solo
comentarte que, tal y como me indicabas, he realizado el Open del DataSet
antes de crear la ventana(oForm := ::oClassObjectFormCurrent:New( Self )).
Esto ha supuesto que, de todos los errores que aparecían en la ventana de
debugger, ahora tan solo me aparezcan estos (ahora veo bastante lógicos los
anteriores: Los TDBEdit están a sociados a un DataSet que no estaba abierto.
Pero aun así, sigo sin entender cómo la primera vez, sin tampoco estarlo
(oSQLQueryFullCurrent:lOpen==.F. en la creación del componente), sí lo hacía
bien):
#6: HEAP[lpd.exe]:
#7: Heap block at 00235868 modified at 0023587A past requested size of a
#8: HEAP[lpd.exe]:
#9: Invalid Address specified to RtlFreeHeap( 00150000, 00235870 )
Sin embargo, como puedes observar, sigue dándome este error en segundos y
posteriores intentos de edicion/adicion de un registro.
Pero además, el campo oDataField de oDbEdit sigue siendo caracter en lugar
de un objeto, a pesar de estar ya abierto el DataSet al que está asociado
(Mirar TFormClinica.prg. Está comentado.) tal y como me has indicado.
Gracias por la atención que mostrais.
Un saludo.
José Francisco Rangel Serrano.


Attached files lpd.sql (2.5 KB)Â lpd.zip (9 KB)Â

José,
el problema está en el ciclo de creación y destrucción de los formularios.
Estás instanciando el objeto formulario en el evento OnChange del combo, y
después, en la opción de editar, es donde realmente se está creando el
formulario, que es donde se está llamando a :New(). En este mismo método
estás desruyéndolo, ya que llamas a :End(). Pero a partir de ahí, ya no es
válido ese objeto hasta que vuelvas a instanciarlo y crearlo con :New().
Veamos la secuencia:
1º vez)
- Se instancia el objeto con
::oClassObjectFormCurrent:=TFormClinica()
- Se crea el formulario con
WITH OBJECT oForm := ::oClassObjectFormCurrent:New( Self )
- Y se destruye con
:End()
2ª vez)
- Se intenta crear el formulario con
::oClassObjectFormCurrent:=TFormClinica()
pero en ese momento, ::oClassObjectFormCurrent contiene una referencia a
un objeto que ya ha sido destruido en su totalidad, y por lo tanto provoca
un fallo en la VM que terminará dando un GPF tarde o temprano.
- las siguientes llamadas a :ShowModal(), etc., fallan debido a lo anterior.
Lo que debes hacer es una de estas 2 soluciones:
- instanciar y crear el formulario cada vez
- crearlo una vez y establecer su propiedad lHideOnClose = .T. (esto hace
que el formulario no se destruya al cerrarlo). Y destruirlo al final, en el
evento OnClose de TMantenimientos.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Mil gracias, José.
Es super lógico lo que dices. Mi problema es que vengo de Alaska XBase++ y
la instanciación de objetos allí no es exactamente igual. Allí,
TFormClinica() devuelve el ClassObject de la clase TFormClinica, y no se
instancia un objeto de dicha clase hasta que sobre dicho ClassObject no se
hace un New(). Veo que en Xailer, el concepto de ClassObject no existe (o se
obtiene de otra manera. De ser así, me gustaría saber como.) y que la
instanciación de un objeto se hace automaticamente con TFormClinica(). Y en
Alaska XBase++, lo que en Xailer se hace como New() para crear el
formulario, es un Create(). De aquí mi error. De haber sabido correctamente
como se comporta Xailer en la instanciación de objetos, no os hubiese
molestado.
Ahora ya va todo correcto.
Muchísimas gracias y un saludo enorme.
José Francisco Rangel Serrano.
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:46a5c736$[email=1@ozsrv2.ozlan.local...]1@ozsrv2.ozlan.local...[/email]
> José,
>
> el problema está en el ciclo de creación y destrucción de los formularios.
> Estás instanciando el objeto formulario en el evento OnChange del combo, y
> después, en la opción de editar, es donde realmente se está creando el
> formulario, que es donde se está llamando a :New(). En este mismo método
> estás desruyéndolo, ya que llamas a :End(). Pero a partir de ahí, ya no es
> válido ese objeto hasta que vuelvas a instanciarlo y crearlo con :New().
>
> Veamos la secuencia:
>
> 1º vez)
>
> - Se instancia el objeto con
> ::oClassObjectFormCurrent:=TFormClinica()
>
> - Se crea el formulario con
> WITH OBJECT oForm := ::oClassObjectFormCurrent:New( Self )
>
> - Y se destruye con
> :End()
>
> 2ª vez)
>
> - Se intenta crear el formulario con
> ::oClassObjectFormCurrent:=TFormClinica()
> pero en ese momento, ::oClassObjectFormCurrent contiene una referencia a
> un objeto que ya ha sido destruido en su totalidad, y por lo tanto provoca
> un fallo en la VM que terminará dando un GPF tarde o temprano.
>
> - las siguientes llamadas a :ShowModal(), etc., fallan debido a lo
> anterior.
>
>
> Lo que debes hacer es una de estas 2 soluciones:
> - instanciar y crear el formulario cada vez
> - crearlo una vez y establecer su propiedad lHideOnClose = .T. (esto hace
> que el formulario no se destruya al cerrarlo). Y destruirlo al final, en
> el evento OnClose de TMantenimientos.
>
> --
> Un saludo,
>
> José F. Giménez
> http://www.xailer.com
> http://www.xailer.info
>