FiveTech Software tech support forums

Mi querido Antonio Linares y amigos del foro:

No pretendo ser dramático, ni negativo, pero así están las cosas:

1.- Definitivamente PCODE DLL no funciona. Quedamos paralizados.

2.- Los browses EDITABLES con TSBrowse, que han funcionado perfecto desde que Manuel Mercado donó su formidable clase TSBrwose y con los que nunca hemos tenidos problemas en su uso desde FW 1.92 y pasando por diferentes versiones de FWH hasta la 2.7, ahora con FWH 7.12 ya no funcionan. Estando en modo edición, al pulsar Flecha Derecha o izquierda genera el siguiente error.

Aplicación:
===========
Path y nombre: C:\MSTVS\CG.EXE
Tam.: 4,798,976 bytes
Máximo de ficheros abiertos: ( SetHandleCount() ) 0
Error ocurrido el día: 12-12-2007, a la hora: 15:49:56
Nombre del error: Error BASE/1070 Argument error: ==
Args:
[ 1] = L .F.
[ 2] = N .F.

Llamadas a funciones
====================
Llamado por TGET:KEYDOWN(0)
Llamado por TSGET:KEYDOWN(155)
Llamado por TWINDOW:HANDLEEVENT(0)
Llamado por TCONTROL:HANDLEEVENT(1393)
Llamado por TGET:HANDLEEVENT(0)
Llamado por TSGET:HANDLEEVENT(385)
Llamado por _FWH(3260)
Llamado por DIALOGBOXINDIRECT(0)
Llamado por TDIALOG:ACTIVATE(270)
Llamado por CONSECUTIVOS(843)
Llamado por (b)ACTIVAMENU(416)
Llamado por TMENU:COMMAND(484)
Llamado por TWINDOW:COMMAND(978)
Llamado por TMDIFRAME:COMMAND(0)
Llamado por TMDIFRAME:HANDLEEVENT(0)
Llamado por _FWH(3260)
Llamado por WINRUN(0)
Llamado por TMDIFRAME:ACTIVATE(927)
Llamado por INICIAL(287)
Llamado por INICIO(272)


Todo lo hemos recompilado con FWH 7.12, xHarbour 1.1.0 y BCC 5.5.1

Estoy seguro que es un problema generado en la actualización de xHarbour, pero necesitamos solución. De lo contrario estaríamos avocados a dejar las aplicaciones que ya están desarrolladas en FWH 2.7 y xHarbour 0.99.61

Es esto lo correcto ?

Deberíamos usar FWH 7.12 sólo para nuevos desarrollos ?

Antonio, con todo respeto, este es un problema que no sólo nos afecta a los desarrolladores de aplicativos finales, sino que a tí también te afecta, pues tu producto está de por medio ya que es el que utilizamos para la presentación VISUAL de nuestros programas. Por esto es vital tu intervención en solucionar la increíble incompatibilidad que se está presentando.

Si tuviésemos que hacer uno o dos ajustes, vaya y venga, pero en lo poco que hemos testeado hemos encontrado problemas de compatibilidad con código clipper y con código en C que nunca habíamos tenido (Intenta compilar HBOle y verás). Igual con TSBrowse, TSButton, entre otros. Debemos dejar de utilizar estas maravillosas librerías de terceros ?

Intentamos la actualización de uno de nuestros aplicactivos tipo ERP, y nos encontramos que en procesos en que se actualizaban automáticamente algunas bases de datos, ya no van más. Qué debemos hacer, comenzar a cambiar código a aplicaciones que por año han funcionado perfecto ?

No encontramos en ninguna parte una explicación de cuáles son _ que hay que hacer, porqué y cuáles sus alternativas. Simplemente hay que esperar que los usuarios ejecuten los programas y esperar a ver por dónde revientan y luego ver cómo los solucionamos. Es esto lo correcto ?. Esperar que los clientes nos ataquen pues sus programas estaban funcionando perfecto y por el prurito de la actualización, de que tienen una tecnología más nueva, se les desestabilizaron ?

