Xailer & OZ Software

Al abandonar un Form (en mi caso el de TLOGIN) pulsando Esc teniendo el foco el tí­pico botón de Cancelar con su bitmap aparece
el siguiente error.-
(b)XBTNBMP:XBTNBMP(41)
Error BASE/1004 Scope Violation <PROTECTED>: FOBITMAPS
Argumentos: ( [ 1] = Tipo: O Valor: )
Pila de llamadas:
(b)XBTNBMP:XBTNBMP (41)
TBTNBMP:FREE (0)
TBTNBMP:WMNCDESTROY (918)
SENDMESSAGE (0)
(b)XCONTROL:XCONTROL (91)
TLOGIN:SENDMSG (0)
(b)XFORM:XFORM (115)
TLOGIN:CLOSE (0)
TBTNBMP:CLICK (104)
TLOGIN:WMKEYDOWN (573)
TWINCONTROL:WMKEYDOWN (955)
TFOLDER:WMKEYDOWN (449)
TFOLDERPAGE:WMKEYDOWN (955)
TSTDCONTROL:WMKEYDOWN (955)
TBTNBMP:WMKEYDOWN (171)
TLOGIN:SHOWMODAL (0)
INITMASTER (53)
MAIN (27)
Consigo corregirlo con.-
CLASS TBtnBmp FROM XBtnBmp
METHOD Free() INLINE IIf( ! Empty( ::FoBitmaps ) .AND. ::FoBitmaps:oParent == Self, ::FoBitmaps:End(), ), Super:Free()
ENDCLASS
Sin el RESERVED:
Espero que las modificaciones al motor de objetos no afecten a la posibilidad de realizar este tipo de correcciones tanto en la
capa x Harbour como C. Se siga manteniendo la derivación TClase => XClase y en mi humilde opinión se utilicen los ámbitos
privativos lo estrictamente necesario ya que, por definición, restan funcionalidad y posibilidades de cambio.
Un saludo
Xavi

Xavi,
Confirmanos que es la versión 1.75. Como ya hemos comentado existe un
problema en el propio xHarbour en el Scoping de clases. Si fuera con la
versión 1.6? te agredecería que nos mandases un ejemplo que reproduzca el
error.
Un saludo,
"xAvi" <[email=x_@_com]x_@_com[/email]> escribió en el mensaje
news:46f94ad4$[email=2@ozsrv2.ozlan.local...]2@ozsrv2.ozlan.local...[/email]
> Al abandonar un Form (en mi caso el de TLOGIN) pulsando Esc teniendo el
> foco el típico botón de Cancelar con su bitmap aparece el siguiente
> error.-
>
> (b)XBTNBMP:XBTNBMP(41)
> Error BASE/1004 Scope Violation <PROTECTED>: FOBITMAPS
> Argumentos: ( [ 1] = Tipo: O Valor: )
>
> Pila de llamadas:
> (b)XBTNBMP:XBTNBMP (41)
> TBTNBMP:FREE (0)
> TBTNBMP:WMNCDESTROY (918)
> SENDMESSAGE (0)
> (b)XCONTROL:XCONTROL (91)
> TLOGIN:SENDMSG (0)
> (b)XFORM:XFORM (115)
> TLOGIN:CLOSE (0)
> TBTNBMP:CLICK (104)
> TLOGIN:WMKEYDOWN (573)
> TWINCONTROL:WMKEYDOWN (955)
> TFOLDER:WMKEYDOWN (449)
> TFOLDERPAGE:WMKEYDOWN (955)
> TSTDCONTROL:WMKEYDOWN (955)
> TBTNBMP:WMKEYDOWN (171)
> TLOGIN:SHOWMODAL (0)
> INITMASTER (53)
> MAIN (27)
>
> Consigo corregirlo con.-
> CLASS TBtnBmp FROM XBtnBmp
> METHOD Free() INLINE IIf( ! Empty( ::FoBitmaps ) .AND.
> ::FoBitmaps:oParent == Self, ::FoBitmaps:End(), ), Super:Free()
> ENDCLASS
>
> Sin el RESERVED:
> Espero que las modificaciones al motor de objetos no afecten a la
> posibilidad de realizar este tipo de correcciones tanto en la capa x
> Harbour como C. Se siga manteniendo la derivación TClase => XClase y en mi
> humilde opinión se utilicen los ámbitos privativos lo estrictamente
> necesario ya que, por definición, restan funcionalidad y posibilidades de
> cambio.
>
> Un saludo
> Xavi

Ignacio Ortiz de Zúñiga escribió:
> Confirmanos que es la versión 1.75.
Si es la 1.75, perdón por no incluir la Información del compilador.-
Versión Xailer: Xailer 1.7.5 Version 1.75
Compilador: xHarbour build 0.99.80 Intl. (SimpLex) PCode Version: 9
Compilador C/C++: Borland C++ 5.5.1
Plataforma: Windows 2000 Professional 5.00.2195 Service Pack 4
He activado la 1.6.5 para realizar la prueba y no da el error.-
Versión Xailer: Xailer 1.6.5 Version 1.65
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
Mi versión de trabajo continua siendo la 1.75 con xHarbour build 0.99.80 debido a que no es compatible el PCode y al igual que
pasa con Xailer.lib añade complejidad al desarrollo.
También he notado un aumento significativo de los tiempos de compilación de la versión 0.99.61 a la 0.99.80.
Un saludo
Xavi

