Access Violation When Function Reaches END;

[Weitentaaal]

Hello Guys

My Problem:
I Call a External DLL and already had many Problems with String Conversations.
Now i Got this AV but it doesn't tell me much where the Error is.

Here my Code:

Code: Pascal  [Select][+][-]

1.  
2. //Def
3. TZAJsonRequestBSTR = Function(sRequest : WideString): WideString; stdcall;
4.  
5. //Calling The DLL
6. Function Call_ZAJsonRequestBSTR(sRequest : WideString): WideString;
7. var
8.    // Legt eine passende Variable (Datenfeld) für das DLL-Unterprogramm an
9.    ZAJsonRequestBSTR : TZAJsonRequestBSTR;
10.    // Legt einen Handle für den Handle der DLL an
11.    LibHandle: THandle;
12. begin
13.    //Einbinden Der DLL
14.    LibHandle := LoadLibrary(PChar('C:\DLLS\FANselect.dll'));
15.    if(LibHandle <> 0)then begin
16.       // Weisst der Variablen ZAJsonRequestBSTR die Adresse des Unterprogrammaufrufs zu
17.       // 'ZAJsonRequestBSTR' aus der DLL FANSelect.dll zu.
18.       Pointer(ZAJsonRequestBSTR) := GetProcAddress(LibHandle, 'ZAJsonRequestBSTR');
19.  
20.       // Prüft, ob eine gültige Adresse zurück gegeben wurde
21.       if @ZAJsonRequestBSTR <> nil then begin
22.          //Blackbox aufrufen
23.          result := ZAJsonRequestBSTR(sRequest);
24.       End;
25.    End;
26.  
27.    // Freigabe des Arbeitsspeichers
28.    ZAJsonRequestBSTR := nil;
29.    FreeLibrary(LibHandle);
30. end;
31.  
32.  
33. //Calling in Code
34. //Both Strings Here are WideStrings (because WideString Supports COM Memory of BSTR)
35. JZaRueckgabe := DLLAufrufe.Call_ZAJsonRequestBSTR(JZa);
36.      
37.  

Hope u can help me.

[Zvoni]

WideString vs. PWideString?

Without seeing the Function-Prototype of the dll-function it's gazing into a crystal ball

[Weitentaaal]

There is the Problem .. i dont't Have the DLL Code 

Tested With PWideString but got the Same Error.

The Calling Worked Fine in VB6, checked if i Have the Same input, wich i had. But no Output Somehow.
But Still why do i get Av when the Code reaches End; ? is it because of an empty String wich returns ?

[Mr.Madguy]

Please provide initial VB6 declaration of this function. I guess, problem is caused by simple fact, that string is allocated by DLL's memory manager and FPC fails to deallocate it properly. BSTR is OLE string, allocated by SysAllocString. May be it should be represented as OleVariant? Is your application 32bit? Because VB6 is 32bit and therefore DLL should be 32bit too.

[Weitentaaal]

VB6 Code :

Code: Pascal  [Select][+][-]

1.      
2.       //Definition    
3.       Public Declare Function ZAJsonRequestBSTR Lib "C:\WGKBlck\Ziehl-Abegg\FANselect.dll" (ByVal sRequest As String) As String
4.  
5.       //Called like that
6.       JZa = StrConv(JZa, vbUnicode)
7.       JZa2 = StrConv(JZa2, vbUnicode)
8.    
9.       JZaRückgabe = StrConv(ZAJsonRequestBSTR(JZa), vbFromUnicode)
10.  

Didn't Tested with OLE variant till now.

Application is 32 bit

[Zvoni]

IIRC, in vb6 passing a String ByVal to an external dll is still passing the address to the String.
And a Returntype of string is probably still a pointer to the Resultstring
That's why i figured PWideString.
Have you tried both as PWideString? the Argument and the return-Type?

[PascalDragon]

Here my Code:

Two remarks (though both are probably not related to your problem):

- you need to use FreeLibrary only if LibHandle is not 0
- to check whether the function was loaded correctly you need to use ZAJsonRequestBSTR <> Nil (or Assigned(ZAJsonRequestBSTR)); using @ZAJsonRequestBSTR will check whether the variable itself has a valid address.

IIRC, in vb6 passing a String ByVal to an external dll is still passing the address to the String.
And a Returntype of string is probably still a pointer to the Resultstring
That's why i figured PWideString.
Have you tried both as PWideString? the Argument and the return-Type?

According to the manual (page 42) of the library the C(++) declaration for the functions is as follows:

Code: C  [Select][+][-]

1. external “C” {
2.   __declspec(dllimport)
3.   const char* __stdcall ZAJsonRequestA(const char *szReq);
4.  
5.   __declspec(dllimport)
6.   const wchar_t* __stdcall ZAJsonRequestW(const wchar_t *szReq);
7.  
8.   __declspec(dllimport)
9.   const BSTR __stdcall ZAJsonRequestBSTR(BSTR sReq);
10. }

So using WideString instead of PWideString is indeed correct.

[Weitentaaal]