No creo que estos sean _.

El sentido común me dice, que si actualizo algo, es para mejorar, para ofrecer más y mejores prestaciones. No para desestabilizar una aplicación.

Cuando _ o adiciones, y ofrecemos actualizaciones a nuestros clientes y se presentan problemas, no podemos decirles que es por las herramientas que utilizamos. Tenemos que solucionarles sus problemas, y por lo menos, dejárselas como estaban.

Cierto es que los ejemplos que vienen incluídos en FWH funciona con la versión 7.12, pero es que son muy sencillos, unas pocas líneas de código. No pasa así con aplicativos grandes, de cientos de miles de lineas y procesos complejos. Créeme que la actualización te va a producir un gran dolor de cabeza.

Tomamos el aplicativo más pequeño y sencillo que hemos desarrollado (lo hicimos en 15 días), y ya llevamos tres días lidiando con la actulización y todavía no terminanos. Se suponía que simplemente era instalar las nuevas versiones de FWH y xHarbour, recompilar todo el código y las librerías que usamos y listo, pero no fué así. De pronto hubiese sido mejor hacerlo desde cero.

Pero no podemos hacer lo mismo con aplicativos que nos tomó años hacer y muchos meses más en migrar desde D.O.S. a 32 bits utilizando FWH y xHarbour.

Cierto que no somos programadores al nivel de los gurús que desarrollan y contribuyen en xHarbour, pero tampoco somos tan novatos como para que una actualización se nos vuelva imposible. Simplemente hay incompatilididades que hacen extremadamente difícil, y en consecuencia, extremedamente costoso en tiempo y dinero (hay que pagar a los programadores) la actualiazación.

A esto debes sumarle que tienes que asignar personal a un riguro control de calidad, pues al no estar identificados los posibles problemas que se puedan presentar en la ejecución de los programas tienes dos opciones: o las sometemos a un control de calidad a fondo, o se las enviamos a los clientes y esperamos a que comiencen a llamarnos para colgarnos de donde más nos duele por la cantidad de fallas y errores que se están presentando.

No es nuestro ánimo entrar en polémicas, ni molestar a nadie. Simplemente tenemos muchos problemas que antes no teníamos y que se presentan a partir de la actualización:

Para estar seguros de lo que hacemos hemos seaparado dos computadores para compilación:

Uno con FWH 2.7 y xHarbour 0.99.61 y el otro con FWH 7.12 y xHarbour 1.1.0.

En cada uno hemos instalado las mismas fuentes (Idénticas, sin ni una letra de cambio) de nuestra principal aplicación, así como todas la librerías que utilizamos. Es decir un espejo el uno del otro. Sólo cambian las versiones de FWH y xHarbour.

Se han compilado y el resultado final es:

La compilada con FWH 2.7 y xHarbour 0.99.61 funciona como siempre ha funcionado: perfecta.

La compilada con FWH 7.12 y xHarbour 1.1.0 se convierte en un dolor de cabeza por los errores que comienza a generar.

Por otro lado, pensamos quer el camino va a ser largo y tedioso, pues vamos tener que esperar a que vayan apareciendo los errores, subirlos al foro, esperar respuesta, y luego, si la hay, ver si esa respuesta soluciona el problema. En consecuencia, el tiempo nos puede atropellar. Somos una empresa que desarrolla aplicativos estándar, del tipo "Instale y comience a utilizar". En el camino, si el cliente lo requiere, le vamos desarrollando procesos especiales, según sus gustos y necesidades, mediante el uso de PCODE Dlls.

Por supuesto que la alternativa es seguir con las herramientas que veníamos utilizando con éxito y olvidarnos por ahora de las actualizaciones de las mismas. No podemos detenernos en la solución de errores que se escapan de nuestras manos. No hay problema. Pero nos queda un mal sabor: Estaremos condenando esas aplicaciones a quedarse desarrolladas con herramientas antiguas ?