Xavi,
> Mi versión de trabajo continua siendo la 1.75 con xHarbour build 0.99.80
> debido a que no es compatible el PCode y al igual que pasa con Xailer.lib
> añade complejidad al desarrollo.
> También he notado un aumento significativo de los tiempos de compilación
> de la versión 0.99.61 a la 0.99.80.
Si no te importa probar esta versión de xHarbour, te podría enviar mañana un
nuevo instalable que soluciona ese problema. Pero eso sí, no se debe usar en
producción, ya que hay que probarlo muy bien porque puede tener otros bugs.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Jose F. Gimenez escribió:
> Si no te importa probar esta versión de xHarbour, te podrí­a enviar mañana un
> nuevo instalable que soluciona ese problema. Pero eso sí­, no se debe usar en
> producción, ya que hay que probarlo muy bien porque puede tener otros bugs.
No en absoluto, tenia previsto compilarlo yo pero por falta de tiempo para el CVS pues eso.
Un saludo
Xavi
jarabal@gmail.com

Xavi,
> También he notado un aumento significativo de los tiempos de compilación
> de la versión 0.99.61 a la 0.99.80.
Efectivamente así es. Supongo que es debido al completo cambio del
preprocesador que se ha hecho. El inicial de Alexander Kressin era bastante
más rápido. El actual, que es trabajo de Prezmyak (seguro que está mal
escrito) en principio es mucho más seguro y libre de errores, pero no tiene
la misma velocidad.
Curiosamente ni en el foro de xHarbour, ni en la lista de desarrolladores se
ha comentado nada al respecto.
Un saludo,

Xavi,
> No en absoluto, tenia previsto compilarlo yo pero por falta de tiempo para
> el CVS pues eso.
Lo puedes descargar desde http://www.xailer.com/files/xharboursetup.exe.
Si en cualquier momento quieres descargar xHarbour desde el CVS y compilarlo
tú, revisa primero el fichero leeme.txt de nuestros binarios, porque hay un
par de modificaciones en los fuentes que debes incorporar para que Xailer
funcione correctamente.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Jose F. Gimenez escribió:
> Si en cualquier momento quieres descargar xHarbour desde el CVS y compilarlo
> tú, revisa primero el fichero leeme.txt de nuestros binarios, porque hay un
> par de modificaciones en los fuentes que debes incorporar para que Xailer
> funcione correctamente.
He conseguido conectar al CVS con el Tortoise 1.8.31 como "anonymus" y compilarlo con Bison 1.24, pero me está armando la
00.99.71. No sé, supongo que debo indicarle otro módulo diferente a xharbour pero no se cual.
¿ No serí­a más fácil y práctico que subierais a vuestro servidor un zip con las fuentes que utilizáis para generar xharbour
óptimo de Xailer y a medida que éste (el de Xailer) vaya cambiando, cambiar las fuentes al igual que se hace con xharboursetup ?
Creo que serí­a un buen punto de partida para mirarlo porque de lo que se trata es de utilizarlo con Xailer.
Un saludo.
Xavi

Ignacio Ortiz de Zúñiga escribió:
> Efectivamente así­ es. Supongo que es debido al completo cambio del
> preprocesador que se ha hecho. El inicial de Alexander Kressin era bastante
> más rápido. El actual, que es trabajo de Prezmyak (seguro que está mal
> escrito) en principio es mucho más seguro y libre de errores, pero no tiene
> la misma velocidad.
Estoy deseando ver las nuevas fuentes, porque las que tengo de Przemek (bien escrito) Harbour Beta build 0.99-0.-
ch = fgetc( pState->pFile->file_in );
Un saludo
Xavi

Jose F. Gimenez escribió:
> Lo puedes descargar desde http://www.xailer.com/files/xharboursetup.exe.
Con el descargado, supongo que es lo mismo pero en METHOD.
CLASS TStatusBar FROM XStatusBar
METHOD UpdatePanels( lOnlyText )
ENDCLASS
METHOD UpdatePanels( lOnlyText ) CLASS TStatusBar
...
RETURN Super:UpdatePanels( lOnlyText )
Provoca error de Scope Violation: UpdatePanels() de XStatusBar (Super) llama a su SetParts() que es private.
Le empasto temporalmente SetParts() para corregir el problema.
Un saludo
Xavi
PD: José, Ignacio, Agradecerí­a alguna respuesta a la propuesta de subir las fuentes utilizadas porque si no parece que moleste y
tampoco es mi intención.