Not Sure what i should do next but i bet the Problem is there because of the type.

The Function did the Job it had to in vb6 so there must be the Problem in the in and output, but i don't get it.

WideString Should be Supported by BSTR or am i wrong ?
So where else could this Call go wrong ?

I Will Test if its Working with pointers...

Thanks for ur Replys, i realy appreciate.

[Zvoni]

Here my Code:

Two remarks (though both are probably not related to your problem):

- you need to use FreeLibrary only if LibHandle is not 0
- to check whether the function was loaded correctly you need to use ZAJsonRequestBSTR <> Nil (or Assigned(ZAJsonRequestBSTR)); using @ZAJsonRequestBSTR will check whether the variable itself has a valid address.

IIRC, in vb6 passing a String ByVal to an external dll is still passing the address to the String.
And a Returntype of string is probably still a pointer to the Resultstring
That's why i figured PWideString.
Have you tried both as PWideString? the Argument and the return-Type?

According to the manual (page 42) of the library the C(++) declaration for the functions is as follows:

Code: C  [Select][+][-]

1. external “C” {
2.   __declspec(dllimport)
3.   const char* __stdcall ZAJsonRequestA(const char *szReq);
4.  
5.   __declspec(dllimport)
6.   const wchar_t* __stdcall ZAJsonRequestW(const wchar_t *szReq);
7.  
8.   __declspec(dllimport)
9.   const BSTR __stdcall ZAJsonRequestBSTR(BSTR sReq);
10. }

So using WideString instead of PWideString is indeed correct.

Wait a sec.

A BSTR is a composite data type that consists of a length prefix, a data string, and a terminator. The following table describes these components.
Remarks
Item    Description
Length prefix    A four-byte integer that contains the number of bytes in the following data string. It appears immediately before the first character of the data string. This value does not include the terminator.
Data string    A string of Unicode characters. May contain multiple embedded null characters.
Terminator    A NULL (0x0000) WCHAR.

How does WideString handle that?

@Weitentaaal: Have you tried the ZAJsonRequestW-Function?

[Mr.Madguy]

How does WideString handle that?

@Weitentaaal: Have you tried the ZAJsonRequestW-Function?

Manual says, that WideString is right type for BSTR. But using ZAJsonRequestW is better idea.

I would also use asm debugger to find exact cause of this problem.

[lucamar]

Wait a sec.

A BSTR is a composite data type that consists of a length prefix, a data string, and a terminator. The following table describes these components.
Remarks
Item    Description
Length prefix    A four-byte integer that contains the number of bytes in the following data string. It appears immediately before the first character of the data string. This value does not include the terminator.
Data string    A string of Unicode characters. May contain multiple embedded null characters.
Terminator    A NULL (0x0000) WCHAR.

How does WideString handle that?

Exactly like that; see the Programmer's Guide,  Memory Issues: WideStrings. It can't be otherwise since its main use is for COM interfaces.

[Weitentaaal]

Finished work for Today but i will try it Tomorrow. Thank u all Guys for ur patience with me .

[engkin]

Wait a sec.

A BSTR is a composite data type that consists of a length prefix, a data string, and a terminator. The following table describes these components.
Remarks
Item    Description
Length prefix    A four-byte integer that contains the number of bytes in the following data string. It appears immediately before the first character of the data string. This value does not include the terminator.
Data string    A string of Unicode characters. May contain multiple embedded null characters.
Terminator    A NULL (0x0000) WCHAR.

How does WideString handle that?

Exactly like that; see the Programmer's Guide,  Memory Issues: WideStrings. It can't be otherwise since its main use is for COM interfaces.

I see a difference, the length is in negative location offset. Am I right?

Edit:
If am right, the dll function is taking the first four byes of the WideString, that is the first two WideChars, as the wrong length of the string. For a string like: 'ABC', this would seem to the dll function as a string that is $00420041 bytes long, while in fact it is only 6 bytes long plus two terminating bytes.

[Mr.Madguy]

I see a difference, the length is in negative location offset. Am I right?

Edit:
If am right, the dll function is taking the first four byes of the WideString, that is the first two WideChars, as the wrong length of the string. For a string like: 'ABC', this would seem to the dll function as a string that is $00420041 bytes long, while in fact it is only 6 bytes long plus two terminating bytes.

Managed strings work exactly this way in Pascal - they have explicit length field and trailing null.

[engkin]

I see a difference, the length is in negative location offset. Am I right?

Edit:
If am right, the dll function is taking the first four byes of the WideString, that is the first two WideChars, as the wrong length of the string. For a string like: 'ABC', this would seem to the dll function as a string that is $00420041 bytes long, while in fact it is only 6 bytes long plus two terminating bytes.

Managed strings work exactly this way in Pascal - they have explicit length field and trailing null.

Not exactly,. The offset is negative, AND the value of length is the number of (Wide)Chars, instead of bytes. For WideString, that is 3 instead of 6 in the 'ABC' example.

WideString in not equivalent to BStr.

Edit:
Both, WideString and BStr, use negative offset for length. But the value is not the same.