Soy muy consciente de que la solución no es fácil, al contrario, debe de ser muy compleja, pero me preocupa que en virtud de todos tus demás proyectos dejes este tema de lado, especialmente cuando veo en el foro que hadie más ha plantedo este problema.

Qué pasa ? Sólo nosotros lo tenemos ?

Compañeros con aplicaciones ya desarrolladas con versiones FWH 2.7 y anteriores no se han actualizado de un sólo salto a FW 7.12 como nosotros? No nos actualizamos a las versiones posteriores a la 2.7 por temor a las imcompatibilidades, pues las veces que lo hicimos tuvimos problemas, claro que nunca tan graves y difíciles como en esta ocasión. Si lo hubiésemos hecho, no tendríamos este problema ?

Si hay colegas desarrolladores con aplicativos grandes que se han actualizado con éxito, quisieran compartir con este pobre cristiano la solución ?

Acaso cambiaron los parámetros de compilación y ejecución y nunca me enteré ? Utilizamos los mismos scripts de siempre. Los que tu mismo has propuesto desde la primera versión de FWH. Se debe cambiar algo en estos scripts para que FWH 7.12 funcione perfecto ?

Hemos probado con el instalador de xHarbour que bajamos de fpt de FiveTech cuando nos actualizamos. Hemos probado bajando todo xHarbour con Tortoise CVS y contruyendo todos los elementos de xHarbour desde cero (es lo que hemos hecho siempre), y en cualquier caso los mismos problemas persisten.

Antonio, insisto en que estoy seguro de que es un problema causado en xHarbour (que pena si se forma polémica). Pero, como FiveWin está de por medio en esta situación, pues tu maravillosa herramienta es la que utilizamos siempre, me temo que te corresponde a tí encontrar una solución. Adiciónale el hecho de que nuestros conocimientos técnicos no son ni el 1.% de los tuyos.

De pronto se me ocurre que en aras de encontrar una solución, aunque no la ideal, se pudiera utilizar FWH 7.12 con xHarbour 0.99.61. Es posible ? Podrías ayudarnos al respecto ? Prefiero perder _ y supuestas mejoras que se hayan hecho en xHarbour, que perder las que tú has hecho en FWH.

Otra opción: Cuán doloroso es el parto de pasar de xHarbour a Harbour ? Se perderán prestaciones en el cambio, por ejemplo ADO, OLE, IP, Scripts ?. Por todo lo que he leído en el transcurso de estos años, tanto en el foro de FiweWin (desde la época de las news, cuanto las extraño) como en las News de xHarbour, se saca como conclusión que xHarbour es más poderoso que Harbour. Estoy en lo cierto ?

La decisión que tomes será muy bienvenida y en nada afectará el profundo aprecio y gran admiración que sentimos por tí. Solamente quisiéramos saber a qué atenernos: si vale la pena seguir intentando en la actualización , o por el contrario, nos olvidamos definitivamente de la misma. Como tú comprenderás, está de por medio nuestra empresa. Compramos la silla sin tener el caballo. Por habladores cometimos el error de comunicarle a nuestros clientes que íbamos a actualizar nuestras herramientas de desarrollo, en beneficio de ellos, pues se supone que las últimas versiones deberían ser mas actualizadas tecnológinamente que las anteriores, con más y mejores prestaciones, con nuevo y mejor look, etc., etc. Ahora no paran las llamadas preguntándonos cuando tendremos las nuevas versiones. Qué les decimos, que seguimos con las anteriores, o que nos esperen ? Cuánto tiempo ?

A esto súmale el hecho de que para esta época del año, los clientes piden cambios en sus procesos o cosas nuevas para el año entrante, aunque esto no tiene problema pues lo haremos con la versión anterior de xHarbour.

Lamento enormemente el generar este tipo de tópicos o polémicas, como quieran llamarlas, pero, dónde más lo hacemos ?.