Xevi,
Toda la información necesaria para utilizar la versión del CVS ya se entrega
en nuestra propio distribución de xHarbour desde hace tiempo. Leete el
fichero 'xHarbour leeme.txt'.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"xAvi" <[email=x_@_com]x_@_com[/email]> escribió en el mensaje
news:470191be$[email=1@ozsrv2.ozlan.local...]1@ozsrv2.ozlan.local...[/email]
> Jose F. Gimenez escribió:
>> Lo puedes descargar desde http://www.xailer.com/files/xharboursetup.exe.
>
> Con el descargado, supongo que es lo mismo pero en METHOD.
>
> CLASS TStatusBar FROM XStatusBar
> METHOD UpdatePanels( lOnlyText )
> ENDCLASS
>
> METHOD UpdatePanels( lOnlyText ) CLASS TStatusBar
> ...
> RETURN Super:UpdatePanels( lOnlyText )
>
> Provoca error de Scope Violation: UpdatePanels() de XStatusBar (Super)
> llama a su SetParts() que es private.
> Le empasto temporalmente SetParts() para corregir el problema.
>
> Un saludo
> Xavi
> PD: José, Ignacio, Agradecería alguna respuesta a la propuesta de subir
> las fuentes utilizadas porque si no parece que moleste y tampoco es mi
> intención.

Xavi,
>> Lo puedes descargar desde http://www.xailer.com/files/xharboursetup.exe.
>
> Con el descargado, supongo que es lo mismo pero en METHOD.
No, no es lo mismo. El enlace anterior contiene una versión de xHarbour
'parcheada' con un par de modificaciones que corrigen este problema. Si has
descargado los fuentes de xHarbour del CVS, tendrás que añadir esas dos
modificaciones antes de compilarlo para que funcione. Revisa el fichero
leeme.txt de nuestro xHarbour, que indica qué módulos se han tocado. Por
supuesto, dichos módulos están incluidos en la instalación.
> CLASS TStatusBar FROM XStatusBar
> METHOD UpdatePanels( lOnlyText )
> ENDCLASS
>
> METHOD UpdatePanels( lOnlyText ) CLASS TStatusBar
> ...
> RETURN Super:UpdatePanels( lOnlyText )
>
> Provoca error de Scope Violation: UpdatePanels() de XStatusBar (Super)
> llama a su SetParts() que es private.
> Le empasto temporalmente SetParts() para corregir el problema.
No hay que corregir nada. Es correcto que SetParts() sea private, puesto que
sólo se llama desde la propia clase.
> PD: José, Ignacio, Agradecería alguna respuesta a la propuesta de subir
> las fuentes utilizadas porque si no parece que moleste y tampoco es mi
> intención.
No, no es ninguna molestia. Tenemos que estudiar si vale la pena tener una
copia de los fuentes de xHarbour en nuestra web, ya que todos los fuentes
están disponibles desde el CVS del proyecto. Y las modificaciones que
nosotros hagamos para nuestra distribución están incluidas en la misma, e
indicadas en los ficheros leeme.txt y readme.txt
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

José,
Gracias.
Te estoy informando de los errores de Scope Violation que me produce la 1.75 de Xailer con el xharbor 'parcheado', descargado
del enlace, por si pueden servirte de ayuda. También te indico lo que hago para poder seguir trabajando con esta versión (1.75)
en mi aplicación por si influye o infiere en los errores. En el caso de XStatusBar, si no le pego SetParts() en mi clase
TStatusBar de la aplicación no me deja seguir adelante ya que siempre me saldrí­a el error de Scope Violation obligándome a
abandonar la ejecución.
Lo mismo me ocurre con la clase XScrollingWinControl, si no le pongo el siguiente código en mi aplicación creando una
TScrollingWinControl me provoca un error de Scope Violation que no se producí­a en versiones anteriores.
CLASS TScrollingWinControl FROM XScrollingWinControl
DATA nExtraHeight INIT 0
DATA nExtraWidth INIT 0
METHOD ProcessControl( oControl )
ENDCLASS
METHOD ProcessControl( oControl ) CLASS TScrollingWinControl
...
AQUí VA EL CUT & PASTE DE LAS FUENTES ORIGINALES PARA EVITAR COPIARLAS AL POST
...
RETURN Nil
No sé si he conseguido explicarme bien, si consideras que puedo hacer o decir algo más dí­melo.
Supongo que todo esto no harí­a falta si compilara con la versión anterior de Xailer 1.6? y utilizando el xharbor de vuestra
distribución o el 0.99.70 estable de http://www.xharbour.org/index.asp?page=download/sources compilado con vuestros cambios y
que ya tení­a presente, pero el cambio de PCode hace que las posibles modificaciones no sean compatibles con la librerí­a en el
futuro.
> Tenemos que estudiar si vale la pena tener una
> copia de los fuentes de xHarbour en nuestra web, ya que todos los fuentes
> están disponibles desde el CVS del proyecto. Y las modificaciones que
> nosotros hagamos para nuestra distribución están incluidas en la misma, e
> indicadas en los ficheros leeme.txt y readme.txt
Existen algunas modificaciones a funciones de xharbour como Transform() y otras que aumentan considerablemente las prestaciones
de mi aplicación final sin perder la compatibilidad con el original y facilitan el trabajo con Xailer al no tener que
sobrecargar eventos como OnGetData() por ejemplo. De ahí­ la importancia de disponer de una versión estable de xharbour que
perdure algún tiempo para no estar constantemente cambiando la versión de trabajo. Exactamente igual que con las versiones de
xharbour que distribuis, motivo por el cual, si facilitarais las fuentes de la distribución, ahorrarí­ais trabajo a todos los que
desearan modificarlas ya que sólo tendrí­an que modificar dichas fuentes que irí­an parejas con la versión de "Xailer.lib"
utilizada. Por otra parte estarí­an seguros de que se trabaja sobre las mismas fuentes a la hora de informar sobre los posibles
errores o mejoras. Xailer es la GUI de la aplicación sobre xharbour con lo que yo no concibo una cosa sin la otra. Espero que
otros desarrolladores con esta maravillosa herramienta valoren esta posibilidad.
El CVS está muy bien pero obliga a seguirlo por la lista de desarrollo que a diferencia del proyecto Harbour está cerrada y la
cuenta de acceso join@xharbour.org inoperante desde hace tiempo.
Gracias por tu tiempo.
Un saludo
Xavi
PD: Perdón por el "pedazo post que me ha salido", espero haberme explicado bien.

