'Select File Path' popup will block 'Open file' vi

[alex.]

When 'Select File Path' popup by click the 'Browser' button, the 'Open file' vi will be blocked.

I found it when I trying to select a file by 'Select Path' popup, all the system log stop recording.

Is it true?

Any suggestion? (Will it help if set the vi for system log for re-entry). I need the log keep on going even when somebody click and popup the file path browser.

Thanks. 

[Norbert_B]

Turbot,

i am not sure that i understand your issue correctly. I asume that you are using something like Open File without connecting a file path name no to it. This function will create a dialog in this case and will stop the execution of the LV program in the mean time.

This is normal behaviour since LV cannot know what the file's name will be unless the user selects a file. So this dialog HAS to block the execution until either confirmed or canceled.

If you don't like that behaviour, you have to either

a) split logging from the rest of the program

b) wire a predefined file name to the Open File.

hope this helps,

Norbert 

[Andrey_Dmitriev]

Hi, Norbert,

I guess, Turbot mentioned following:

Looks like block with UI thread. VI (LV 8.6) in attachment.

Andrey.

Message Edited by Andrey Dmitriev on 11-19-2008 03:08 PM

[alex.]

Yes，the vi popup the 'File path select' and the system log vi are 2 different vi. Almost no relation between them.

[Wiebe@CARYA]

I can reproduce this in 8.5.

It is definitely a bug... I would be suppressed if this is an unknown bug,
since it is a severe bug.

Regards,

Wiebe.

[Andrey_Dmitriev]

Hi, Wiebe,

Not sure that this is the bug, probably somewhere this behaviour documented 😉

Anyway, there are other posibilities to block cycles when Dialogs or MessageBox called.

Look at screenshot below (sorry, pretty big): there are 6 different cycles, which are blocked by different actions:

Refer to doc Multitasking in LabVIEW

But I agree, some of such "blocks" can be positioned as bugs.

regards,

Andrey.

Attached examples for LV 8.6 and 8.5

Message Edited by Andrey Dmitriev on 11-20-2008 04:03 PM

[F._Schubert]

Great collection Andrey!

I ran into that issue once and did not find the time yet to dig deeper, it was either a queue or a TCP connection (or maybe it was just the status logging of the TCP connection) that was blocked by the file dialog. I will certainly have this post in mind when I will continue to work on that code.

Felix 

[Wiebe@CARYA]

Nice collection, indeed.

I think you should add the file browse button of a path control. This is
much weirder then the file dialog called from code. The loop where the
control is read isn't blocked, but at complete distinct parts of the code
are blocked! I have lot's of applications where I have a dynamic VI logging
data. So in all these apps I have to disable all the path controls, or at
least their browse buttons!

To prevent this, we have to call User32.dll functions for messagebox's and
fileopen dialogs? Of course with the dll's set to "reentrant" execution.
Seems like something NI should fix. And by "fix" I don't mean "document
it"...

Regards,

Wiebe.

[Andrey_Dmitriev]

Thanks. The best way to prevent such "deadlocks" is avoid to use property nodes, DLLs in UI thread, etc (in general all elemenths which caused switch execution thread to UI) in any time-critical loops. For example - there are two loops - they almost the same, but one is faster, and another is slow:

I mean that sometimes we can easily recognize deadlocks: MessageBox called, then cycle stopped completely. But sometimes as in example above you can't recognize some small dynamical deadlocks easily. Just don't use "blocked" elemenths.

Andrey.

Message Edited by Andrey Dmitriev on 11-20-2008 07:14 PM

[alex.]

Thanks for all. Actually I just want to make all the log keep on recording when file browse button of a path control is clicked.

May I know what is the best way to do it. And how to implement with the user dll.

Thanks a lot.