Leaderboard

New Version available: Version 1.7: [New Feature] Add a condensed pixel font that allow for longer text to be entered. [bug Fix] Synchronize the "Edit>>Show Terminal" menu with the "Show Terminal" check box. [bug Fix] CAR 186982: "[iE] Wrong Icon is loaded in Icon Editor". Get it here. PJM

If the DLL call and ActiveX call are both UI threaded (ActiveX as said is most likely, DLL depends on the Call Library node configuration but if it is a driver you haven't written yourself I would be vary to change a possible UI thread setting to re-entrant as that could cause all kinds of weird problems in the DLL if its functions aren't explicitly written to be re-entrant) you get most likely following scenario: Since the ActiveX call takes a certain amount of time, LabVIEW can't interrupt it midway to switch to the DLL call and let it take over the same UI thread. Once LabVIEW hands over control to an external code (ActiveX or DLL) it can only wait for that code to return code back to LabVIEW before doing anything else in that same thread. There is not a single way around it. I can give you a solution that will work. Create two LabVIEW executables, one calling into the ActiveX component and the other into the DLL, and let them communicate through Inter-application Communication together. That solves the problem since both components now reside in separate processes and will be simply multitasked by Windows itself. Changing the Call Library Nodes to run re-entrant might be a solution, but without knowing the underlying DLL code I would never make such a change myself. If it is not set re-entrant this has most likely a reason. It could be just an omission from the actual programmer but the chance that the DLL uses global variables and resources between functions without protecting them explicitly is very high and in that case changing the VIs to allow re-entrant calls could in the best case lead to crashes in the worst case to strange and almost impossible to debug effects. One other option is to change the Call Library Node to be re-entrant and assign all Driver VIs to a specific execution system. Now you go into vi.lib/utility/sysinfo.llb/thread config.vi and run it. In that VI set the execution system you have chosen to assign to all driver VIs to only have one thread. This will likely work fine but has the disadvantage that the thread configuration is not part of the VI but of the LabVIEW runtime setup. So you will have to make sure to add the according lines in labview.ini, that this change will create, into any executable ini file as well as any other LabVIEW development system ini file that you may use, such as other LabVIEW development versions you may use or other LabVIEW installations on any other machine that wants to make use of that library.

The Call Library Node has its own threading configuration that allows you to select that the DLL function is either called thread safe from the UI thread or in reentrant mode in whatever thread the calling VI is executing. If you have the UI Thread selected in the Call Library Node you can put the VI in whatever execution system you want but in order to call the function LabVIEW will switch to the UI thread first. I believe that most ActiveX nodes have to be called thread safe at all times, so they will execute in the UI thread anyhow (since most ActiveX components are specified to be apartement threaded, which is to say that an application should always call the Active X component from the same thread and the UI thread is the only thread in LabVIEW where this can be guaranteed without a very complex thread configuration system that nobody would understand.