Xavi,
> Te estoy informando de los errores de Scope Violation que me produce la
> 1.75 de Xailer con el xharbor 'parcheado', descargado del enlace, por si
> pueden servirte de ayuda.
Tienes razón, perdona. Acabo de probarlo y efectívamente se produce el
error, aunque no debería producirse. Parece que xHarbour sigue teniendo
problemas con los 'scope' en determinados casos. Vamos a seguir
investigándolo.
> También te indico lo que hago para poder seguir trabajando con esta
> versión (1.75) en mi aplicación por si influye o infiere en los errores.
> En el caso de XStatusBar, si no le pego SetParts() en mi clase TStatusBar
> de la aplicación no me deja seguir adelante ya que siempre me saldría el
> error de Scope Violation obligándome a abandonar la ejecución.
Como solución temporal está bien. Pero cuando xHarbour funcione bien del
todo deberías deshacer ese cambio.
> Lo mismo me ocurre con la clase XScrollingWinControl, si no le pongo el
> siguiente código en mi aplicación creando una TScrollingWinControl me
> provoca un error de Scope Violation que no se producía en versiones
> anteriores.
>
> CLASS TScrollingWinControl FROM XScrollingWinControl
> DATA nExtraHeight INIT 0
> DATA nExtraWidth INIT 0
>
> METHOD ProcessControl( oControl )
> ENDCLASS
>
> METHOD ProcessControl( oControl ) CLASS TScrollingWinControl
> ...
> AQUÍ VA EL CUT & PASTE DE LAS FUENTES ORIGINALES PARA EVITAR COPIARLAS AL
> POST
> ...
> RETURN Nil
Este caso es distinto, ya que en el código que as pegado en la clase hija
hay referencias a DATAs de la clase padre que son PRIVATE, y es correcto que
se produzca el error. Al redeclarar esas DATAs en la clase hija estás
evitando el error ya que a partir de ese momento son accesibles también
desde la clase hija.
No obstante, me gustaría hacer una aclaración al respecto. Esta técnica de
redeclarar miembros privados en las clases hijas para poder acceder a ellos
funciona, pero es muy posible que deje de funcionar en el futuro. Uno de los
cambios que se preven en el motor de objetos de xHarbour (al igual que han
hecho en Harbour) consiste en que los miembros privados son realmente
privados, y si una clase hija redeclara uno de estos miembros, en realidad
estaría creando uno completamente nuevo, aunque tenga el mismo nombre. Así
es también como se comportan algunos otros lenguajes.
> No sé si he conseguido explicarme bien, si consideras que puedo hacer o
> decir algo más dímelo.
Sí, te has explicado bien. El problema fue que yo no me dí cuenta de que
estabas desarrollando la clase T.
> Supongo que todo esto no haría falta si compilara con la versión anterior
> de Xailer 1.6? y utilizando el xharbor de vuestra distribución o el
> 0.99.70 estable de http://www.xharbour.org/index.asp?page=download/sources
> compilado con vuestros cambios y que ya tenía presente, pero el cambio de
> PCode hace que las posibles modificaciones no sean compatibles con la
> librería en el futuro.
Sí, es cierto. Pero debido a las mejoras que se han hecho en xHarbour,
conviene ir pasando ya a la nueva versión, aunque como ves hay algunos
errores en el compilador que hay que corregir.
> De ahí la importancia de disponer de una versión estable de xharbour que
> perdure algún tiempo para no estar constantemente cambiando la versión de
> trabajo.
Sí, por supuesto. Nuestro objetivo es conseguir una versión lo más estable
posible de xHarbour que dure un tiempo y que permita poner en producción los
programas con toda garantía.
> Por otra parte estarían seguros de que se trabaja sobre las mismas fuentes
> a la hora de informar sobre los posibles errores o mejoras. Xailer es la
> GUI de la aplicación sobre xharbour con lo que yo no concibo una cosa sin
> la otra. Espero que otros desarrolladores con esta maravillosa herramienta
> valoren esta posibilidad.
Bueno, la verdad es que casi todos los programadores de Xailer utilizan
nuestros binarios sin preocuparse del CVS de xHarbour, aunque podrían
hacerlo. Es más, somos de la opinión de que si alguien quiere compilar
xHarbour por su cuenta es totalmente libre de hacerlo, pero lógicamente debe
tener una cierta experiencia tanto con el CVS como con las interioridades
del propio proyecto xHarbour.
> El CVS está muy bien pero obliga a seguirlo por la lista de desarrollo que
> a diferencia del proyecto Harbour está cerrada y la cuenta de acceso
> join@xharbour.org inoperante desde hace tiempo.
Sí, es cierto. No obstante, se pueden seguir los cambios viendo el archivo
changelog, sin necesidad de leer la lista. En la lista se tratan temas
fundamentalmente técnicos y se discute qué hacer y cómo. Yo sería partidario
de permitir el acceso a la lista, aunque fuera solamente en modo lectura,
pero me temo que yo no puedo tomar esa decisión.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Jose F. Gimenez escribió:
> Sí­, es cierto. No obstante, se pueden seguir los cambios viendo el archivo
> changelog, sin necesidad de leer la lista.
>
LO ESCRIBO EN CLAVE DE HUMOR porque de la vida es mejor reí­rse que llorar.
Si no estáis de humor pasar directamente al final.
Narro mis pensamientos y actuaciones tras leer tu post.
Bueno, vale, de acuerdo..., te acepto pulpo como animal de compañí­a.
Instala la tortura (en qué estarí­a pensando) "tortuga", cambio el disco por si acaso, conecta, ..., ¡mierdas no conecta! y ahora
que le pasa (tic, tac, tic, tac, ...) "ANONYMOUS" joer "anonymous". Por fin conecta. Rezo para que no me "change" nada y le doy
a bajar la última versión. (tic, tac, tic, tac, ...) todo verde esto va bien, la última vez me chango un montón de ficheros en
conflicto y ya sé que es imposible pero..., esta vez no me ha pillado.
Revisa el log.-
$Id: ChangeLog,v 1.5731 2007/10/04 11:43:43 modalsist Exp $
Revisa última entrada.-
2007-10-04 08:45 UTC-0300 Eduardo Fernandes <modalsist@yahoo.com.br>
Revisa que no estén "tocados" los archivo de José, parece que no pero ya me duelen los ojos, menos mal que nada más a pasado una
semana. Copia a desarrollo, copia los archivos de José, copia bison, copia el .bat y revisa los sets que sean correctos.
Compila (tic, tac, tic, tac, ...) ¡mierdas no compila! error falta el bison.simplex, como mí­nimo ha servido para ver que hay
sets repetidos con los por defecto.
Corrige el bat y vuelve a compilar (tic, tac, tic, tac, ...)(tic, tac, tic, tac, ...)(...)
Ok. Mira el make log.-
MAKE Version 5.2 Copyright (c) 1987, 2000 Borland
bcc32 -c -Iinclude;sourcecompiler;sourcemacro -d -5 -6 -a8 -O2 -OS -DHB_API_MACROS -DHB_GUI -D__WIN32__
-oobjb32hbfhnd.obj sourcecommonhbfhnd.c
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
sourcecommonhbfhnd.c:
bcc32 -c -Iinclude;sourcecompiler;sourcemacro -d -5 -6 -a8 -O2 -OS -DHB_API_MACROS -DHB_GUI -D__WIN32__
-oobjb32hbfsapi.obj sourcecommonhbfsapi.c
....
....
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
del make.tmp
¡OH ni errores ni avisos, que buenos que son...!
Cambia la raí­z del directorio xharbor del IDE a este, borra el directorio obj de la aplicación y reconstruye.
Ejecuta y ... ¡JOER la primera en la frente!
#1: GPF (Code = c0000005):
Access violation
TAPPLICATION:_AFORMS (0)
TAPPLICATION:INITIALIZE (135)
INITAPPLICATION$ (33)
SI SOLO A PASADO UNA SEMANA!!!
POR QUí‰, DIOS MIO, POR QUí‰ ....
Paso de mirarlo o me dan las tantas.
Me cargo todo el directorio de descarga, vuelvo a la tortuga y le meto versión a fecha 17/09/2007, rezo para que la conserven y
descargo. Miro el changelog y ¡mierdas me baja una de antes! será un bug de la tortuga que le han puesto "mayor que fecha".
Reviso el log de desarrollo y veo que la siguiente entrada es del 21/09/2007. Vuelvo a borrar todo el directorio de descarga, le
meto 21/09/2007 y descargo (tic, tac, tic, tac, ...) todo verde.
Reviso el log y bingo consigo el dí­a deseado. Joer algien más metio algo ese dí­a.-
$Id: ChangeLog,v 1.5705 2007/09/17 13:20:30 ran_go Exp $
2007-09-17 10:20 UTC-0300 Ranier Vilela <ranier/at/cultura.com.br>
....
2007-09-17 09:06 UTC-0300 Luiz Rafael Culik Guimaraes <luiz at xharbour.com.br>
....
2007-09-17 13:30 UTC+0100 Jose F. Gimenez <jfgimenez/at/wanadoo.es>
POR FIN AQUí ESTAS!!!
Ala, repí­telo todo a partir de aquí­.
Rezo y pongo un cirio mental a todos los santos conocidos para no tener que mirar los cambios del dí­a en el código.
Reconstruyo el proyecto y está vez sí­, parece que la aplicación se comporta igual que con la versión 'parcheada'.
A todo esto más de las 6, pero eso es otra historia.
José,
¿Son las mismas fuentes?
¿Si es Open Source, OSI-Approved, que problema hay en entregar un zip con las fuentes de la versión distribuida?
Un saludo
Xavi

