in reply to Re: Calling a function form an external DLL with Inline::C on windows
in thread Calling a function form an external DLL with Inline::C on windows

Thanks to the help from BrowserUK, I've already figured out that I have to write wrapper functions.

I've tried it the way you did above:

int wrap_RegisterClient2(int cl_id, char* read_ip) {
  return RegisterClient2(cl_id, read_ip);
}

[download]

but it doesn't work, I get the same error message as in the case without the wrapper.

It works with BrowserUK's method. In fact, I have to go one step further:

int wRegisterClient2( SV *id, SV *IP ) {
    int c_id = SvIV( id );
    char *c_ip = SvPVX( IP );
    int result = RegisterClient2( &c_id, c_ip );
    printf("%d", c_id);
    sv_setiv(id, (IV) c_id);
    return result;
}

[download]

Basically, the purpose of this RegisterClient2 function is to establish contact with the instrument that listens on the given IP address, and it gives back a unique numeric id in nClientId that I have to use in further calls. And if I want to access this id from Perl, I have to write back the integer value into the SV that was passed to the wrapper.

So what follows now is me rolling up my sleeves and go elbow-deep into perlguts.

Thanks to the advice anyway.

Replies are listed 'Best First'.
Re^3: Calling a function form an external DLL with Inline::C on windows
by BrowserUk (Patriarch) on Aug 06, 2010 at 12:21 UTC
    I've tried it the way you did above: 
    int wrap_RegisterClient2(int cl_id, char* read_ip) {
  return RegisterClient2(cl_id, read_ip);
}

    [download]
    but it doesn't work, I get the same error message as in the case without the wrapper.

    The problem, I believe, is that unless all the parameters, and the return type, are types that the default typemap knows how to handle, Inline::C doesn't wrap and export it. And it appears that the default typemap doesn't know how to handle int *.

    So, whilst this works fine: 

    #! perl -slw
use strict;
#use Inline C => Config => BUILD_NOISY => 1;
use Inline C => <<'END_C',  NAME => '_test', CLEAN_AFTER_BUILD => 0;

int test( int i ) {
    return i;
}

END_C

print test( 123 );
__END__
C:\test>test
123

    [download]

    This doesn't: 

    #! perl -slw
use strict;
#use Inline C => Config => BUILD_NOISY => 1;
use Inline C => <<'END_C',  NAME => '_test', CLEAN_AFTER_BUILD => 0;

int test( int *i ) {
    return *i;
}

END_C

print test( 123 );

__END__
C:\test>test
Warning. No Inline C functions bound to Perl in C:\test\test.pl
Check your C function definition(s) for Inline compatibility

Use of inherited AUTOLOAD for non-method main::test() is deprecated at
+ C:\test\test.pl line 12.
Can't locate auto/main/test.al in @INC (@INC contains: C:\test\_Inline
+\lib C:/Perl64/site/lib C:/Perl64/lib .) at C:\test\test.pl line 12

    [download]

    There is the TYPEMAPS configuration option, but I haven't seen any (good) documentation on that. And finding the default typemap and looking at that doesn't yield many clues.

    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.
[reply]
[d/l]
[select]
      Seems like a correct diagnosis.

      However, it is possible to work around this issue by declaring all parameters of the wrapper functions as SV*, then manipulating their contents inside - just as you've showed it.

      Now I've written all these wrapper functions, and consequently I'm able to get data from the instrument.

      All that's left is to integrate it with the existing robot movement and EUT-driver code. I hope I won't run into any further issues with timing, serial comms, windows dark magic, etc.
[reply]
        I hope I won't run into any further issues with timing, serial comms, windows dark magic, etc.

        Of course there are further issues.

        Win32::SerialPort uses Win32::CommPort which uses Win32::API to export some functions from the Windows API. And it seems that Win32::API doesn't like to work together with Inline::C - at least serial communication doesn't work with the solution derived in the posts above. I get a deluge of error messages, like
        Use of uninitialized value in subroutine entry at C:/Perl/site/lib/Win
+32API/CommPort.pm line 213.
Use of uninitialized value in subroutine entry at C:/Perl/site/lib/Win
+32API/CommPort.pm line 247.
Second Read attempted before First is done at measure.pl line 402
Use of uninitialized value $got in numeric ne (!=) at C:/Perl/site/lib
+/Win32/SerialPort.pm line 1216.
Use of uninitialized value in subroutine entry at C:/Perl/site/lib/Win
+32API/CommPort.pm line 213.
Use of uninitialized value in subroutine entry at C:/Perl/site/lib/Win
+32API/CommPort.pm line 247.
Second Read attempted before First is done at measure.pl line 402
Use of uninitialized value $got in numeric ne (!=) at C:/Perl/site/lib
+/Win32/SerialPort.pm line 1216.

        [download]
[reply]
[d/l]
Re^3: Calling a function form an external DLL with Inline::C on windows
by syphilis (Archbishop) on Aug 06, 2010 at 12:50 UTC
    I've already figured out that I have to write wrapper functions.

    Yes, the reference (in the update) to "yesterday's news" was meant to be acknowlegement of the fact that the isssue had already been resolved :-)

    Cheers,
    Rob
[reply]

In Section Seekers of Perl Wisdom