Hi.

What is the bitness of the dll?

Andreas.

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

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.

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

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

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

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

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 ? :(

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.