Xavi,
Te entiendo perfectamente, y no nos costaría mucho incluir los fuentes. El
problema surge cuando los usuarios desean reconstruir xHarbour en sus
propias máquinas ya que existen un motón de motivos por los cuales el
proceso puede fallar que como comprenderás están fuera del ámbito del
soporte que ofrece Xailer.
El motivo más importante para evitar que cada uno se reconstruya su propia
versión de xHarbour es el de soporte por parte nuestro. Nosotros sólo
podemos responsabilizarnos del correcto funcionamiento de Xailer con las
versiones de xHarbour construidas y publicadas oficialmente por nosotros.
Ell no implica que cualquier usuario pueda crear sus propios binarios de
xHarbour para utilizarlos con Xailer, pero logicamente bajo su única
responsabilidad. Si se produce un error en sus programas ha de probarse su
mal funcionamiento con una versión publicada por Xailer. Espero que lo
entiendas.
En cualquier caso, te aseguro que descargar xHarbour con el CVS Tortoise de
forma anónima es muy sencillo. Contrruir todos los binarios y librerías
puede que se complique algo más.
Un saludo,
"xAvi" <[email=x_@_com]x_@_com[/email]> escribió en el mensaje
news:470793d2$[email=2@ozsrv2.ozlan.local...]2@ozsrv2.ozlan.local...[/email]
> Jose F. Gimenez escribió:
>> Sí, es cierto. No obstante, se pueden seguir los cambios viendo el
>> archivo changelog, sin necesidad de leer la lista.
>>
>
> LO ESCRIBO EN CLAVE DE HUMOR porque de la vida es mejor reírse que llorar.
>
> Si no estáis de humor pasar directamente al final.
>
> Narro mis pensamientos y actuaciones tras leer tu post.
>
> Bueno, vale, de acuerdo..., te acepto pulpo como animal de compañía.
>
> Instala la tortura (en qué estaría pensando) "tortuga", cambio el disco
> por si acaso, conecta, ..., ¡mierdas no conecta! y ahora que le pasa (tic,
> tac, tic, tac, ...) "ANONYMOUS" joer "anonymous". Por fin conecta. Rezo
> para que no me "change" nada y le doy a bajar la última versión. (tic,
> tac, tic, tac, ...) todo verde esto va bien, la última vez me chango un
> montón de ficheros en conflicto y ya sé que es imposible pero..., esta vez
> no me ha pillado.
> Revisa el log.-
> $Id: ChangeLog,v 1.5731 2007/10/04 11:43:43 modalsist Exp $
> Revisa última entrada.-
> 2007-10-04 08:45 UTC-0300 Eduardo Fernandes <modalsist@yahoo.com.br>
> Revisa que no estén "tocados" los archivo de José, parece que no pero ya
> me duelen los ojos, menos mal que nada más a pasado una semana. Copia a
> desarrollo, copia los archivos de José, copia bison, copia el .bat y
> revisa los sets que sean correctos.
> Compila (tic, tac, tic, tac, ...) ¡mierdas no compila! error falta el
> bison.simplex, como mínimo ha servido para ver que hay sets repetidos con
> los por defecto.
> Corrige el bat y vuelve a compilar (tic, tac, tic, tac, ...)(tic, tac,
> tic, tac, ...)(...)
> Ok. Mira el make log.-
> MAKE Version 5.2 Copyright (c) 1987, 2000 Borland
> bcc32 -c -Iinclude;sourcecompiler;sourcemacro -d -5 -6 -a8 -O2 -OS -DHB_API_MACROS
> -DHB_GUI -D__WIN32__ -oobjb32hbfhnd.obj sourcecommonhbfhnd.c
> Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
> sourcecommonhbfhnd.c:
> bcc32 -c -Iinclude;sourcecompiler;sourcemacro -d -5 -6 -a8 -O2 -OS -DHB_API_MACROS
> -DHB_GUI -D__WIN32__ -oobjb32hbfsapi.obj sourcecommonhbfsapi.c
> ...
> ...
> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
> del make.tmp
> ¡OH ni errores ni avisos, que buenos que son...!
>
> Cambia la raíz del directorio xharbor del IDE a este, borra el directorio
> obj de la aplicación y reconstruye.
> Ejecuta y ... ¡JOER la primera en la frente!
> #1: GPF (Code = c0000005):
> Access violation
>
> TAPPLICATION:_AFORMS (0)
> TAPPLICATION:INITIALIZE (135)
> INITAPPLICATION$ (33)
>
> SI SOLO A PASADO UNA SEMANA!!!
> POR QUÉ, DIOS MIO, POR QUÉ ....
>
> Paso de mirarlo o me dan las tantas.
> Me cargo todo el directorio de descarga, vuelvo a la tortuga y le meto
> versión a fecha 17/09/2007, rezo para que la conserven y descargo. Miro el
> changelog y ¡mierdas me baja una de antes! será un bug de la tortuga que
> le han puesto "mayor que fecha".
> Reviso el log de desarrollo y veo que la siguiente entrada es del
> 21/09/2007. Vuelvo a borrar todo el directorio de descarga, le meto
> 21/09/2007 y descargo (tic, tac, tic, tac, ...) todo verde.
> Reviso el log y bingo consigo el día deseado. Joer algien más metio algo
> ese día.-
> $Id: ChangeLog,v 1.5705 2007/09/17 13:20:30 ran_go Exp $
> 2007-09-17 10:20 UTC-0300 Ranier Vilela <ranier/at/cultura.com.br>
> ...
> 2007-09-17 09:06 UTC-0300 Luiz Rafael Culik Guimaraes <luiz at
> xharbour.com.br>
> ...
> 2007-09-17 13:30 UTC+0100 Jose F. Gimenez <jfgimenez/at/wanadoo.es>
> POR FIN AQUÍ ESTAS!!!
>
> Ala, repítelo todo a partir de aquí.
> Rezo y pongo un cirio mental a todos los santos conocidos para no tener
> que mirar los cambios del día en el código.
> Reconstruyo el proyecto y está vez sí, parece que la aplicación se
> comporta igual que con la versión 'parcheada'.
> A todo esto más de las 6, pero eso es otra historia.
>
> José,
> ¿Son las mismas fuentes?
> ¿Si es Open Source, OSI-Approved, que problema hay en entregar un zip con
> las fuentes de la versión distribuida?
>
> Un saludo
> Xavi

