Framework V2.0

Hi,

Or are you planing to implement a 100% percent native .net dll that will work under x64 and ia32 .net framework without replacing the dll? <<

This is planned.

Julian

Hi

The proble is not that pinvoke has to be enabled. The problem is, that a stack imbalance has ocurred by calling the GetDC function

The GetDC function needs as parameter a intptr type because it's a handle and not a long. So after calling the function, the stack is not correctly in the way .net expects it because the type was not the excpected one of the dll. .net 2 is very strict in checking such things, this could be disabled but I think it's better to change it to the correct parameter instead of disabling this check.

Here's the fix.

Take the wrapper dll source code and change the following. In the file wpdfinterface.cs in the class wWindowsWrap change the GetDC definition from

public static extern IntPtr GetDC(long handle); // We need to call this with '0'

to

public static extern IntPtr GetDC(IntPtr handle); // We need to call this with '0'

same for the ReleaseDC, the handle parameter's type has to be intptr.

In the file class1.cs change the calls to getdc and releasedc. Change all '0' parameter values to intptr.zero.

That will fix the problem.

Another question to you Julian. Are you going to develop a x64 version of the wpdfcontrol dll? Or are you planing to implement a 100% percent native .net dll that will work under x64 and ia32 .net framework without replacing the dll?

Kind Regards
Fabrizio

Hi,

thanks, I'll check that.

wPDFControl however is based on a native Win32 conversion engine so PInvoke must be enabled.

Julian

I am trying to execute the following code and I get the following error message.
Any idea?

<CODE>
Dim pdf As New wPDF.PDFControl
pdf.SetLicense("aaaa","bbbb", 00000)
pdf.BeginDoc("test.pdf")
pdf.DrawImage(Image.FromFile("image.jpg"))
pdf.EndDoc()

<ERROR>
Detected PInvokeStackImbalance

**

*A call to PInvoke 'wPDF!wPDF.wWindowsWrap::GetDC' function blocked
the correspondence of the stack. The possible reason could be the PInvoke administrated sign not having coincidance with the sign of destination not administrated...*