Creanme que acudimos al foro sólo cuando vemos que el agua ya nos tapó. Siempre solucionamos los problemas nostros mismos. Leemos, investigamos, probamos, y por ensayo y error, hemos salido adelante. Sólo que esta vez, el problema supera de largo nuestra capacidad técnica y creemos, en el mejor de los sentidos, que le correponde a FiveTech pronunciarse y tomar cartas en el asunto de las actualizaciones de xHarbour, o en su defecto, como le dijo el Rey Juan Carlos a uno de los presidentes de un país de este tan sufrido tercer mundo, que me digan, "Por qué no te callas ?" y nos olvidamos del asunto. No volvemos a molestar

Saludos y un abrazo para todos,

Carlos Gallego

Bueno, planteo mi caso.

He pasado de FWH 2.5x a 7.11 con xHarbour, cierto que tuve que revisar y rehacer varios ajustes a diferentes clases de FiveWin de acuerdo con mis gustos y creo que lo he logrado sin mayores problemas.

El mayor problema lo tuve con las clases y libs de terceros, mas de una ha dejado de tener soporte y no puedo exigirlo.

Hubiera sido bueno que los autores de estas clases cedieran los derechos a Fivetech (como lo hice con TGraph). Seguro que si esta clase deja de funcionar en versiones futuras exigiré que funcione.

En alguna parte ví un comentario sobre que quienes usan las clases de nuestro amigo Manuel Mercado (TSxxx) estan montados en una bomba de tiempo, no es mi caso.

Por hoy no veo problemas y si muchas mejoras. Pronto cambiaré a la versión mas reciente de xHarbour, ya daré mi opinión en su momento.

Hola Carlos,

Primero de todo darte a ti y a los tuyos animos. Siempre que hay una migración, estas no acostumbran a ser tan transparentes como parecen. En mi caso, te puedo contar q ahora estoy en la 7.4 y funciona perfectamente, pero evidentemente despues de haber testeado 'mas a fondo' de lo que queria muchos de los procesos, por lo que a veces el concepto de 'tendria de funcionar igual...' es muy relativo.

Primero de todo, debes de tener claro porque realizas la migración. En tu caso q os ha llevado al cambio despues de un año a la nueva lib ? Q ventaja os aporta ?

Segundo, todas las librerias de tercero es OBLIGATORIO disponer de fuentes para poder recompilarlos, ajustarlos y realizar todos _ oportunos.

Tercero, paciencia. No todo es tan facil y trivial. Nuevas librerias, pues recompilamos y ya esta (pues va a ser q no). Tu esto ya lo debes saber. Llega un momento que cuando tienes aplicaciones en productivo, q llevan tiempo funcionando y son muy estables, tienes de tener muy claro el salto y el cambio a una version, valorar las partes positivas q te aportan y las consecuencias que puedes tener.

En mi caso, tambien comentarte que uno de los aplicativos que tenemos funcionando, esta hecho con la 2.4 . Durante todo este tiempo ha sido muy robusta, y si hemos tenido de tocar algo lo hacemos con las lib de la 2.4 -> Me niego a migrarla a las nuevas versiones y mas si todo lo que necesitamos lo podemos ir solucionando con la vieja libreria.

El tema de los Pcode Dll. Yo hace tiempo que me pelee con ellos e incluso te voy a decir que en un cambio de version, cuando aun no funcionaban bien, tuve q recurrir a AL para que afinara el tema, porque yo ni sabia como se habian realizado, ni entendia como estaba montado, ni tenia tiempo de mirarlo, y es por eso que tuve que recurrir a sus servicios, pero realmente lo necesitaba.

Yo te aconsejo, q "dividas y venceras" , q pongas en el foro tus dudas con pequeños ejemplos autocontenidos y entre todos mirar de echarte un cable. Pequeños ejemplos de Pcode, TSBrowse, ... mas de uno te da a veces algun 'tirito' en el q tu no habias caido...
Siempre tendras este problema, en mayor o menor medida pero cuanto mas tiempo tardes en hacer cambios, mas problemillas te saldran...

