Xailer & OZ Software

Estimado usuario de Xailer,
La última versión de Xailer 1.1a ha sacado a relucir, debido a la separación
de las clases 'X' y las clases 'T', errores de xHarbour en el tratamiento
del ámbito en miembros de clase cuando estos son accedidos desde un
code-block y hemos decidido anular temporalmente el control de ámbito hasta
que esté corregido. Para ello sólo hace falta incluir el fichero que
adjuntamos con este Email. El resto de ficheros que hemos publicado hoy para
resolver los distintos errores de ámbito ya no son necesarios. Rogamos
disculpen cualquier molestia ocasionada.
Un cordial saludo,
[El equipo de Xailer]
http://www.xailer.com
------------------------------------------------------------ -----------------
Dear Xailer user,
The last Xailer 1.1a version has arise, due the separation of 'X' and 'T'
classes, of some xHarbour bugs on class members scope when they are accessed
from a code-block and we have decided to temporarely cancel the Class scope
control. To make it work you just include the file attached to this message.
The rest of the files published today to solve this same problem are not
necessary. We apologize for any inconvenience.
Best regards,
[Xailer team]
http://www.xailer.com


Attached files application.rar (6.3 KB)Â

TAPPLICATION:INITIALIZE(160)
Error BASE/1605 Invalid self: INITIALIZE
Argumentos: ( [ 1] = Tipo: O Valor: [ 2] = Tipo: O Valor: )
***************************** Registro de errores
*****************************
Fecha: 10/25/06
Hora: 18:11:39
Memoria libre: 617732
Area actual: 1
------------------------- Información del
compilador --------------------------
Versión Xailer: Xailer 1.1.1 Version 1.1a
Compilador: xHarbour build 0.99.61 Intl. (SimpLex) PCode Version: 7
Compilador C/C++: Borland C++ 5.5.1
Plataforma: Windows XP Professional 5.01.2600 Service Pack 2
----------------------- Información detallada del
error -----------------------
Subsistema: BASE
Código de error: 1605
Estado: .F.
Descripción: Invalid self
Operación: INITIALIZE
Argumentos: [ 1] = Tipo: O Valor: [ 2] = Tipo: O Valor:
Fichero:
Código error SO: 0
Pila de llamadas:
TAPPLICATION:INITIALIZE (160)
INITAPPLICATION$ (32)
"Ignacio Ortiz de Zúñiga" <NoName@xailer.com> escribió en el mensaje
news:453f8bdd$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Estimado usuario de Xailer,
>
> La última versión de Xailer 1.1a ha sacado a relucir, debido a la
> separación de las clases 'X' y las clases 'T', errores de xHarbour en el
> tratamiento del ámbito en miembros de clase cuando estos son accedidos
> desde un code-block y hemos decidido anular temporalmente el control de
> ámbito hasta que esté corregido. Para ello sólo hace falta incluir el
> fichero que adjuntamos con este Email. El resto de ficheros que hemos
> publicado hoy para resolver los distintos errores de ámbito ya no son
> necesarios. Rogamos disculpen cualquier molestia ocasionada.
>
> Un cordial saludo,
>
> [El equipo de Xailer]
> http://www.xailer.com
>
> ------------------------------------------------------------ -----------------
>
> Dear Xailer user,
>
> The last Xailer 1.1a version has arise, due the separation of 'X' and 'T'
> classes, of some xHarbour bugs on class members scope when they are
> accessed from a code-block and we have decided to temporarely cancel the
> Class scope control. To make it work you just include the file attached to
> this message. The rest of the files published today to solve this same
> problem are not necessary. We apologize for any inconvenience.
>
> Best regards,
>
> [Xailer team]
> http://www.xailer.com
>
>
>
>

