LabVIEW
strange labview hang
@PointOnePa wrote:
Have you gained any additional insight/understanding of this issue since your last post in July 2010?
I'm fighting a similar problem, and I'm wonder if the ActiveX Server DLL that I'm using is attempting to pop-up a dialog box that is deadlocking with the Labview GUI. Repainting of the Labview application window unlocks the application and lets it proceed from the point of hanging.
Other related post from 2006:
It's an old post but ActiveX multithreading is a topic, that nobody on this planet really understands fully due to its terrible internal structure that builds in fact on OLE thechnology. And OLE has still some reminenscents from Windows 3.x times. Basiscally it is not fully cleanl multitasking, but some sort of combination of cooperative and concurrent multitasking, due to compatibility hacks for the old Windows OLE architecture, that was build on the Windows 3.1 cooperative multitasking architecture. Most Active X controls depend almost entirely on the windows message queue to work properly and not get hang somehow, yet when LabVIEW calls such components it has to suspend most activities in order to not potentially crash the Active X interface which can be a problem if the ActiveX control assumes that it has total control over the system for the entire duration of the call. More modern LabVIEW versions try to detect if an ActiveX component or external DLL try to open a modal windows and resume in such a case the processing of the system messages anyhow to prevent such a deadlock, but if the component doesn't open a modal window but for instance a floating window, LabVIEW can't really do much about it.
For the problem of the OP: Hiding the non-modal window probably circumvents that problem, since Windows detects that early on during creation of the window and shortcircuits most of the event processing of that window, so that the blocked message queue doesn't block the CreateWindow() API call, and the DLL function can continue back to LabVIEW.
@instrumento wrote:
Since we moved the window off screen that we haven't had this problem. We call Matlab through a Matlab generated DLL, which may or not use ActiveX (probably not).
It doesn't matter much if there is Active X involved or not in an external DLL. As I described, similar issues happen if an application creates any (visible) window in the external code. For modal windows recent LabVIEW versions have a workaround implemented but for non modal windows this is not really feasable. Active X is causing basically the same issue, only that the internal Active X architecture is even more complex and the mere fact there is an ActiveX component in the external code usually is a problem already without the need to open a (visible) window.
