FHW64 llamadas a DLL/COM/ACTIVEX 32 bits

[fgondi]

Hola amigos,

Alguien sabe si se puede?
Ya he intentado introducir en el registro las claves para DllSurrogate. Pero sigue sin funcionar.
http://www.gfi.com/blog/32bit-object-64bit-environment/

Es que no consigo que funcione ni el Acrobat pdf.
Sin embargo si se comunica con excel 2010 de 32bit.

En otro ámbito:
He probado FreeImage64.dll y sobre windows 8 no funciona. En concreto he probado "Samples\Ribbon2.prg"

[Antonio Linares]

Fernando,

Una aplicación de 64 bits no puede llamar a código en 32 bits de forma directa, sencillamente porque se ejecutan en espacios diferentes: las aplicaciones de 32 bits en Windows 64 se ejecutan en WOW64 (Windows on Windows), de manera parecida a como las aplicaciones de 16 bits pueden funcionar en Windows 32 (WOW).

Al hablar de objetos COM, la situación es diferente, puesto que la llamada no es "directa", sino que que la capa de OLE de Windows, permite la conversación:
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/

De todas formas, la solución más fácil es disponer de versiones de 64 bits de las DLLs que usemos

[fgondi]

Antonio, gracias.

Entonces, debo entender que si se pude llamar a los objetos COM?

Os funciona el ejemplo "Samples\pdf.prg"? a mi me da error en la aplicación.


De la clase FreeImage64.dll, tengo que cambiar algo?

[Antonio Linares]

Fernando,

samples\testimg.prg está funcionando bien aqui y usa FreeImage64.dll

En cuanto a pdf.prg aqui falla tambien. Posiblemente no sea compatible con los 64 bits. Voy a google...

[Antonio Linares]

Fernando,

Que versión de Windows estás usando ?

Aqui en Windows 8 64 bits es que pdf.prg ni siquiera funciona en 32 bits...

La pesadilla de los componentes externos...

[Antonio Linares]

En Windows 8 64 cambiandole de TActiveX a THActiveX crea el objeto en 32 bits pero no admite oActiveX:SetCurrentPage( 1 ) ni oActiveX:SetCurrentPage = 1

[Antonio Linares]

En Windows 7 64 samples\pdf.prg arranca bien, aun asi parece que tengo que actualizar el pdf reader de Acrobat

Como ves, nos estamos encontrando con diferencias que vienen del propio Windows o del propio componente Acrobat. A esto me refiero con los problemas de los componentes externos. Nosotros no hemos cambiado nuestro EXE, pero el comportamiento de nuestra aplicación cambia según la versión de Windows o la versión instalada del componente.

[fgondi]

Muchas gracias Antonio. Seguiré investigando

Cuanto largo y tendido podríamos hablar de lo conveniente que es usar componentes externos
Ojala algún día podamos tener esta conversación

En este caso caso estamos hablando de Windows y de Acrobat Reader. Los 2 son bastantes usados por casi todo el mundo.
En otros componentes lo entiendo, pero en estos 2 no me digas que porque se actualizan y cambian la culpa es de ellos
Son la base de muchos sistemas, y si ellos cambian, nosotros nos adaptaremos, desgraciadamente ellos (por windows) ponen las reglas del juego.

Otro ejemplo puede ser FWH, no siempre al recompilar todos nuestros fuentes con la nueva versión de FWH funciona sin mas.
A veces hay que hacer retoques en el sistema para que pueda funcionar.
Por ejemplo en la versión 13.06 se incluye que xbrowse sólo se ordena si se defiene lAutoSort a True.

Es lo que tiene la evolución.

[Antonio Linares]

Fernando,

Tienes toda la razón en que el lector de PDFs de Acrobat es muy importante en las aplicaciones y que por supuesto tenemos que encontrarle la forma de que funcione bien.