José Luis,
¿Te ocurre con cualquier ejemplo?
Gracias
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"José Luis Capel" <jose.luis@iaicom.com> escribió en el mensaje
news:[email=453f8cc1@news.xailer.com...]453f8cc1@news.xailer.com...[/email]
> TAPPLICATION:INITIALIZE(160)
> Error BASE/1605 Invalid self: INITIALIZE
> Argumentos: ( [ 1] = Tipo: O Valor: [ 2] = Tipo: O Valor: )
>
> ***************************** Registro de errores
> *****************************
>
> Fecha: 10/25/06
> Hora: 18:11:39
> Memoria libre: 617732
> Area actual: 1
>
> ------------------------- Información del
> compilador --------------------------
>
> Versión Xailer: Xailer 1.1.1 Version 1.1a
> Compilador: xHarbour build 0.99.61 Intl. (SimpLex) PCode Version: 7
> Compilador C/C++: Borland C++ 5.5.1
> Plataforma: Windows XP Professional 5.01.2600 Service Pack 2
>
> ----------------------- Información detallada del
> error -----------------------
>
> Subsistema: BASE
> Código de error: 1605
> Estado: .F.
> Descripción: Invalid self
> Operación: INITIALIZE
> Argumentos: [ 1] = Tipo: O Valor: [ 2] = Tipo: O Valor:
> Fichero:
> Código error SO: 0
>
> Pila de llamadas:
> TAPPLICATION:INITIALIZE (160)
> INITAPPLICATION$ (32)
>
>
>
> "Ignacio Ortiz de Zúñiga" <NoName@xailer.com> escribió en el mensaje
> news:453f8bdd$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
>> Estimado usuario de Xailer,
>>
>> La última versión de Xailer 1.1a ha sacado a relucir, debido a la
>> separación de las clases 'X' y las clases 'T', errores de xHarbour en el
>> tratamiento del ámbito en miembros de clase cuando estos son accedidos
>> desde un code-block y hemos decidido anular temporalmente el control de
>> ámbito hasta que esté corregido. Para ello sólo hace falta incluir el
>> fichero que adjuntamos con este Email. El resto de ficheros que hemos
>> publicado hoy para resolver los distintos errores de ámbito ya no son
>> necesarios. Rogamos disculpen cualquier molestia ocasionada.
>>
>> Un cordial saludo,
>>
>> [El equipo de Xailer]
>> http://www.xailer.com
>>
>> ------------------------------------------------------------ -----------------
>>
>> Dear Xailer user,
>>
>> The last Xailer 1.1a version has arise, due the separation of 'X' and 'T'
>> classes, of some xHarbour bugs on class members scope when they are
>> accessed from a code-block and we have decided to temporarely cancel the
>> Class scope control. To make it work you just include the file attached
>> to this message. The rest of the files published today to solve this same
>> problem are not necessary. We apologize for any inconvenience.
>>
>> Best regards,
>>
>> [Xailer team]
>> http://www.xailer.com
>>
>>
>>
>>
>
>

Ignacio yo también he tenido muchos problemas con la declaración INLINE
de los métodos, te recomiendo que los quites y con ello además de
seguridad, ganarás en velocidad... Quitar el control de ámbito en un IDE
que va a funcionar en Windows es un poco peligroso incluso temporalmente...
Saludos
Ignacio Ortiz de Zúñiga escribió:
> Estimado usuario de Xailer,
>
> La última versión de Xailer 1.1a ha sacado a relucir, debido a la separación
> de las clases 'X' y las clases 'T', errores de xHarbour en el tratamiento
> del ámbito en miembros de clase cuando estos son accedidos desde un
> code-block y hemos decidido anular temporalmente el control de ámbito hasta
> que esté corregido. Para ello sólo hace falta incluir el fichero que
> adjuntamos con este Email. El resto de ficheros que hemos publicado hoy para
> resolver los distintos errores de ámbito ya no son necesarios. Rogamos
> disculpen cualquier molestia ocasionada.
>
> Un cordial saludo,
>
> [El equipo de Xailer]
> http://www.xailer.com
>
> ------------------------------------------------------------ -----------------
>
> Dear Xailer user,
>
> The last Xailer 1.1a version has arise, due the separation of 'X' and 'T'
> classes, of some xHarbour bugs on class members scope when they are accessed
> from a code-block and we have decided to temporarely cancel the Class scope
> control. To make it work you just include the file attached to this message.
> The rest of the files published today to solve this same problem are not
> necessary. We apologize for any inconvenience.
>
> Best regards,
>
> [Xailer team]
> http://www.xailer.com
>
>
>

Ignacio,
>
> ¿Te ocurre con cualquier ejemplo?
>
He añadido el application.obj a la lib y asunto solucionado.
Saludos,
José Luis Capel

