How to use GetLastError to get DLL error details ?

[jdorne]

Hi.
I use Labview 6.1 under W2K pro.

I try to use a DLL to control a unit plugged in my COM1. This DLL use setLastError in kernel32.dll but when i use GetLastError i have 0 : no error. I thing that the thread that is taken by GetLastError is the run-time of Labview (that has no error) and not the thread of the DLL... not easy to explain in english...
If someone can help me .. ?? don't hesitate !!

Jerome

[mikeporter]

The problem with giving a detailed answer is that the exact way you have to interact with a DLL is very device-specific. Each DLL uses its own way of returning errors and even defining what an error is.

What is the specific device you are trying to talk to through the serial port?

Mike...

[JRA]

Are you sure that an error is occuring? If it says no error, then one has most likely not occured. If you think that different threads may be the root of this, you can change that in the VI Properties for your VI. Create a subVI which calls your DLL and then set that in a different thread from the UI thread.

[jdorne]

I have resolved my problem ; I guess...
The issue was that the calling thread of
Getlasterror was different from the calling thread of the DLL. I need to call getlasterror immediatly after having called the dll (a sub VI doesn't work out)

The device i want to talk to is a TBOX from Technotrade. It's a "programmable automat".

Bye
Jerome

[Greg_McKaskle2]

> I try to use a DLL to control a unit plugged in my COM1. This DLL use
> setLastError in kernel32.dll but when i use GetLastError i have 0 : no
> error. I thing that the thread that is taken by GetLastError is the
> run-time of Labview (that has no error) and not the thread of the
> DLL... not easy to explain in english...
> If someone can help me .. ?? don't hesitate !!
>

If possible, it would be better if the function returned the error for
you, as GetLastError is a poor way of doing this in any API.

In the default settings, it is a little difficult to control which
thread executes various subVIs or DLLs and in which order. You can
arrange it to be predictable, though.

I think you have two problems. First off, you want to make sure that
the same th
read calls the function that sets the error and GetLastError.
The utility for setting threads is in
vi.lib/utility/sysinfo/threadcfg.vi or something close to that. It will
indicate how many threads are setup for a given execution system and
priority. You could arrange for any of these to have only one thread
and then make sure the VI running the nodes runs in the execution system
with only a single thread. You could also just set the DLLs to run in
the UI thread.

The second problem is that after executing a node, LV can switch over to
run a different node, then switch back at a later date. During this
switch, another VI can call SetLastError, GetLastError or
ClearLastError, all of which affect the thread-global error state. So
you need to arrange for the nodes to run such that nothing separates
them. One way of doing this for certain is to make a wrapper DLL around
the calls such that the calls happen in a synchronous DLL, where LV
cannot do switching between t
asks. If you have already setup a VI to
run in a less used execution system, and nobody else uses the thread,
then you are good to go.

Greg McKaskle