La idea de los componentes externos es realmente buena, el problema es que en la práctica los distintos modelos que se han ido implementando han tenido muchos fallos de diseño. Si el uso de las DLLs, o de los ActiveX, etc. fuese algo robusto, no aparecerían GPFs, o errores (con poca documentación para entender porque el error ocurre y no la descripción del error en si). Pero bueno, tienes razón tambien, no nos queda otra que usar lo que Microsoft ofrece

En Windows 7 64, pdf.prg se ejecuta bien asi:

Code: Select all  Expand view

#include "FiveWin.ch"

function Main()

   local oWnd, oActiveX

   DEFINE WINDOW oWnd TITLE "FiveWin ActiveX Support"

   oActiveX = THActiveX():New( oWnd, "AcroPDF.PDF.1" ) // Use "AcroPDF.PDF.1" for Acrobat Reader 7

   oWnd:oClient = oActiveX // To fill the entire window surface

   oActiveX:LoadFile( "fwintro.pdf" )
   // oActiveX:SetCurrentPage( 1 )

   ACTIVATE WINDOW oWnd

return nil

Pero en la ventana aparece una página web que intenta acceder a res://ieframe.dll/navcancl.htm#http://acropdf.pdf.1/ pero como en el nombre aparece navcanl (abreviatura de navigation cancelled?) puede ser que intentase acceder a otra. De donde sale esa página web ? voy a buscarlo en google...

[Antonio Linares]

Nada, casi no hay resultados.

En 32 bits, no muestra esa página web sino una ventana gris oscura. He probado a hacerle Hide() y el control está ahi,
pero no muestra nada, solo una imagen gris.

Da la impresión de que a partir de esta versión en curso de Acrobat Reader, el código que antes usábamos y que funcionaba bien, ya no funciona. Y a partir, de aqui, se aceptan sugerencias, ideas... (a este punto es al que me refiero con el tema
de los "componentes externos". Que cámino seguir a partir de aqui salvo buscar en google y encomendarse a todos los santos ?

[Antonio Linares]

http://livedocs.adobe.com/acrobat_sdk/9.1/Acrobat9_1_HTMLHelp/wwhelp/wwhimpl/common/html/wwhelp.htm?context=Acrobat9_HTMLHelp&file=IAC_API_OLE_Objects.103.167.html

[Antonio Linares]

Hay algún usuario de FWH que esté usando el ActiveX "AcroPDF.PDF.1" ?

En caso afirmativo, podrían especificar que versiones usan de FWH, Harbour/xHarbour y compilador de C ? gracias

[Antonio Linares]

Con FWH 32 he probado a hacer esta llamada:

oActiveX:Print()

y se muestra la caja de diálogo de Windows de selección de nombre de fichero y el fichero se genera (aunque su contenido es erróneo).

El hecho de que responda al mensaje Print() quiere decir que el objeto esta creado y que responde a nuestros mensajes.

La pregunta es, por qué se muestra en gris y no aparece nada más ?

[Antonio Linares]

Bueno, sonó la flauta. Asi funciona en 32 bits

Code: Select all  Expand view

#include "FiveWin.ch"

function Main()

   local oWnd, oActiveX

   DEFINE WINDOW oWnd TITLE "FiveWin ActiveX Support"

   oActiveX = TActiveX():New( oWnd, "AcroPDF.PDF.1" ) // Use "AcroPDF.PDF.1" for Acrobat Reader 7

   oWnd:oClient = oActiveX // To fill the entire window surface

   oActiveX : src = hb_CurDrive() + ":\" + CurDir() + "\fwintro.pdf"
   oActiveX:GotoFirstPage()

   ACTIVATE WINDOW oWnd

return nil

[Antonio Linares]

En FWH 64 bits, usando la Clase THActiveX (basada en el propio soporte de ActiveX de Harbour) aparece el error que src no es una data válida: ("no exported variable"), y usando la Clase TActiveX genera GPF...