National Instruments 320685D-01 ユーザーズマニュアル
Chapter 2
Using Loadable Compiled Modules
©
National Instruments Corporation
2-7
LabWindows/CVI Programmer Reference Manual
Windows 95/NT unloads DLLs at process termination is not well-defined. Therefore, the
DLL you call into might no longer be loaded. This can cause a general protection fault.
DLL you call into might no longer be loaded. This can cause a general protection fault.
Nevertheless, when you use your DLL in a program in the LabWindows/CVI
development environment, it is often necessary to call into DLLs to release resources
after each run. To solve this dilemma, use conditional code to release resources only if
you are running in the LabWindows/CVI development environment. An example
follows.
development environment, it is often necessary to call into DLLs to release resources
after each run. To solve this dilemma, use conditional code to release resources only if
you are running in the LabWindows/CVI development environment. An example
follows.
#include <utility.h>
switch (runState)
{
case kRunState_Stop:
if (! InStandaloneExecutable())
{ /* call into other DLLs to release resources */ }
/* release resources, including unloading DLLs */
break;
}
It is always safe to call into the LabWindows/CVI Run-time Engine in a run state change
callback.
callback.
•
If your DLL uses global variables that can become stale after each program execution in
the LabWindows/CVI development environment, re-initialize the variables in response
to the
the LabWindows/CVI development environment, re-initialize the variables in response
to the
kRunState_Start
or
kRunState_Stop
message. For example, memory that
you allocate using LabWindows/CVI ANSI C functions such as
malloc
or
calloc
is no
longer valid when you restart your program. If your DLL has global variables that point
to allocated memory, set those pointers to
to allocated memory, set those pointers to
NULL
in response to the
kRunState_Start
or
kRunState_Stop
message.
Compiled Modules that Contain Asynchronous Callbacks
A compiled module can call a source code function asynchronously. This can happen through
interrupts or signals. In Windows 95/NT, the compiled module can call the source code
function from a thread other than the main thread. The call takes place asynchronously with
respect to the normal execution of the source code in your program.
interrupts or signals. In Windows 95/NT, the compiled module can call the source code
function from a thread other than the main thread. The call takes place asynchronously with
respect to the normal execution of the source code in your program.
The execution and debugging system in the LabWindows/CVI development environment is
not prepared to handle this asynchronous execution. Consequently, the compiled module must
announce to LabWindows/CVI that it is calling asynchronously into source code. It does this
by calling
not prepared to handle this asynchronous execution. Consequently, the compiled module must
announce to LabWindows/CVI that it is calling asynchronously into source code. It does this
by calling
EnterAsyncCallback
before calling the function, and calling
ExitAsyncCallback
after calling the function.
EnterAsyncCallback
and
ExitAsyncCallback
have one parameter, which is a pointer to a buffer of size
ASYNC_CALLBACK_ENV_SIZE
. You must pass the same buffer into
ExitAsyncCallback
that you passed into
EnterAsyncCallback
because the buffer stores state information. The
definition of
ASYNC_CALLBACK_ENV_SIZE
and the prototypes for these two functions are
in
libsupp.h.
00ProRef.book : 06chap02.fm Page 7 Monday, March 9, 1998 3:23 PM