I get error 998 when calling a LabVIEW buildt DLL from MSVC++

[waldemar.hersacher]

I created a DLL in LV 6.0.2. This DLL contains 39 VIs and controls. 13 of the VIs are exported, the others are subVIs, which one of them is a dynamic VI.
I do not have all connectors used by defining the VI prototype in the build file for the application builder.
Using this DLL I get four effects:
From LV 6.0.2 FDS all works fine until I quit LV immediatly after the application VI stoppes. Then LV wants to save some of the VIs of the DLL.
If I do the same but close the VI before I quit LV one want save anything.
After Building an exe from the application VI and running the exe all works fine. The VI will only stop and if I close or quit noone wants to save something.
Then I built an application with M
SVC++ 6.0 using this DLL. There will be no errors or warnings during the build. If I start the application i get an error message dialog with the number 998 stating "system error loading LV Runtime engine. My application needs a Version 6.0 or compatible Runtime-engine". The path to teh Runtime-engine is given in the dialog and the lvrt.dll there has version 6.0.2.

Does someone run on such a problem?
Has someone a solution to this?

[Randy_H]

Waldemar,

I. LabVIEW wanting to save VIs
The DLL created is just a group of VIs, not actually compiled DLL code. When the subVIs are called, they might be cached from the disk copy, not the one in the DLL. LabVIEW then loads the separate copy of that subVI. It will then ask if you want to save changes because there were value changes when it was run (this makes since) or it is in LabVIEW 6.0 version and has not been mass compiled for LabVIEW 6.0.2. When it is compiled to an exe, the search path for the subVIs goes through the executable and not the LabVIEW development environment. Also, saving VIs is not an option in an executable so the save dialog does not pop up.

II. MSVC++ error
This is actually a Microsoft issue. It has something to do with static and
dynamic linking of the MFC DLL. Our R&D engineers have verified this with projects created with no LabVIEW code at all (that is why we believe it to be solely a Microsoft issue). There are three options at this time:
1. Link with the DLL form of MFC.
2. Do not link with the .lib from the LV DLL, instead use LoadLibrary and GetProcAddress to dynamically load the DLL and call the function.
3. Use the VC delayload feature to make the LV DLL not get loaded until the first call is made into it. See VC help on "delayload" for information on setting this up.

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

[waldemar.hersacher]

LabVIEW wanting to save VIs:

The problem is really about the location of the VIs. The DLL and my example are using the queue VIs. Loading the example would cause LabVIEW to load "Create Queue" from the development environment. Calling the function "ETLKWPOpenCommunication" would also load "Create Queue" but the path points to the DLL. So LabVIEW will try to save the VI back into the DLL which it can't.

Btw a real LabVIEW programmer would not use the DLL. There is a LabVIEW library available with the same functionality. The example is only for demonstration that it is possible to do it.

[waldemar.hersacher]

MSVC++ error

I already had the shared DLL of MFC in the project.
I use the delayload feature and the system error 998 disapeared.
Now I have a new and old error, which have been discussed in this forum with no final solution. The problem is I get the message box with the error "LabVIEW.lib was not called by a LabVIEW process". Since I know from a track initiated by Gabriela Tillmann that I have to do alot when using cluster/array parameters, the interface of all VIs which will be exported use only basic data types like numbers and strings. Knowing the example from devzone is running I removed all calls to subVIs. Also I created a console application but the error remains. The last thing I removed was the "runVI" method of a dynamically loaded V
I. After this remove I get no error messages but the VI is doing nothing.
Is there any document from which I can see what does not work in a DLL when this DLL is called by something else but LabVIEW?