Save a pointer returned from a dll and use it after any time

[galtech]

I use a DLL where one fonction return a pointer to a int value. At the moment of the execution a this fonction, the value in the adresse of the pointer is null. After a time (about 500ms) the value is ok. How can I "read" the value at this time. Can I save the pointer of this int value to use it after ? Thanks in advance and sorry for my english (french speeking)

[rolfk]

galtech wrote:

> I use a DLL where one fonction return a pointer to a int value.
> At the moment of the execution a this fonction, the value in the
> adresse of the pointer is null. After a time (about 500ms) the
> value is ok. How can I "read" the value at this time. Can I save
> the pointer of this int value to use it after?

Let me say this: This way of working is ABSOLUTELY nasty for a DLL!
It counters any proper programming style and makes multithreading with
this DLL virtually impossible. In DOS times this might have been a valid
way of operation but under a multithreading OS this is really not the
way to go.

Who can guarantee you that the DLL is still loaded when you try to
reference the pointer? There are other possible problems with this some
real and others might be not a problem yet but might get one in future
versions of OSses.

That said there is of course always a way to make this work although not
with a full guarantee that it will never crash under special
circumstances such as low memory situations or similar, which are beyond
your application control.

Configure the parameter of your Call Library Node as an uInt32 passed by
Value.

Then create a new Call Library Node and fill in folowing:

Library Name: LabVIEW
Function Name: MoveBlock
Calling Convention: cdecl
Execute in UI Thread

Return Value: void
1. Parameter: Name: source; Type: uInt32 passed by Value
2. Parameter: Name: dest; Type: int32 passed as Pointer
3. Parameter: Name: len; Type: int32 passed by Value

Wire your returned pointer to "source", a 0 constant to "dest", and a 4
constant to "len". The right terminal of "dest" will contain the value
of the supposed pointer if the DLL hasn't been swapped, trashed,
unloaded or whatever in the meantime.

Rolf Kalbermatter

[galtech]

First thanks for your respond.
Second, I am ok with you. This DLL is badly made but I do not have unfortunately access to it!

Best regards,

Yves

[shoneill]

Rolfk,

Always ready with a good reply. This approach was unknown to me. Is this available in labVIEW 6.1 or is it a new thing with LAbVIEW 7.1?

Up until now I've always assumed that LV can't do anything with a U32 pointer, even if the address is valid.

Now I know different.

Thanks

Shane.

[rolfk]

shoneill wrote:
> Rolfk,<br><br>Always ready with a good reply. This approach was unknown
> to me. Is this available in labVIEW 6.1 or is it a new thing with LAbVIEW 7.1?

The fact that you can call LabVIEW manager functions (External Code
Reference manual) with a call library node which has "LabVIEW" as the
library name does work at least since 6.0 but if I remember correctly
also in 5.x. Yes I just looked in my notes. There is one difficulty
however when using BridgeVIEW 2.x (the predecossor of what is now
LabVIEW DSC) which is really just LabVIEW 5.x as far as the executable
is concerned. The same VIs need to use the string "BridgeVIEW" there to
work, so VIs using that feature were not portable between LabVIEW and
BridgeVIEW.

The manager functions itself have been available since CINs do exist but
above mentioned ability was only added later on when LabVIEW started to
export all those functions by name just as a DLL does. Windows
executables and DLLs are really very similar both in binary layout and
also how they are handled. The only real difference is the startup
function which gets invoked by the OS on loading the binary image file.
The fact that most executables do not export functions the same way as
DLLs do is not that it can't be done, it is simply very seldom used.

Rolf Kalbermatter

[Amaunette]

I am having almost exactly the same problem, and the solution posted here hasn't worked for me.

I am using an exteral dll written in C to interface with a pulser/receiver through LABVIEW 8.2.  The function I am using now is formatted like this:

aisNP3FreqModeFilter(int freq, int mode, int filter, int *IOfilter)

The purpose of the int pointer "IOfilter" is to check the filter settings (since not all filter settings are compatible with all frequency settings).  So I need to read the pointer returned from IOfilter, which should correspond to the value of "filter".  I have configured a call library function node in the following way:

return value
Parameters:
1. freq (int 32 value)
2. mode (int 32 value)
3. filter (int 32 value)
4. IOfilter (int 32 pointer to value)

I wired in the appropriate values to the first three parameters.  The fourth parameter, since I didn't know what to do, I wired in a numeric (int32) constant.  Then I wired a numeric indicator from the right side of IOfilter in the call library node.  But no matter what values I put in for the input to IOfilter, I get that same value back.  Like I said, the purpose of IOfilter is to check the filter settings, so I am expecting to get the value of filter returned to me instead of the string constant wired into IOfilter, which is what I'm getting.

I  have also tried the MoveBlock technique described in rolfk's post.  LABVIEW crashed on the call to the MoveBlock function. 

Are there any other suggestions on how to read an int32 pointer after dll call?

Thanks!