FiveTech Support Forums

I'm upgrading from older FWH version using xharbour version .99

the DLL32 function PPO code reveals a call to GetProcAddress() - "OLD Convention"

in the new FWH 10.1 the same DLL32 function PPO code reveals a call to GetProcAdd() -- "NEW Convention"

in the OLD convention, this function returned a binary string used with CallDLL() function.

in newer FWH libraries, this same call results in a value of data type "Pointer" -- I have never seen a datatype "Pointer" before and wonder what exactly it is and how it's used, defined, etc.

anyway, the NEW convention uses GetProcAdd() instead of GetProcAddress() to return the binary string.

I ask because I am getting GPF's while calling a C-Language .DLL file, which always worked fine in old FWH / XHarbour.

What's the difference with new DLL calling convention in CALLDLL() between .99 xharbour FWH libraries and 1.2 xharbour FWH libraries?

in the meantime I will try to build a simple example to get more information.

thank you.

Don,

DLL32 gets translated into DLL, as DLL32 was developed for 16 bits apps. The syntax to use is DLL FUNCTION ...

Whats the DLL FUNCTION declaration that you are using ? Except for the GetProcAdd() change, everything should work fine as usual.

i can communicate with the c-language dll file if I use GetProcAdd()

If I use GetProcAddress() a "Pointer" is returned and I have no success with the DLL - GPF every time.

I'm using a DLL (IMAGE2PDF.DLL from Utility Warrior - you can down load it).
This is a DLL that receives parms and/or returns info.

If I call the DLL without passing parms, no problem using DLL FUNCTION and/or manually calling getprocadd() and calldll() calling convention.

But, If I attempt to PASS PARAMETERS to the DLL I get a GPF. I've tried passing strings - LPSTR, and integer values - LONG

These functions work great with fwh 2006 and xHarbour Compiler build 0.99.51 (SimpLex)

I think there is a difference in the GetProcAdd() and CallDll() functions in FWH between the "OLD" and "NEW" FWH.

do you have any c-language dll's that receive parms that you can test? if not, I can supply one that I know for sure works fine.

thanks.

Don,

GetProcAddress() is a function declared in Harbour/xHarbour, thats why we had to rename ours to GetProcAdd(). If you use FWH DLL FUNCTION command then you have to use GetProcAdd(). It will not work with the other.

What xHarbour version are using ? Are you using Borland C to compile ?

borland 5.5 c++
xharbour 1.2.1 ( shipped with FWH 10.1 )

i confirm 100% that GetProcAdd() is the appropriate call for xharbour 1.2.1 when using calldll() function.

In my coding, if I don't pass any parameters to a .DLL function - no problem. works perfectly.

But - if I MUST pass parameters to a .DLL function, then I get a GPF every time, using my
new configuration of xharbour 1.2.1 and FWH 10.1.

If I use EXACT SAME .DLL AND EXACT XHAROBUR SOURCE CODE for xharbour 0.99.51 and FWH 2006,
it works perfectly, with or without passing parameters from calling code to the .DLL function.

Don,

Please post here the DLL FUNCTION ... sentence that you have declared and how you are using it, thanks

Dear Antonio,

Whenever I upgrade xHarbour errors I have experienced.
Dll32 Function in FWH so without the use of xHabour dllcall () function is used.



Regards
bsm

Try



EMG

Here is code for my xHarbour 1.2.1 and BCC 5.5 and FWH 10.1

The actual dll can be downloaded from http://www.utilitywarrior.com/Image-to-PDF-Dynamic-Link-Library.htm

From that web-page, click the "download link" at the bottom of the page.

Don,

Please try to remove PASCAL from the declaration of those two functions that are failing.

Good News - Bad News

Removing PASCAL from all calls results in:

---

-- pass an integer ( LONG ) parm - SUCCESS!!!!

retval := I2PDF_SetDPI( 0 )

DLL STATIC FUNCTION I2PDF_SetDPI( nDpi AS LONG ) AS LONG;
FROM "I2PDF_SetDPI" LIB hLib

---

-- Pass a character string ( LPSTR ) -- GPF.

retval := I2PDF_License( "XXX-ZZZZ-AAAAA-BBBBBB-CCCCCCC" )

DLL STATIC FUNCTION I2PDF_License( cLicCode AS LPSTR) AS VOID;
FROM "I2PDF_License" LIB hLib

Try to call I2PDF_License() alone. It doesn't GPF.

EMG

Unfortunately, I must provide the license parameter for proper usage.

i wonder if the "big string" has some sort of ramification?

Is the definition of LPSTR appropriate?

retval := I2PDF_License( "XXX-ZZZZ-AAAAA-BBBBBB-CCCCCCC" )

DLL STATIC FUNCTION I2PDF_License( cLicCode AS LPSTR) AS VOID ;
FROM "I2PDF_License" LIB hLib

Yes, it is. But what I did want to point out is that if it works alone then the declaration must be correct.

EMG

I have discovered the nature of the problem!!!!

With the PASCAL parm in the DLL function definition, all calls were successful until I tried one using parameters. The 1st call with parameters caused the GPF.

After removing the PASCAL keyword in the DLL function definition, I was able to call a function successfully with parameters, ONCE. But, I could NOT call the DLL after that, regardless of the function, parameters, etc.

Regarding the function in question in prior postings ---- retval := I2PDF_License( "XXX-ZZZZ-AAAAA-BBBBBB-CCCCCCC" )
I successfully called the I2PDF_License( cString ) function, without the PASCAL keyword, passing a character parameter as LPSTR.
I'm sure all functions within the DLL work fine because I've used this DLL for several years.

Here is the nature of the problem with a code snippet to support my suspscion.

If no parms are passed - the DLL can be called as often as needed.
As soon as the DLL is called ONE TIME with a Parameter, ALL SUBSEQUENT CALLS, regardless of which function, produce a GPF.

It seems as if passing a parameter ONCE causes the process to fail on subsequent attempts.

I wonder if the CallDLL() function is not "starting fresh" each time, or maybe has some
info/garbage alive from the prior call, or something like that?