Manu,
Gracias por tus sugerencias. Precisamente José Giménez ya ha comentado en
varias ocasiones y foros sobre la lentitud de los INLINE, pero en
determinadas ocasiones no merece la pena desarrollarlo aparte, por
simplicidad y poco impacto en la velocidad.
En cuanto al tema de la seguridad en mi opinión exageras, ya que aunque es
posible que un usuario modifique el valor de una data protected, es poco
probable que lo haga porque entre otras cosas no está publicado ningún
fuente de Xailer. Lo que si es posible, y ha ocurrido alguna vez es que un
usuario cree una data para un formulario cuyo nombre coincide con un miembro
protected de la propia clase TForm o sus ancestras. Pero desgraciadamente
este problema no se resuelve con el control de ámbito. Por cierto, que este
problema no lo tiene el nuevo motor OOP de Harbour.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Manu" <manuexposito@terra.es> escribió en el mensaje
news:453f9642$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Ignacio yo también he tenido muchos problemas con la declaración INLINE de
> los métodos, te recomiendo que los quites y con ello además de seguridad,
> ganarás en velocidad... Quitar el control de ámbito en un IDE que va a
> funcionar en Windows es un poco peligroso incluso temporalmente...
>
> Saludos
>
> Ignacio Ortiz de Zúñiga escribió:
>> Estimado usuario de Xailer,
>>
>> La última versión de Xailer 1.1a ha sacado a relucir, debido a la
>> separación de las clases 'X' y las clases 'T', errores de xHarbour en el
>> tratamiento del ámbito en miembros de clase cuando estos son accedidos
>> desde un code-block y hemos decidido anular temporalmente el control de
>> ámbito hasta que esté corregido. Para ello sólo hace falta incluir el
>> fichero que adjuntamos con este Email. El resto de ficheros que hemos
>> publicado hoy para resolver los distintos errores de ámbito ya no son
>> necesarios. Rogamos disculpen cualquier molestia ocasionada.
>>
>> Un cordial saludo,
>>
>> [El equipo de Xailer]
>> http://www.xailer.com
>>
>> ------------------------------------------------------------ -----------------
>>
>> Dear Xailer user,
>>
>> The last Xailer 1.1a version has arise, due the separation of 'X' and 'T'
>> classes, of some xHarbour bugs on class members scope when they are
>> accessed from a code-block and we have decided to temporarely cancel the
>> Class scope control. To make it work you just include the file attached
>> to this message. The rest of the files published today to solve this same
>> problem are not necessary. We apologize for any inconvenience.
>>
>> Best regards,
>>
>> [Xailer team]
>> http://www.xailer.com
>>
>>

Manu,
> Quitar el control de ámbito en un IDE que va a funcionar en Windows es un
> poco peligroso incluso temporalmente...
Ta's pasao! Si eso es tan peligroso como dices, ¿cómo es que Harbour NO ha
tenido control de ámbito hasta hace cuatro días? ¿Quieres decir que los
programas hechos con Harbour + algún GUI para windows son muy peligrosos?
--
Un saludo,
José F. Giménez
http://www.xailer.com

Perdonar pero antes de equivocarme prefiero hacer la pregunta.
¿Meter el fichero application.obj dentro de Xailer.lib?
¿O añadir application.obj en el proyecto de momento?
Saludos.
José Ramón Castro.
Ignacio Ortiz de Zúñiga escribió:
> Estimado usuario de Xailer,
>
> La última versión de Xailer 1.1a ha sacado a relucir, debido a la separación
> de las clases 'X' y las clases 'T', errores de xHarbour en el tratamiento
> del ámbito en miembros de clase cuando estos son accedidos desde un
> code-block y hemos decidido anular temporalmente el control de ámbito hasta
> que esté corregido. Para ello sólo hace falta incluir el fichero que
> adjuntamos con este Email. El resto de ficheros que hemos publicado hoy para
> resolver los distintos errores de ámbito ya no son necesarios. Rogamos
> disculpen cualquier molestia ocasionada.
>
> Un cordial saludo,
>
> [El equipo de Xailer]
> http://www.xailer.com
>
> ------------------------------------------------------------ -----------------
>
> Dear Xailer user,
>
> The last Xailer 1.1a version has arise, due the separation of 'X' and 'T'
> classes, of some xHarbour bugs on class members scope when they are accessed
> from a code-block and we have decided to temporarely cancel the Class scope
> control. To make it work you just include the file attached to this message.
> The rest of the files published today to solve this same problem are not
> necessary. We apologize for any inconvenience.
>
> Best regards,
>
> [Xailer team]
> http://www.xailer.com
>
>
>

José Ramón,
> Perdonar pero antes de equivocarme prefiero hacer la pregunta.
>
> ¿Meter el fichero application.obj dentro de Xailer.lib?
>
> ¿O añadir application.obj en el proyecto de momento?
Es mejor meterlo en xailer.lib, pero si no sabes cómo hacerlo también puedes
añadirlo al proyecto.
--
Un saludo,
José F. Giménez
http://www.xailer.com

