World: r3wp

See, the library handle comes from the standard library loading function 
(well, Windows standard)

Yes, that would make your binding work the same way as the C code, 
so if that doesn't work, you definitely know the problem is elsewhere

Can you show your complete #import specification and the definition 
of a function that doesn't work?

#import [

   "LedCtrl.dll" cdecl [

      led-is-power?: "LSN_IsPower" [
         return: [logic!]
      ]

      led-open-card: "LSN_OpenCard" [
          return: [logic!]
      ]  

      led-get-screen-number: "LSN_GetLedScrNumb" [
          return: [integer!]
      ]

      led-set-power: "LSN_Power" [
         power-on? [logic!]
         return: [logic!]
      ]

      led-get-brightness: "LSN_GetBright" [
         return: [integer!]
      ]

led-get-brightness is the first one to fail ...

your lib uses stdcall, so better use stdcall instead of cdecl (though 
that's most likely not the culprit here)

I used that, I changed it later to give it a try ...

rest looks good to me, at first glance

just to be sure: in the code example from the LEDSet program you 
gave earlier, is there maybe some initialisation function called 
_after_ all the proc addrs have been retrieved?

there is plenty of ASSERT(fpIsPower		!= NULL);, for each funcitons, 
then function LoadLedCtrl returns true ...

well, I am bothering you here more, than if I would upload somewhere 
a project file with all sources. The app is really small, but I might 
be missing some obvious setting or something else :-)

An initialisation function is indeed a good candidate for the problem

http://xidys.com/pekr/ledset-source.zip

It's not that obvious, the C code does strange indirections :-)

Kaj - so I defined following functions. It returns something :-) 
Hopefully I have an integer handle, representing the "address"? of 
the requested function. Now is the last step you described - how 
should I invoke it?

   "Kernel32.dll" stdcall [

      load-library: "LoadLibraryA" [
         name [c-string!]
         return: [integer!]
      ]
       
      get-proc-address: "GetProcAddress" [
         library-handle [integer!]
         function-name  [c-string!]
         return: [integer!] 
       ]

   ]

print ["load-library: " handle: load-library "LedCtrl.dll" lf]

print ["get-proc-address: " get-proc-address handle "LSN_IsPower" 
lf]

led-power?: function [
	handler		[function! [return: [logic!]]]
	return:		[logic!]
][
	handler
]

led-power? as function! get-proc-address handle "LSN_IsPower"

Something like that, but I'm not sure the casting to function! type 
will be accepted

get-proc-address should really be defined as return: [function!] 
but that's not currently supported

*** Compilation Error: invalid definition for function led-power?: 
[function! [return: [logic!]]]

Ah, that's only supported in import functions, I think. That's why 
I handle them as integers everywhere, but then you can't call it 
as a function. So game over

I will return to serial communication decoding, although that's not 
much fun :-)

Some Red/System type casting will not help? :-)

No, because those casts aren't supported yet

Anyway - it was a good way to learn a few bits in a practical manner 
:-)

I can't find anything in the C++ code, though, that would necessitate 
manual loading. It looks like the regular #import should work. What 
errors are you getting exactly from those functions?

*** Runtime Error 99: unknown error
*** at: 7572FC56h

Doc may need to have a look at it

R2 and World crash. In fact I think that those functions just try 
to write to serial port ...

If R2 and World crash the same way, manual loading doesn't help

What happens when you call the same functions in C or C++?

I haven't try. There are their Ex variants, imo related to dialog 
boxes. In fact I haven't tried anywhere in the source call to those 
funcs. So maybe those are called from dialog boxes.

That would be the definitive test whether the problem is in the Red 
binding or not

LedSetDlg.cpp does:

fpSetLanguage(m_nLanguage);//set language  1= chinese english=3

why would it be a proof?

Maybe there's no default language so that's needed. Or the default 
is Chinese and you don't have Chinese support installed or something 
like that

You don't know if the C functions don't do the very same thing as 
the Red binding

m_nLanguage = 0; //for auto

I wrapped a dialog box call, as DLL can cal e.g. LSN_BrightDlg, and 
it opens in English. When I explicitly call a language setting function, 
later on, set/get brightness still crashes ... I will see moving 
to the PC, where the sending card to LED screen actually is.

OK, enough for this weekend. Thanks for the assistance :-)

If you haven't tested this on the machine with the hardware, anything 
is possible. That's why calling the C functions would have tested 
such things

I tested it initially also on that machine. As I said - I was able 
to turn screen on/off, to get is-power? returning proper values ....

That means #import basically works for this library, so the other 
functions should also be able to be made to work

The Ex function variants are not about dialogs. They take an extra 
integer parameter for the screen number, when there are multiple 
LED screens

The sample code uses the Ex functions. There may be a bug in the 
simple functions, so you should try the Ex functions instead

CLedSetApp::InitInstance() does this:

#ifdef _AFXDLL

 Enable3dControls();			// Call this when using MFC in a shared DLL
#else

 Enable3dControlsStatic();	// Call this when linking to MFC statically
#endif

I don't know why that would affect communication with the device, 
but since the library itself contains MFC dialogs, it may need one 
of these initialisation functions

(See also: Not REBOL) In this way, RED could be renamed to ROD with 
many positive and complex connotations :)