FiveTech Support Forums

Did you try to load/unload the dll for each call?

EMG

Yes.

1st all DLL functions were constructed with the DLL handle value.
These constructs do not load/unload the library and I was required to do it at the beginning and FreeLibrary( ndll ) at the end.

Then, I changed the construct to use the DLL name, which forces the load/unload each time.



this, obviously, took much longer to run, but, the results were identical.

I'm leaning towards the issue might possibly be within the CallDLL( ) function within FWH. I haven't tried the xHarbour DLLCall function yet. I'm hoping to get this resolved within the FWH world as I have many applications calling these types of DLL's and preservation of existing code would be nice.

More Information

I instructed the DLL to output messages to the console.

It appears that the process was completed by the DLL and the GPF occurs upon the RETURN of control from the DLL back to the CallDLL( ) function.

retval := I2PDF_AddImage(alltrim( infile ) ) // processed ok
retval := I2PDF_MakePDF( outfile, 0, @cBuffer , 300 ) // processed ok - created the .PDF file, but control never returned back to my program.

Here is what was on the screen (also, the pdf file was successfully created!)

* Application successfully built *
15:56:37 Creating PDF structure in memory
15:56:37 0001: [testreport.emf]
15:56:37 Saving PDF (1 pages) to [DEBUG-report.pdf]
15:56:37 Save complete

T:\FWH10\samples>

The GPF occured AFTER the "Save complete" message appeared on the console screen - thus, I believe the commands are being processed to completion by the DLL but control is not being returned back to my program from the CallDLL() function.

I processed the DLL function "manually" with the following code and it had a GPF during the CallDLL() function call:

Don,

The licence function is pascal for sure:

If you remove pascal from it, then it will GPF. Pascal means that the called function balances the calling C stack itself.

Don,

This code is working fine here. Please notice that the shown version is 252. Could it be that you are using a wrong DLL ?

I'm also using version 252. The DLL is dated
04/11/2009 11:17 PM 1,003,520 Image2PDF.dll

I get the exact same results with an older version 240 which has worked perfectly for us in the past.
05/15/2008 10:20 PM 865,792 Image2PDF.dll

I tried your code snippet and it GPF's here. I put the debugger in the program and it behaved exactly the same as I described in a prior posting.

Can you show me the compile and link scripts you used? Maybe I'm not using correct libraries or compile switches?

Don,

I tested it using Harbour and Borland C. Used standard FWH samples buildh.bat

Are you using Harbour or xHarbour ?

I used xHarbour and Harbour with the buildx.bat and buildh.bat supplied with FiveWin

both got gpf.

here is the Harbour link script from b32.bc using Harbour 2.0 shipped with FWH

c:\borland\bcc55\lib\c0w32.obj +
dllpdf.obj, +
dllpdf.exe, +
dllpdf.map, +
...\lib\FiveH.lib ...\lib\FiveHC.lib +
t:\harb20\lib\win\bcc\hbrtl.lib +
t:\harb20\lib\win\bcc\hbvm.lib +
t:\harb20\lib\win\bcc\gtgui.lib +
t:\harb20\lib\win\bcc\hblang.lib +
t:\harb20\lib\win\bcc\hbmacro.lib +
t:\harb20\lib\win\bcc\hbrdd.lib +
t:\harb20\lib\win\bcc\rddntx.lib +
t:\harb20\lib\win\bcc\rddcdx.lib +
t:\harb20\lib\win\bcc\rddfpt.lib +
t:\harb20\lib\win\bcc\hbsix.lib +
t:\harb20\lib\win\bcc\hbdebug.lib +
t:\harb20\lib\win\bcc\hbcommon.lib +
t:\harb20\lib\win\bcc\hbpp.lib +
t:\harb20\lib\win\bcc\hbcpage.lib +
t:\harb20\lib\win\bcc\hbwin.lib +
t:\harb20\lib\win\bcc\hbcplr.lib +
c:\borland\bcc55\lib\cw32.lib +
c:\borland\bcc55\lib\uuid.lib +
c:\borland\bcc55\lib\import32.lib +
c:\borland\bcc55\lib\psdk\odbc32.lib +
c:\borland\bcc55\lib\psdk\nddeapi.lib +
c:\borland\bcc55\lib\psdk\iphlpapi.lib +
c:\borland\bcc55\lib\psdk\msimg32.lib +
c:\borland\bcc55\lib\psdk\rasapi32.lib,
dllpdf.res

