1. himanshi tayal
  2. PowerBuilder
  3. Thursday, 8 February 2024 17:13 PM UTC

Hello 

Migrating from PB 2009 to PB 2022 64 bit 

We are getting below error while calling external function :

Function calling from PB: 

FUNCTION long Fchgstr32 ( ulong buffer, ulong fldid, longptr occ, ref string fldval, longptr fldlen ) Library "pbtux32.dll" Progma_pack(1)

 

Defination in *.dll :

_TMDLLEXPORT long _TMDLLENTRY Fchgstr32(long buffer, DWORD fldid, long occ, char *fldvar, DWORD fldlen)
{
return(Fchg32((FBFR32 *)buffer, fldid, occ, fldvar, fldlen));
}

Please tell me which data type is mismatching here or not compatible with 64 bit as I have changed DWORD data type to QWORD but still same issue .

 

Andreas Mykonios Accepted Answer Pending Moderation
  1. Thursday, 8 February 2024 18:45 PM UTC
  2. PowerBuilder
  3. # 1

Hi.

What is the bitness of the dll?

Andreas.

Comment
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Thursday, 8 February 2024 18:49 PM UTC
  2. PowerBuilder
  3. # 2

Hi, Himanshi -

First, the DLL needs to be compiled as a 64-bit DLL in order to be called successfully by a 64-bit PB application.

Second, all parameters/arguments in the DLL and in PB that pass a memory address should be Longptr data type so they can hold a 64-bit address. The argument named "buffer" would appear to be one.

Best regards, John

Comment
  1. Armeen Mazda @Appeon
  2. Thursday, 8 February 2024 18:57 PM UTC
Adding to what John said, if you are migrating to 64-bit then you should carefully read through this migration guide and make necessary code changes. https://docs.appeon.com/pb2022r3/migrating_32bit_applications_to_64bit/index.html
  1. Helpful
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Thursday, 8 February 2024 19:38 PM UTC
  2. PowerBuilder
  3. # 3

You'll need a 64-bit version of the dll and use the proper data types:

DWORD = ULong

long = long

Memory pointer = LongPtr

char *fldvar appears to be an Ansi string so you need to add:  Alias For "Fchgstr32;Ansi"

Progma_pack is only for structures.

 

Comment
There are no comments made yet.
himanshi tayal Accepted Answer Pending Moderation
  1. Friday, 9 February 2024 11:58 AM UTC
  2. PowerBuilder
  3. # 4

we have build dll with 64 bit only still we are facing above issue 

 

Comment
There are no comments made yet.
himanshi tayal Accepted Answer Pending Moderation
  1. Friday, 9 February 2024 12:01 PM UTC
  2. PowerBuilder
  3. # 5

DLL is build on 64 bit and we use below only but still throwing error .

You'll need a 64-bit version of the dll and use the proper data types:

DWORD = ULong

long = long

Memory pointer = LongPtr

char *fldvar appears to be an Ansi string so you need to add:  Alias For "Fchgstr32;Ansi"

Progma_pack is only for structures.

 

Is there some inbuild function or some way through which we can check from which path it is picking the *.dll ?

 

Comment
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Friday, 9 February 2024 15:27 PM UTC
  2. PowerBuilder
  3. # 6

OK - Let's walk through it step-by-step:

Argument 1: long buffer
If this argument contains the address of a block of memory, then in 64-bit it needs to hold a 64-bit value. If the PB app is supplying the block of memory, such as a string that has been initialized to 10,000 (Unicode) spaces, for example, then preface the argument name in the external function declaration with the "REF" (pass by reference) keyword - and PB will pass the address of the PB variable: REF String buffer. If Tuxedo is expecting ANSI (single byte/character) data instead of UnicodeLE16 (two bytes/character), then the external function declaration will also have to include the optional phrase: ALIAS FOR "Fchgstr32;ansi".

Now, if Tuxedo has allocated the block of memory and has provided its address in another, different DLL function, then argument 1 should be declared as a PB Longptr. I cannot make that determination based on the limited information you have supplied.

Argument 2: DWORD fldid
As Roland explained, the PB equivalent to the typdef'd DWORD data type is ULong (UnsignedLong). Since this parameter does NOT appear to contain a memory address, it should keep the same data type: ULong fldid.

Argument 3: long occ
A data type of long is identical to the PB Long data type: Long occ.

Argument 4: char *fldvar
A null-delimited array of (single-byte, or ANSI) characters... in other words, a PB String. If the DLL function is going to change the contents of this string and PB needs to be able to see the changed value, then the string needs to be passed by reference (include the REF keyword, as in REF String fldvar). If PB does NOT need to be able to see any change to the string value, omit the REF keyword: String fldvar.

Argument 5: DWORD fldlen
Same explanation as argument 2: ULong fldlen

Return value: long
Same explanation as argument 3: Long

----------------------

No guarantees, since there are some aspects of arguments 1 and 4 that are not clear, but I suggest you try the following:

