Variables and Building DLL

[RobBoyer]

"So looks that the function will not call everytime this file function inside the DLL only if you do it once in LabVIEW with the same function. So LabVIEW and DLL share the same area, but DLL cannot handle its own area only helped by LabVIEW."

I have no idea what you are trying to say here.  I think the piece of the puzzle that you are missing is that your DLL has its own copy of the global variables that you have built into it.  This is by design.  And when the DLL returns, you should fully expect its copy of the global variables to die with it.  If you expect global data to persist between function calls, it should not be built into the DLL - it should be threaded through each DLL call and managed in the calling code.  This could be done a number of ways. 

1) Each DLL needing the global data could expect the global data as input, and each DLL writing the global data could output the new values.  In this case, your global variables would only be directly referenced from the code that calls the DLLs.

2) The DLL could be implemented as an object-oriented class.  (As I understand, LabVIEW now supports this.)  Then, your constructor would initialize the global data, and all the function calls you make could be called against that same object.  Since the object would persist for the lifetime of the calling code, the global data would do so as well.

I'm sure there are other solutions, but I'm not that familiar with building DLLs in LabVIEW.

I hope this helps.

[teodor_blaga]

I think I found something that might be interesting.

In my code I use Internet Tool Kit foe XML parsing. So, when I compile my DLL, this ToolKit cretes a dependency called  DOMUserDefRef.dll. I think this is the root of the problems. So I think this is why I have this behaviour. When you open a new LabVIEW session and run one VI which contains this XML component is somehow that it will be registered somewhere and it will disappear when you close the LabVIEW session. In this time, everything that runs including also DLLs will work fine. But if you skip that first step that I mention it seems that the DOMUserDefRef.dll cannot be found and it will skip the execution of the called function DLL.

So then there is a new question. Why my DLL cannot see that DOMUserDefRef.dll? Do you know a setup fot this in builder? I tried only one tricky staf (which is not working) to put it in the same directory with the created DLL (even if the builder puts this in a data directory).

Teodor

[kaêm]

Few facts about DLLs.

1. DLLs are loaded into OS memory only once. Each process that loads them will share the code, but will have their own set of private variables, even global variables.

2. Global variables inside a DLL are like global variables in a normal program. They don't lose their values between function calls and you surely don't need to 'refresh' them. Global variables inside a DLL are not shown to outside of the DLL unless they are exported.

3. A process that has loaded the DLL will lose its data memory (variables), when the process releases the DLL. This doesn't mean that the DLL is released from OS memory, the process just doesn't hava a handle to it anymore. The OS removes the DLL from memory when no process has a handle to it.

4. While LabVIEW is running and two VIs load the same DLL, both these VIs can see the same global variables, because there is only one process, LabVIEW, accessing that DLL. These open VIs are just threads of that process and share the same memory space. But if these VIs are built into EXEs, and are runned without LabVIEW being open, they have their own set of data.

------------------------------

I understood that in this problematic case, there is only one DLL that has several VIs that are exported, and only one progam that loads the DLL. There should be no problem with the global variables in this scenario. The globals should retain their value between the function calls of one process.