Y por ultimo, no molestas, claro que no, y solo te escribo para darte animos y q todos estamos por aqui, muchos a veces ocultos, pero que quizas se sienten identificados un poco contigo y con tus problemas poruqe ya los hemos pasado. Te animo a que pongas tus dudas con pequeños ejemplos...

Suerte

Carlos,

>
De pronto se me ocurre que en aras de encontrar una solución, aunque no la ideal, se pudiera utilizar FWH 7.12 con xHarbour 0.99.61. Es posible ?
>

Si, sólo tienes que recompilar todos los PRGs de FWH con xHarbour 0.99.61.

Puedes hacerlo usando este fichero BAT:
for %%f in (*.prg) do c:\harbour\bin\harbour %%f /n /ic:\fwh\include;c:\harbour\include
for %%f in (*.c) do c:\bcc55\bin\bcc32 -c -Ic:\bcc55\include;c:\harbour\include %%f
for %%f in (*.obj) do c:\bcc55\bin\tlib fivehx.lib -+ %%f /0 /P32,,

Carlos,

En relación al resto de comentarios que haces en tu post, no voy a entrar en discusiones, pero si quiero aclarar algunos puntos:

1. Cada nueva versión de FWH es probada por cientos de programadores, en aplicaciones realmente complejas y se revisa cada posible fallo de compatibilidad ó error que pueda aparecer.

2. Precisamente el problema que estais teniendo se debe a no usar versiones recientes y a no estar actualizados. Si os hubiéseis mantenido actualizados, vuestros problemas se habrían detectado rapidamente y ya estarían solucionados.

3. Muy pocos usuarios usan las DLLs de pcode, y esto conlleva el problema de que no estan probadas por muchos usuarios, y que ante un problema como el vuestro, no se ejerce la presión necesaría sobre los equipos de desarrollo de Harbour/xharbour. Es por esto que nosotros siempre aconsejamos usar el código mas "estandard" posible, y no usar capacidades que no sean muy "populares".

Carlos,

Una cosa más:

Es preciso y muy importante, poder reproducir el error (en este caso el de las DLLs de pcode) con un ejemplo sin usar código FWH para poder reportarlo al equipo de desarrollo de harbour/xHarbour.

Sin un ejemplo reproducible, nadie se pondrá a trabajar en arreglar algo que no saben lo que es ni cómo probarlo.

Alfredo, Carles, Antonio, por eso amo este foro. Ustedes son maravillosos.

Entrando en materia y resumiendo sus amables respuestas:

1.- Me actualizo porque me gustaría poner en nuestras aplicaciones un nuevo look con estilo Office2007, el nuevo OutLook, entre otras nuevas prestaciones. Se acuerdan de una canción que dice "Vanidad, por tu culpa he caído...."


2.- Por religión no utilizo ninguna librería de la que no tenga las fuentes. De todas tengo las fuentes, de las que hemos hecho nosotros, y de las que muy gentilmente han cedido colegas del foro.

3.- Soy consciente de que cada actualización lleva implícita algunas modificaciones, las que en todo caso, han servido para ir mejorando nuestro código. Eso esta muy bien. Lo que pasa es que en esta ocasión nos está quedando grande.

4.- Reconozco ahora el mea culpa por no haber sido constante en las actualizaciones y de paso confieso que me las estaba tomando de cómodo. Por mi edad (en pocos días cumplo 56, creo que soy de los más viejos, sino el más viejo del grupo) estaba tratando de llevar las cosas a media marcha. Prometo, ante Dios y el mundo, que a partir de ahora seré juicioso y pisaré el acelerador. Es más Antonio, para febrero del próximo año voy por FTDN, vale ?

