# So, I used INT , The following way is working for some other API but not this API :(

That should work.

Given this dll:

#include <stdio.h>

__declspec(dllexport) unsigned char __stdcall getChar() {
    unsigned char c = (unsigned char)( rand() & 0xFF );
    printf( "Returning %d\n", c );
    return c;
}
[download]

This script:

#! perl -slw
use strict;
use Win32::API;

my $getChar = Win32::API->Import( 'junkdll', 'int getChar()' )
    or die $!, $^E;

print getChar() for 1 .. 10;
[download]

Produces this output:

C:\test>t-w32api.pl
Returning 41
41
Returning 35
35
Returning 190
190
Returning 132
132
Returning 225
225
Returning 108
108
Returning 214
214
Returning 174
174
Returning 82
82
Returning 144
144
[download]

Not the most convenient form (numeric) to receive 'char' data, but you seem to want the numeric value anyway. You're just working too hard at trying to convert the value when there is no need to.

Hi BrowserUk

For some reason, having 'int' and getting data from my DLL is not working well.

my $i2cGetDeviceAddressFunc = Win32::API->new('CrdI2C32', 'int i2cGetD
+eviceAddress()') or warn "\n ERROR: Can not import API:i2cGetDeviceAd
+dress ,  $^E ,";

my $ret = 0;

$ret = $i2cGetDeviceAddressFunc->Call();

print "\n RET: $ret";
[download]

Output

1. Run
 RET: 53113496

2. Run
RET: 52195992

3. Run
RET: 52851352

4. Run
RET: 52458136

5. Run
 RET: 51540632
[download]

Output is not what i expected and more over every run, it produce different output. But the C code which calls the i2cGetDeviceAddress() API produces same output always.

I don't have source code of the DLL (CRDI2C32.DLL) , We bought this from other company, They gave C, C++, VB & PASCAL example code which has API prototypes.

PASCAL Sample:

xx.pas

Function  i2cGetDeviceAddress : Byte;                                 
+               stdcall; external 'CrdI2C32.DLL';

C Sample:

xx.h
typedef unsigned char __stdcall i2cGetDeviceAddress_type();
extern i2cGetDeviceAddress_type *i2cGetDeviceAddress;

xx.c
i2cGetDeviceAddress_type *i2cGetDeviceAddress = NULL;
....
 i2cGetDeviceAddress = (i2cGetDeviceAddress_type*)GetProcAddress(hDll,
+"i2cGetDeviceAddress");
  if (i2cGetDeviceAddress == NULL) {
    FreeLibrary(hDll);
    return 22; // function not found in library
  }

VB Sample:

xx.bas

 Declare Function i2cGetDeviceAddress Lib "CrdI2C32.DLL" () As Byte

[download]

I didn't look in detail (I suspect the relevant details could be buried quite deep), but it looks likely to be a bug in Win32::API to me.

Even if not a bug in Win32::API, it looks like an uninitialized four-byte value is having only some of its bytes overwritten. So why not just work around it and pull out only the byte you care about?

$ret &= 0xFF;
[download]

Though, the return values you show actually show the lowest two bytes being consistently 0x7298, which seems rather unlikely.

printf "%d 0x%x\n", $_, $_
    for 53113496, 52195992, 52851352, 52458136, 51540632
53113496 0x32a7298
52195992 0x31c7298
52851352 0x3267298
52458136 0x3207298
51540632 0x3127298
[download]

...So it could easily be neither of the things I guessed. Is 0x98 (152) the value you are expecting to get?

- tye        

We bought this from other company

The one you have seems to be broken. What size is it? You probably need to send it back under warranty and exchange it for a new one.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?