Dialog box locks up redrawing ring control in separate loop.

[Teds]

I created some code that uses 'user32.dll' to display a Windows dialog box.  For some reason and under certain conditions,  this dialog box locks up the front panel of redrawing a ring control.  The ring control is updated using property nodes in a Separate loop.

I attached a small test VI to demonstrate.  If you select 'Use Control Refnum' and click on the Windows Dialog 'Enable' button, then the ring will not draw until the dialog box is acknowledged.   The same issue does not occur with LabVIEW dialog boxes, the other button.  Plus if you update the control directly I have no problems with the custom windows dialog box.

It is probably something do with the Call Library Node, running under the UI thread.  

Could anyone give me a good explanation?

Thanks,

PH

[vt92]

The windows dialog box may not play well with the event structure.  You might try incorporating the functionality of the lower loop into the upper loop using a timeout.  That way, all of the control behavior is captured in the event structure.

I couldn't replicate the issue on my machine.

[vt92]

Also, there is a performance hit for assigning the ring control value by property node.

[tst]

The DLL call is configured to run in the UI thread. Any call to the property node also executes in the UI thread. Because the UI thread is in the middle of calling the function, it has to wait unti that's over before it can execute the property.

You could configure the DLL call to run in any thread, but that requires the function to be thread-safe, and I don't know if that specific function is. You could try searching MSDN to see if the documents thread safety of the Windows API functions.

[crossrulz]

The Call Library Function is set to run in the UI Thread.  Therefore, no front panel updates can be performed while the function is running (ie, the dialog box is showing).

[Teds]

Thank you.  Yes, that appears to be the solution.  I could change the function to MessageBoxA to run with 'Any thread' and it seems to work ok.  I couldn't find much on the thread safety of the user32.dll function with respect to the MessageBoxA function so honestly i have no idea if changing it to Any Thread would cause any adverse affects.

I will have to give it some more thought on the solution.  What I like about the windows message box is that you can easily specify the # of buttons, icons, default buttons, etc..   I will look around to see if anyone has developed a VI that could mimic the windows dialog box without the user32 dll issues.

Thanks,

PH