5.- Creanme amigos, que el uso de las Dll con código es formidable. Da una versatilidad impresionante y es (o era) 100% estable y sin limitaciones. Todo lo que pueden hacer en su código normal en el ejecutables, lo pueden poner en las Dll, inclusive con librería de terceros como TSButton, TSBrowse, el Browse de Hernán. hbZip, ADS, MySql, etc. NO HAY LIMITE. Simplemente tienen su aplicación básica y desde allí acceden al código en las Dll y funciona perfecto y sin afectar velocidad ni estabilidad, no importa si es Windos'98, XP, Vista, 32 o 64 Bits. Que ventajas tiene ? Muchas: Hacer modificaciones sin tocar el ejecutable principal, simplemente envían la Dll al cliente y listo. Aumentar servicios a sus aplicaciones. Dar una verdadera y profesional escalabilidad a las mismas. Personalizar aplicaciones que son estándar. Por ejemplo, un programa para control de inventario que es igual para todo el mundo, se puede personalizar para cada cliente según sus gustos y necesidades, simplemente haciendo la Dll correspondiente y enviándosela, y muchas más.

De verdad los animo a que prueben. Animo a todos los colegas del foro a que prueben. Vale la pena, descubrirán un universo de posibilidades con su uso, y de paso, no me dejan solo. Y por lo que he podido ver, solo con FiveWin se puede hacer en forma estable, jejejejejeje..... (Antonio, es un Image Maker más para FiveWin). Pueden pasar todo tipo de parámetros, efectuar todo tipo de procesos, obtener todo tipo de respuesta de las funciones contenidas en las Dll's, etc., etc., etc.

A la fecha, nuestros desarrollos están orientados, en un 70.% por lo menos, hacia las Dll's

Cuenten conmigo para cualquier ayuda al respecto. Si consideran necesario, con gusto preparo un ejemplo lo más completo que pueda, incluyendo fuentes y scripts de compilación y linqueo, eso si, sobre FWH 2.7 y xHarbour 0.9961. Ustedes sólo ordenen que yo obedezco, y estoy seguro que Antonio nos ayudará a mejorarlo.

6.- Arturo, básicamente casi todos los botones y browses que utilizamos en nuestras aplicaciones están sobre TSButton y TSBrowse y nunca hemos tenido problema. Los botones se pueden cambiar por los nativos de FWH, es tedioso pero puede hacerse sin mayor conflicto. Pero los browses son otra cosa. TSBrowse (del desaparecido y extrañado Manuel Mercado) tiene prestaciones que no tienes en las clases nativas de FWH como TWBrowse, TCBrowse, etc. La opción sería reemplazarla por xBrowse, no la he probado, pero lo que si he visto, es que implicaría cambio drástico de código y no tiene todas las prestaciones que tiene TSBrowse, ni su maravillos manejo del look, headers multilinea en 3D, rows multilinea, etc. Es así o estoy equivocado ?. Una luz al respecto me ayudaría mucho.

7.- Antonio, la verdad, verdad, es que no tengo ni puñetera idea de cómo hacer el ejemplo sin usar FWH. Desde ayer estoy intentando hacer una rutina simple tipo Clipper D.O.S., pèro por supuesto compilada con xHarbour, pero no logro generar la Dll. Intenté con hbMaker y la generó pero no la lee el ejemplo que la invoca. Si me puedes orientar cómo hacerlo y me puedes enviar un ejemplo, incluídos los respectivos scripts, preparados para niños de kinder, te agradecería mucho.

8.- Antonio, respecto a recompilar los PRGs de FWH 7.12 con xHarbour 0.99.61 me saltan algunas preguntas:

- Con esto sólo recompilaría FIVEHX.LIB, pero entiendo que no están todas las fuentes (en prg o en C) que componen dicha librería o estoy equivocado. Qué PRGS o códigos en C estarían haciendo falta para no dejar funciones o prestaciones de las contenidas en FIVEHX.LIB deshabilitadas ?

- Qué pasaría con FIVEHC.LIB ? Me imagino que si está en puro código C, no generaría problemas con la versión del PCODE de xHarbour y la que tú usaste para generarla. Estoy en lo correcto ?

9.- Antonio, después releí lo que escribí al inicio de este post y me dí cuenta que estaba con un poquito de amargura. Espero que me comprendas que me causó mucho stress enfrentarme a problemas que hacia rato no tenía. Gracias por tu prudencia. Por eso eres mi MAESTRO.