Ignacio,
Esperemos que el proyecto no adopte ningún giro radical en beneficio de un GUI-IDE concreto.
Un saludo
Xavi

Xavi,
> Esperemos que el proyecto no adopte ningún giro radical en beneficio de un
> GUI-IDE concreto.
Si eso ocurriera, iría en su propio perjuicio, ya que se reduciría su base
de usuarios. Por nuestra parte, estamos trabajando para portar Xailer
también a Harbour, por lo que ni a nosotros ni a nuestros usuarios nos
perjudicaría.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

xHarbour developer mailing list está ABIERTA.
Podéis leerla en .-
http://sourceforge.net/mailarchive/foru ... _name=xhar bour-developers
Y postear en USENET: comp.lang.xharbour .-
http://groups.google.es/group/comp.lang.xharbour
Un saludo
Xavi
Ignacio Ortiz de Zúñiga escribió:
> Xavi,
>
> Te entiendo perfectamente, y no nos costarí­a mucho incluir los fuentes. El
> problema surge cuando los usuarios desean reconstruir xHarbour en sus
> propias máquinas ya que existen un motón de motivos por los cuales el
> proceso puede fallar que como comprenderás están fuera del ámbito del
> soporte que ofrece Xailer.
>
> El motivo más importante para evitar que cada uno se reconstruya su propia
> versión de xHarbour es el de soporte por parte nuestro. Nosotros sólo
> podemos responsabilizarnos del correcto funcionamiento de Xailer con las
> versiones de xHarbour construidas y publicadas oficialmente por nosotros.
> Ell no implica que cualquier usuario pueda crear sus propios binarios de
> xHarbour para utilizarlos con Xailer, pero logicamente bajo su única
> responsabilidad. Si se produce un error en sus programas ha de probarse su
> mal funcionamiento con una versión publicada por Xailer. Espero que lo
> entiendas.
>
> En cualquier caso, te aseguro que descargar xHarbour con el CVS Tortoise de
> forma anónima es muy sencillo. Contrruir todos los binarios y librerí­as
> puede que se complique algo más.
>
> Un saludo,
>
> "xAvi" <[email=x_@_com]x_@_com[/email]> escribió en el mensaje
> news:470793d2$[email=2@ozsrv2.ozlan.local...]2@ozsrv2.ozlan.local...[/email]
>> Jose F. Gimenez escribió:
>>> Sí­, es cierto. No obstante, se pueden seguir los cambios viendo el
>>> archivo changelog, sin necesidad de leer la lista.
>>>
>> LO ESCRIBO EN CLAVE DE HUMOR porque de la vida es mejor reí­rse que llorar.
>>
>> Si no estáis de humor pasar directamente al final.
>>
>> Narro mis pensamientos y actuaciones tras leer tu post.
>>
>> Bueno, vale, de acuerdo..., te acepto pulpo como animal de compañí­a.
>>
>> Instala la tortura (en qué estarí­a pensando) "tortuga", cambio el disco
>> por si acaso, conecta, ..., ¡mierdas no conecta! y ahora que le pasa (tic,
>> tac, tic, tac, ...) "ANONYMOUS" joer "anonymous". Por fin conecta. Rezo
>> para que no me "change" nada y le doy a bajar la última versión. (tic,
>> tac, tic, tac, ...) todo verde esto va bien, la última vez me chango un
>> montón de ficheros en conflicto y ya sé que es imposible pero..., esta vez
>> no me ha pillado.
>> Revisa el log.-
>> $Id: ChangeLog,v 1.5731 2007/10/04 11:43:43 modalsist Exp $
>> Revisa última entrada.-
>> 2007-10-04 08:45 UTC-0300 Eduardo Fernandes <modalsist@yahoo.com.br>
>> Revisa que no estén "tocados" los archivo de José, parece que no pero ya
>> me duelen los ojos, menos mal que nada más a pasado una semana. Copia a
>> desarrollo, copia los archivos de José, copia bison, copia el .bat y
>> revisa los sets que sean correctos.
>> Compila (tic, tac, tic, tac, ...) ¡mierdas no compila! error falta el
>> bison.simplex, como mí­nimo ha servido para ver que hay sets repetidos con
>> los por defecto.
>> Corrige el bat y vuelve a compilar (tic, tac, tic, tac, ...)(tic, tac,
>> tic, tac, ...)(...)
>> Ok. Mira el make log.-
>> MAKE Version 5.2 Copyright (c) 1987, 2000 Borland
>> bcc32 -c -Iinclude;sourcecompiler;sourcemacro -d -5 -6 -a8 -O2 -OS -DHB_API_MACROS
>> -DHB_GUI -D__WIN32__ -oobjb32hbfhnd.obj sourcecommonhbfhnd.c
>> Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
>> sourcecommonhbfhnd.c:
>> bcc32 -c -Iinclude;sourcecompiler;sourcemacro -d -5 -6 -a8 -O2 -OS -DHB_API_MACROS
>> -DHB_GUI -D__WIN32__ -oobjb32hbfsapi.obj sourcecommonhbfsapi.c
>> ...
>> ...
>> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
>> del make.tmp
>> ¡OH ni errores ni avisos, que buenos que son...!
>>
>> Cambia la raí­z del directorio xharbor del IDE a este, borra el directorio
>> obj de la aplicación y reconstruye.
>> Ejecuta y ... ¡JOER la primera en la frente!
>> #1: GPF (Code = c0000005):
>> Access violation
>>
>> TAPPLICATION:_AFORMS (0)
>> TAPPLICATION:INITIALIZE (135)
>> INITAPPLICATION$ (33)
>>
>> SI SOLO A PASADO UNA SEMANA!!!
>> POR QUí‰, DIOS MIO, POR QUí‰ ....
>>
>> Paso de mirarlo o me dan las tantas.
>> Me cargo todo el directorio de descarga, vuelvo a la tortuga y le meto
>> versión a fecha 17/09/2007, rezo para que la conserven y descargo. Miro el
>> changelog y ¡mierdas me baja una de antes! será un bug de la tortuga que
>> le han puesto "mayor que fecha".
>> Reviso el log de desarrollo y veo que la siguiente entrada es del
>> 21/09/2007. Vuelvo a borrar todo el directorio de descarga, le meto
>> 21/09/2007 y descargo (tic, tac, tic, tac, ...) todo verde.
>> Reviso el log y bingo consigo el dí­a deseado. Joer algien más metio algo
>> ese dí­a.-
>> $Id: ChangeLog,v 1.5705 2007/09/17 13:20:30 ran_go Exp $
>> 2007-09-17 10:20 UTC-0300 Ranier Vilela <ranier/at/cultura.com.br>
>> ...
>> 2007-09-17 09:06 UTC-0300 Luiz Rafael Culik Guimaraes <luiz at
>> xharbour.com.br>
>> ...
>> 2007-09-17 13:30 UTC+0100 Jose F. Gimenez <jfgimenez/at/wanadoo.es>
>> POR FIN AQUí ESTAS!!!
>>
>> Ala, repí­telo todo a partir de aquí­.
>> Rezo y pongo un cirio mental a todos los santos conocidos para no tener
>> que mirar los cambios del dí­a en el código.
>> Reconstruyo el proyecto y está vez sí­, parece que la aplicación se
>> comporta igual que con la versión 'parcheada'.
>> A todo esto más de las 6, pero eso es otra historia.
>>
>> José,
>> ¿Son las mismas fuentes?
>> ¿Si es Open Source, OSI-Approved, que problema hay en entregar un zip con
>> las fuentes de la versión distribuida?
>>
>> Un saludo
>> Xavi
>
>