RE: Implementar una función en una DLL RE: Implementar una función en una DLL
Verás, no soy experto en DLLs ni en C++, pero ese mensaje indica un conflicto. Las DDLs creadas con C exportan funciones, es decir, ponen a disposición de programas clientes una vía para realizar llamadas a funciones contenidas en dichas DLLs. Las funciones se pueden llamar por nombre o por número (ordinal). Sin profundizar en las formas de llamado y enlace, y demás complejidades del C, en ese proceso solo intervienen el programa cliente y la DLL.
Las DLL de automatización creadas en VB, por mucho que lo parezcan, no se comportan igual a las anteriores. Para que un programa cliente pueda usar código de una DLL ActiveX, debe crear un objeto a partir de una clase pública contenida en la DLL, y después ejecutar métodos de dicho objeto. Como su nombre lo indica, las DLL ActiveX emplean Automatización ActiveX, que antes fué Automatización COM. COM se basa en una jerarquía de clases a partir de la interfaz IUnknown. Lo que se deriva de todo esta cháchara es que se requiere trabajar con objetos (e interfaces COM, aunque lo ignoremos) para emplear una DLL de Basic.
Es evidente que el InstallShield trata de hacer una llamada directa a la función dentro de la DLL, y se queja al no poder encontrar el EntryPoint. Si la DLL estuviera programada en C y exportara dicha función no habría problemas. Al llamar a la DLL desde otro proyecto VB no hay problemas, se emplea ActiveX sin darnos cuenta.
Para quienes deseen profundizar sobre el tema y emplear algunos trucos para "dar la vuelta" a situaciones como esta les recomiendo el libro Hardcore Visual Basic, de Bruce McKinney. Está incluido en el MSDN. En el explica como crear DLLs con objetos globales, que no necesitan instanciarse explícitamente para ser llamados, pero creo que en este caso no aplica, porque el cliente (InstallShield) no es VBy por ende, no debe emplar COM.
Espero no haberlos mareado mucho, aamartin</TR> |