Amigos, por favor tomen mis comentarios por el lado amable. Soy un fanático de FiveWin y leal a morir. No importa lo que pase en el mundo, jamás dejaré de utilizar FiveWin ni me aventuraré por otros rumbos. FiveWin fue, es y será el mejor GUI que existe para los que venimos de Clipper, y así Antonio me diga que ya no lo use más, pues de malas, porque lo seguiré usando mientras yo siga en este negocio. Así me digan ciego y cerrado, pues de malas, porque lo seguiré utilizando. Así por otros lados ofrezcan el cielo y la tierra, pues de malas, porque lo seguiré usando, no importa la versión. No importa la guerra que le hagan por otros lados, pues de malas, porque lo seguiré usando. Punto.

Asi que amigos del alma, larga, larguísima vida a FiveWin. Es el mejor. Y metámosle duro el hombro para hacerlo cada día mejor.

Saludos y abrazos,

Carlos Gallego

Carlos,

> Con esto sólo recompilaría FIVEHX.LIB

Asi es. FIVEHX.LIB solo contiene PRGs y se entregan todos ellos con FWH

>
Qué pasaría con FIVEHC.LIB ? Me imagino que si está en puro código C, no generaría problemas con la versión del PCODE de xHarbour y la que tú usaste para generarla. Estoy en lo correcto ?
>

Sí. De todas formas, construye FIVEHX.LIB y pruébalo. Quizá necesites algo adicional y desde aqui te ayudaremos

Carlos,

De todas formas vamos a intentar conseguir un ejemplo sin FWH que reproduzca los errores que comentas.

Otra opción que tenemos es registrar los símbolos de los PRGs de las DLLs como se hacía antes, ya que desde #pragma BEGINDUMP se tiene acceso a "symbols" y con eso ya podemos hacerlo.

Antonio, gracias.

>
Asi es. FIVEHX.LIB solo contiene PRGs y se entregan todos ellos con FWH
<

Perfecto

>
Sí. De todas formas, construye FIVEHX.LIB y pruébalo. Quizá necesites algo adicional y desde aqui te ayudaremos
<

Me pongo inmediatamente en la tarea.

>
Otra opción que tenemos es registrar los símbolos de los PRGs de las DLLs como se hacía antes, ya que desde #pragma BEGINDUMP se tiene acceso a "symbols" y con eso ya podemos hacerlo.
<

Me podrías ayudar con un ejemplo sencillo de cómo hacerlo ?

Cuál de las dos opciones es mejor para efectos de estabilidad, recompilar con 0.99.61 o registrar los símbolos de los PRGs ?

Saludos,

Carlos Gallego

Carlos,

>
Cuál de las dos opciones es mejor para efectos de estabilidad, recompilar con 0.99.61 o registrar los símbolos de los PRGs ?
>

De momento recompila con 0.99.61 y prueba tu aplicación.

Mientras estamos revisando _ que se han hecho en las DLLs de pcode, y a ver si encontramos un ejemplo que reproduzca lo que nos comentas

Carlos,

Hemos probado tu ejemplo que usa OemToAnsi() en la DLL y funciona perfectamente.

Por favor intenta proporcionarnos un ejemplo que falle (aunque use FWH), gracias

Antonio,


http://mastersoft3000.com/publico/prudll.zip

Contiene fuentes del ejemplo y de la dll, bats y scripts de compilación que estoy usando. De pronto ha cambiando algo en los parámetros de compilación o Linkeo, o ahora hay que hacer algo más y me hace falta.

Por favor prueba y me cuentas.

Saludos,

Carlos Gallego

Carlos,

Ese es el mismo ejemplo que ya nos distes y que hemos probado y que funciona bien.

O le has modificado algo ?

Oops, discúlpame. Es el mismo

Extraño, de todas formas lo recompilé y probé, y a mi me generó el error. Usaste los mismos scripts que están en el ejemplo u otros ?. De pronto puede ser algo en los scripts.

Saludos,

Carlos Gallego