here is link script using xHarbour 1.2 shipped with FWH

C:\Borland\BCC55\lib\c0w32.obj +
dllpdf.obj, +
dllpdf.exe, +
dllpdf.map, +
...\lib\Fivehx.lib ...\lib\FiveHC.lib +
T:\XHARB12\lib\rtl.lib +
T:\XHARB12\lib\vm.lib +
T:\XHARB12\lib\gtgui.lib +
T:\XHARB12\lib\lang.lib +
T:\XHARB12\lib\macro.lib +
T:\XHARB12\lib\rdd.lib +
T:\XHARB12\lib\dbfntx.lib +
T:\XHARB12\lib\dbfcdx.lib +
T:\XHARB12\lib\dbffpt.lib +
T:\XHARB12\lib\hbsix.lib +
T:\XHARB12\lib\debug.lib +
T:\XHARB12\lib\common.lib +
T:\XHARB12\lib\pp.lib +
T:\XHARB12\lib\pcrepos.lib +
C:\Borland\BCC55\lib\cw32.lib +
C:\Borland\BCC55\lib\import32.lib +
C:\Borland\BCC55\lib\uuid.lib +
C:\Borland\BCC55\lib\psdk\odbc32.lib +
C:\Borland\BCC55\lib\psdk\rasapi32.lib +
C:\Borland\BCC55\lib\psdk\nddeapi.lib +
C:\Borland\BCC55\lib\psdk\msimg32.lib +
C:\Borland\BCC55\lib\psdk\iphlpapi.lib,
dllpdf.res

Don,

Please download my test files and run them in your computer, thanks

http://www.mediafire.com/?zjmntm3rk2n

your test.exe file works fine here.

I recompiled with my version of buildx.bat and buildh.bat and both created GPF's.

can you show me the b32.bc output you used from both the compile and link step?

Don,

c:\bcc55\lib\c0w32.obj +
C:\test.obj, +
C:\test.exe, +
C:\test.map, +
c:\fwh\lib\FiveH.lib c:\fwh\lib\FiveHC.lib +
c:\harbour\lib\hbrtl.lib +
c:\harbour\lib\hbvm.lib +
c:\harbour\lib\gtgui.lib +
c:\harbour\lib\hblang.lib +
c:\harbour\lib\hbmacro.lib +
c:\harbour\lib\hbrdd.lib +
c:\harbour\lib\rddntx.lib +
c:\harbour\lib\rddcdx.lib +
c:\harbour\lib\rddfpt.lib +
c:\harbour\lib\hbsix.lib +
c:\harbour\lib\hbdebug.lib +
c:\harbour\lib\hbcommon.lib +
c:\harbour\lib\hbpp.lib +
c:\harbour\lib\hbcpage.lib +
c:\harbour\lib\hbwin.lib +
c:\harbour\lib\hbcplr.lib +
c:\harbour\lib\hbct.lib +
c:\harbour\lib\xhb.lib +
c:\bcc55\lib\cw32.lib +
c:\bcc55\lib\uuid.lib +
c:\bcc55\lib\import32.lib +
c:\bcc55\lib\psdk\odbc32.lib +
c:\bcc55\lib\psdk\nddeapi.lib +
c:\bcc55\lib\psdk\iphlpapi.lib +
c:\bcc55\lib\psdk\msimg32.lib +
c:\bcc55\lib\psdk\rasapi32.lib,

I email you a copy of FiveH.lib and FiveHC.lib

I noticed that xHarbour also has a function named CallDLL().

Is it possible my environment is mistakenly calling the xHarbour CallDLL() version and the parm passing convention is different.

does your CallDLL and xHarbour CallDLL maybe get mixed up in my environment?

I used the xHarbour and Harbour DLLCALL() FUNCTION and it seems to work fine.

I suspect the problem is within CALLDLL() function - perhaps I'm invoking the harbour CallDLL() and not the FWH CallDLL() ???


This Works

Don,

In the libs that I have sent you CallDll() has been renamed to FWCallDll() to avoid conflicts with Harbour/xHarbour.

Simply call FWCallDll() from your code or modify DLL.ch to call FWCallDll(), thanks

Don,

I use Image2PDF with xHarbour.

One thing I noticed is that you renamed the dll to Image2PD.dllF and this generates a lot of problems.

Make the call and keep the dll with its default name - Image2PDF StdCall.dll.