Saludos:
No es que no sepa como meterlo pero necesito saber si sustituye a otra
que ya existe o es nueva
Ya que lo he intentado meter así­ : tlib xailer -+application y me dice
que no existe application en la librerí­a xailer.
Si fuera un modulo nuevo en la librerí­a xailer la tendrí­a que meter así­
: tlib xailer +application
Por eso mi pregunta.
José Ramón Castro.
Jose F. Gimenez escribió:
> José Ramón,
>
>> Perdonar pero antes de equivocarme prefiero hacer la pregunta.
>>
>> ¿Meter el fichero application.obj dentro de Xailer.lib?
>>
>> ¿O añadir application.obj en el proyecto de momento?
>
> Es mejor meterlo en xailer.lib, pero si no sabes cómo hacerlo también puedes
> añadirlo al proyecto.
>

Bueno me gusta más lo que comenta Ignacio...
Tu sabes que hay datos que modifican el comportamiento de Windows, me
refiero a controles, y que los salva el propio Windows. Normalmente lo
que se hace para tratarlo como una DATA es guardar el valor del
resultado de ejecutar una función GET de windows de "esos datos" en
dicha DATA, Delphi empiezan F..., que deberí­a estar oculta lógicamente,
ya que para asignarle el valor a windows habrí­a que usar la función SET
y actualizar la DATA de nuestra clase... me referí­a a eso.
Sólo querí­a comentarlo... por eso digo que es un "poco peligroso". A
estas alturas de la pelí­cula creo que nadie cometerá el error de usas
una data de esas... digo yo!!!
Manu
Jose F. Gimenez escribió:
> Manu,
>
>> Quitar el control de ámbito en un IDE que va a funcionar en Windows es un
>> poco peligroso incluso temporalmente...
>
> Ta's pasao! Si eso es tan peligroso como dices, ¿cómo es que Harbour NO ha
> tenido control de ámbito hasta hace cuatro dí­as? ¿Quieres decir que los
> programas hechos con Harbour + algún GUI para windows son muy peligrosos?
>

Jose Ramon
es un módulo que ya existe en la LiB de Xailer, por lo que debe de ser
sustituido.
Yo lo he hecho así y funciona PERFECTO
C:XailerBorlandbcc55bintlib C:XailerLibxailer -+Directoriodel
OBJasustituirApplication
Un Saludo,
Xevi.
"José Ramón Castro Polinio" <jrcpoli@terra.es> ha escrit al missatge del
grup de discussió: [email=453fd9e1@news.xailer.com...]453fd9e1@news.xailer.com...[/email]
> Saludos:
>
> No es que no sepa como meterlo pero necesito saber si sustituye a otra que
> ya existe o es nueva
>
> Ya que lo he intentado meter así : tlib xailer -+application y me dice
> que no existe application en la librería xailer.
>
> Si fuera un modulo nuevo en la librería xailer la tendría que meter así :
> tlib xailer +application
>
> Por eso mi pregunta.
>
> José Ramón Castro.
>
> Jose F. Gimenez escribió:
>> José Ramón,
>>
>>> Perdonar pero antes de equivocarme prefiero hacer la pregunta.
>>>
>>> ¿Meter el fichero application.obj dentro de Xailer.lib?
>>>
>>> ¿O añadir application.obj en el proyecto de momento?
>>
>> Es mejor meterlo en xailer.lib, pero si no sabes cómo hacerlo también
>> puedes añadirlo al proyecto.
>>

Manu,
> Tu sabes que hay datos que modifican el comportamiento de Windows, me
> refiero a controles, y que los salva el propio Windows. Normalmente lo que
> se hace para tratarlo como una DATA es guardar el valor del resultado de
> ejecutar una función GET de windows de "esos datos" en dicha DATA, Delphi
> empiezan F..., que debería estar oculta lógicamente, ya que para asignarle
> el valor a windows habría que usar la función SET y actualizar la DATA de
> nuestra clase... me refería a eso.
> Sólo quería comentarlo... por eso digo que es un "poco peligroso". A estas
> alturas de la película creo que nadie cometerá el error de usas una data
> de esas... digo yo!!!
Vamos a ver, estoy de acuerdo en que si alguien intenta usar las "datas
internas" directamente, pues se va a liar la de Troya, pero es que ese mismo
problema existía anteriormente, tanto si se desactiva el 'scoping' como si
no. Y si no te habías dado cuenta, prueba a añadir este código a cualquier
programa:
CLASS TControl FROM XControl
DATA cText
ENDCLASS
ya verás lo divertido que puede llegar a ser algo tan "inocente"
Quizás el hecho de desactivar el 'scoping' sólo ha sacado a relucir los
problemas del diseño del motor de objetos de [x]Harbour. Pero esos problemas
siempre han estado ahí, no son nuevos.
Aún así, no todo van a ser malas noticias... por lo que he podido leer
últimamente en la lista de Harbour, Przemek hay hecho cambios sustanciales
en el motor de objetos (y ha indicado su intención de hacer los mismos
cambios en xHarbour próximamente), que van a paliar parte de esos problemas.
P.ej., los miembros 'private' de las clases van a ser verdaderamente
privados, y si una clase hija declara algún miembro con el mismo nombre, lo
tratará como un miembro nuevo y completamente independiente del de la clase
padre; esto va a permitir, entre otras cosas, que exista una verdadera
protección de los miembros de una clase frente a sus clases hijas, que ahora
mismo no existe.
--
Un saludo,
José F. Giménez
http://www.xailer.com