FUNCTION Long Fchgstr32 ( &
   REF String buffer, &
   ULong      fldid, &
   Long       occ, &
   String     fldvar, &
   ULong      fldlen &
) LIBRARY "pbtux32.dll" ALIAS FOR "Fchgstr32;ansi"

// or...

FUNCTION Long Fchgstr32 ( &
   Longptr buffer, &
   ULong   fldid, &
   Long    occ, &
   String  fldvar, &
   ULong   fldlen &
) LIBRARY "pbtux32.dll" ALIAS FOR "Fchgstr32;ansi"

Best regards, John

Comment
There are no comments made yet.
himanshi tayal Accepted Answer Pending Moderation
  1. Monday, 12 February 2024 10:28 AM UTC
  2. PowerBuilder
  3. # 7

Hello John ,

 

Thanks for your suggestion .

I have changed my code according to your suggestion ;

 Below are the changes :

Code changes done at PB side : 

FUNCTION long Fchgstr32 ( longptr buffer, ulong fldid, long occ, string fldval, ulong fldlen ) Library "pbtux32.dll"  alias for "Fchgstr32;Ansi"

 

Code at *.dll definition side :

_TMDLLEXPORT long _TMDLLENTRY Fchgstr32(FBFR32* buffer, ULONG fldid, long occ,char* fldvar, ULONG fldlen)
{
return(Fchg32(buffer, fldid, occ, fldvar, fldlen));
}

 

but still getting same error .

Did i  write something wrong ? :(

Comment
  1. Roland Smith
  2. Monday, 12 February 2024 13:30 PM UTC
Please explain the purpose of each argument. Include whether they are input or output arguments. Is buffer string or binary data?
  1. Helpful 1
  1. John Fauss
  2. Monday, 12 February 2024 14:47 PM UTC
@Himanshi - Yes, please. All you've given us so far is syntax with no context. Roland is correct, more information is needed. Also, the Tuxedo-dependent type definitions (_TMDLLEXPORT, _TMDLLENTRY, & FBFR32) are unknown to us... can you supply the standard C/C++ equivalents? I'm guessing the _TMDLLENTRY resolves to _stdcall, but I have no idea what a data type of FBFR32 is. Is there a web link to any online documentation that you can provide?
  1. Helpful 1
  1. himanshi tayal
  2. Tuesday, 13 February 2024 11:16 AM UTC
AS far i have checked i found below :



_TMDLLEXPORT : #define _TMDLLEXPORT __declspec(dllexport)

Use __declspec(dllexport) to export the function or method. You can export an entire C++ class by placing the __declspec(dllexport) before the class name, or you can export a single method by placing __declspec(dllexport) before the method name.

_TMDLLENTRY :#if defined(__BORLANDC__) && !defined(__cplusplus)

#define _TMDLLENTRY __declspec(dllexport) __stdcall

#else

#define _TMDLLENTRY __stdcall

#endif

FBFR32 : typedef struct Fbfr32 FBFR32;



Can you please refer this document may be it help :

https://docs.oracle.com/cd/E13203_01/tuxedo/tux71/html/rf3fml18.htm
  1. Helpful
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Wednesday, 14 February 2024 02:24 AM UTC
  2. PowerBuilder
  3. # 8

The information in the provided URL dates from the year 2000 and describes DLL functions implemented in 16-bit and 32-bit Windows. The initial 64-bit version of Windows was released available in 2005. A quick scan of that web page shows that the first argument is a pointer to a structure whose members are not described. In short, the web page information is almost no help.

The interfacing of a PB application to an external DLL entry point/function is a very low-level, detail-intensive process, where all of the details have to be correct in order for the interface to work. I have no confidence that the DLL you are wanting to interface with is actually a 64-bit DLL. If it is a 32-bit DLL, you will not be able to call it from a 64-bit PB application regardless of what you try.

It appears that you may have little experience calling external DLL functions from PB. What you are trying to accomplish requires a moderate level of expertise. For example, if PB is to pass a structure by reference (passing the memory address of, or pointer to, the structure), then PB needs to define that structure and its members using PB data types. The same for all of the calling arguments... you have to be certain you are specifying the PB data types that directly correspond with the typedef'd data types the DLL is expecting. PB needs to own/control the memory used by the variables/structures that the DLL may affect. Is character/string information to be encoded in Unicode16LE or ANSI? Are structure members laid out in memory with (standard) 8-byte alignment or 1-byte alignment? Which calling parameters are input values, output values, or both?

Have you been able to successfully call this function from a 32-bit PB app and a 32-bit DLL? If not, this is where I would focus my efforts. Perhaps with just an experimental, test application. Maybe with a simple or at least simpler Tuxedo function?

If you need practice coding PB external function declarations, I suggest you try calling a variety of Windows API functions from a test app. In the Tech Articles section in the Community, there is a four-part series that covers many aspects of interfacing PB with external DLL functions. Here is the URL to the first part:

    https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder/302-interfacing-pb-applications-with-the-windows-api-part-1

I regret that I am unable to provide you with additional assistance, but I want to wish you Good Luck.

 

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.