Labview.lib was not called from a labview process

[lvEngineer2005]

We are implementing DSNewHandle() from labview.lib in our COM server. After calling the method successfully for a few times, we cannot make the call anymore. There is a message box telling us that it's a fatal error: Labview.lib was not called from a Labview process.

What should we do to resolve this problem?

Best regards,

[rolfk]

---

@lvEngineer2005 wrote:
We are implementing DSNewHandle() from labview.lib in our COM server. After calling the method successfully for a few times, we cannot make the call anymore. There is a message box telling us that it's a fatal error: Labview.lib was not called from a Labview process.

What should we do to resolve this problem?

Best regards,

---

labview.lib is the import library to link with external code you want to use with LabVIEW and which should be able to handle LabVIEW data types directly. The implementation of all those functions actually resides in labview.exe or lvrt.dll. The only way you can make use of this is if the code making use of this is invoked from within the labview.exe process or a LabVIEW executable running through lvrt.dll. So it is not a very good idea to try to make use of these functions in your own COM server.

Why would you want to use this function in some executable not running in the context of the LabVIEW system? It does nothing complicated you couldn't do with a malloc(), too.

Rolf Kalbermatter

[lvEngineer2005]

That is, we need to get a pointer of TD1Hdl(created by labview) out off one of our labview DLL directly. We follow a sample LV_string_array.zip which introduces us to DSNewHandle and Labview.lib.

Could you help me resolve this issue one way or another? We really need feature that works.

Best Regards,

[rolfk]

---

@lvEngineer2005 wrote:
That is, we need to get a pointer of TD1Hdl(created by labview) out off one of our labview DLL directly. We follow a sample LV_string_array.zip which introduces us to DSNewHandle and Labview.lib.

Could you help me resolve this issue one way or another? We really need feature that works.

Best Regards,

---

I'm not sure how to help. You give not any new information. Basically with COM servers you have two situations:

1) It is an out of process server. In that case your COM server is in the form of an EXE file and therefore is an independant process. COM takes care of marshalling the data for you (as far as COM compatible data is concerned), but you can not access LabVIEW manager functions since it is an independant process.

2) If it is an in process server, then it has the form of a DLL and is accessed by a process of your choice. Here you can only access LabVIEW manager functions, if the process instantiating the COM server object is a LabVIEW process.

So you can only use DSNewHandle in a COM server which is going to be used in LabVIEW only. No instantiation from a Visual Basic app for instance will be possible.

So you will have to provide a lot more information why you want to do this and what you want to do exactly to let us help you come up with a possible solution, if any.

Rolf Kalbermatter

[lvEngineer2005]

Rolf,

Quote:
2) If it is an in process server, then it has the form of a DLL and is accessed by a process of your choice. Here you can only access LabVIEW manager functions, if the process instantiating the COM server object is a LabVIEW process.

So you can only use DSNewHandle in a COM server which is going to be used in LabVIEW only. No instantiation from a Visual Basic app for instance will be possible.

So you will have to provide a lot more information why you want to do this and what you want to do exactly to let us help you come up with a possible solution, if any.

Here is my response:

Problem Found:

It is an in process server. I include the labview.lib into my ATL COM server project (created by ATL Project Wizard in VisualC++ 2003). In my server's method such as this:

STDMETHODIMP CClayArray::SystemInit2(void)
{
// TODO: Add your implementation code here
TD1Hdl LV_Str_Array;
//CreateLVArray(&LV_Str_Array) ;
LV_Str_Array = (TD1Hdl)DSNewHandle(sizeof(TD1));
return S_OK;
}

The build goes without any warning or error. (I was able to execute successfully this method on June 22nd, and early 23rd, but not the 23rd afternoon)

The fatal error message comes up ath the line: LV_Str_Array = (TD1Hdl)DSNewHandle(sizeof(TD1));

This message is exactly this: Labview.lib was not called from a LabVIEW process.


This error tells me that eventhough I can compile my code with labview.lib but cannot run it because of the labview.lib's runtime DDL is either corrupted or is a different version with the compiled library.

Solution Sought:

I would like to run the code without any error like before.

You can create a small ATL Project with a simple object and insert the code and run it to get some hints from it.

I hope this information is helpful to you.

Best Regards,

Khanh Nguyen

[SERDARSOYLU]

Hi;

I am having exactly the same problem as yours. I am wondering if you managed to solve this problem.If yes, could you possibly post it?

Kind Regards 

[rolfk]

You can NOT use labview.lib in an ATL project!

The process trying to call functions from labview.lib has to be started as a LabVIEW process! There is no other way. If your COM Automation server is an in process ActiveX DLL and always will be used inside a LabVIEW program or executable, then there is no problem, but if the ActiveX component is used by a different application you get that error. This is because labview.lib does not implement those functions but simply tries to link back to the LabVIEW kernel, which is not there if the calling process is not a LabVIEW process.

I'm really wondering why you think you need LabVIEW handles in a process that is not invoked as a LabVIEW process (development system or executable).

Message Edited by rolfk on 06-09-2010 04:36 PM

[SERDARSOYLU]

Hi Rolf;

In my TCP-IP server client application, I have a client vi that I converted into three Labview dlls; initialize, read and close. I am calling read.dll in a while loop in c++. The read dll is supposed to output an array (I attached a picture of it along with its header file created by Labview). According to header file, this dll outputs TD1 structure;

typedef struct {

int32_t dimSizes[2];

double Numeric[1];

} TD1;

typedef TD1 **TD1Hdl;

and on the c++ side, I am using the following line

TD1Hdl handle_var;

handle_var = (TD1**)DSNewHandle(sizeof(TD1)); 

but right at the line where I call DSNewHandle() function , I am getting the following error:

Labview.lib wan not called from a Labview process.

I created my project from scratch on my machine and I mass compiled  but the problem still persists. I am wondering if you have any idea what the problem could be?

Thank you so much! 

[rolfk]

Well that is not gonna work. The LabVIEW DLL is called inside its own LabVIEW runtime context since it does need a LabVIEW runtime kernel and your application is not a LabVIEW process and therefore does not have the necessary runtime kernel. Somehow the LabVIEW DLL contains code that detects if the DLL is called from a LabVIEW process that is the same version than the DLL was compiled in. If that is the case the DLL is loaded into that process and executed in process directly. If the LabVIEW versions do not match or the calling process is not a LabVIEW process, the DLL spawns a LabVIEW runtime process and loads the DLL into that context. It then sets up a marshalling stub similar to what ActiveX does for out of process automation servers and marshals all parameters between the calling process and the actual DLL runtime process.

So your non-LabVIEW process has absolutely no way of linking into the seperate out of process LabVIEW kernel in which the DLL executes. At least I do not know of any way, maybe there would be a way, but I doubt it and it certainly doesn't seem to be documented. Most likely if there would be, it would also very much depend on the actually used LabVIEW version in which you created the DLL.

Your only documented and sure to work solution is to not use LabVIEW native datatypes but standard C types instead.

Message Edited by rolfk on 06-09-2010 08:53 PM

[rolfk]

Another point, if the shown LabVIEW code is more or less all that is done in your DLL, you could quite easily avoid the whole hassle and simply use either Winsock or some other TCP/IP library functions from your C++ project directly. Flattened LabVIEW data isn't that complicated that it could not be unflattened programmatically in C/C++ either.

Message Edited by rolfk on 06-09-2010 08:59 PM