Eso está super bien!!!
Esperemos que lo haga pronto y que Walter lo pueda revisar, un motor OOP
sin control de ámbitos es un poco menos OOP.
Gracias por tu información, como siempre, es muy buena y bienvenida...
Mañana viernes me voy a Córdoba, el lunes a Cádiz... el dí­a que me toque
por Almerí­a me gustarí­a tomarme una cervecita contigo si te apetece, vale?
Manu
Jose F. Gimenez escribió:
> Manu,
>
>> Tu sabes que hay datos que modifican el comportamiento de Windows, me
>> refiero a controles, y que los salva el propio Windows. Normalmente lo que
>> se hace para tratarlo como una DATA es guardar el valor del resultado de
>> ejecutar una función GET de windows de "esos datos" en dicha DATA, Delphi
>> empiezan F..., que deberí­a estar oculta lógicamente, ya que para asignarle
>> el valor a windows habrí­a que usar la función SET y actualizar la DATA de
>> nuestra clase... me referí­a a eso.
>> Sólo querí­a comentarlo... por eso digo que es un "poco peligroso". A estas
>> alturas de la pelí­cula creo que nadie cometerá el error de usas una data
>> de esas... digo yo!!!
>
> Vamos a ver, estoy de acuerdo en que si alguien intenta usar las "datas
> internas" directamente, pues se va a liar la de Troya, pero es que ese mismo
> problema existí­a anteriormente, tanto si se desactiva el 'scoping' como si
> no. Y si no te habí­as dado cuenta, prueba a añadir este código a cualquier
> programa:
>
> CLASS TControl FROM XControl
> DATA cText
> ENDCLASS
>
> ya verás lo divertido que puede llegar a ser algo tan "inocente"
>
> Quizás el hecho de desactivar el 'scoping' sólo ha sacado a relucir los
> problemas del diseño del motor de objetos de [x]Harbour. Pero esos problemas
> siempre han estado ahí­, no son nuevos.
>
> Aún así­, no todo van a ser malas noticias... por lo que he podido leer
> últimamente en la lista de Harbour, Przemek hay hecho cambios sustanciales
> en el motor de objetos (y ha indicado su intención de hacer los mismos
> cambios en xHarbour próximamente), que van a paliar parte de esos problemas.
> P.ej., los miembros 'private' de las clases van a ser verdaderamente
> privados, y si una clase hija declara algún miembro con el mismo nombre, lo
> tratará como un miembro nuevo y completamente independiente del de la clase
> padre; esto va a permitir, entre otras cosas, que exista una verdadera
> protección de los miembros de una clase frente a sus clases hijas, que ahora
> mismo no existe.
>

Manu,
> Mañana viernes me voy a Córdoba, el lunes a Cádiz... el día que me toque
> por Almería me gustaría tomarme una cervecita contigo si te apetece, vale?
Pero no hagas como siempre... que pasas por aquí sin decir ni pio
--
Un saludo,
José F. Giménez
http://www.xailer.com

Si no me falla la memoria estaré por ahí­ el 13 de Noviembre por la tarde
y me iré al dí­a siguiente después de comer con la gente de la Junta de
Andalucí­a de las UTEDLT de la provincia de Almerí­a. Pienso que lo mejor
serí­a quedar el 13 por la noche
Ya te aviso para decirte el hotel donde me alojaré...
Manu
Jose F. Gimenez escribió:
> Manu,
>
>> Mañana viernes me voy a Córdoba, el lunes a Cádiz... el dí­a que me toque
>> por Almerí­a me gustarí­a tomarme una cervecita contigo si te apetece, vale?
>
> Pero no hagas como siempre... que pasas por aquí­ sin decir ni pio
>