Open VI Reference blocks event loop

[instrumento]

Run the attached VI.  If you have the WORKS/DOESN'T WORK toggle in the WORKS position and hold down the HOLD ME button with the mouse, the ticking clock keeps on ticking.  If you let go of the mouse and toggle to the DOESN'T WORK positions then hold down the HOLD ME buttong with the mouse, the ticking clock stops ticking.  The problem seems to be that the Open VI Reference call either doesn't execute, hangs, or blocks for one reason or another.  The state of the event structure "Lock the front panel ..." is irrelevant, i.e. doesn't seem to affect behavior.

Is this a known limitation of Labview?  Is there a workaround to enable a call to Open VI Reference when the mouse is down?

[Dynamik]

Hi instrumento,

      Have you solved this?  If not, perhaps you'll post the VI?

Cheers.

[instrumento]

I did try to attach the vi.  I'll do it again, in zip form, using IE and WinXP (last time I tried to attach the VI from Linux using Firefox).

[instrumento]

Looks like the attachment made this time.  I don't think it was a matter of OS and/or browser (and by the way, I'm trying to run the VI under Windows not Linux) but the way the Preview Post button works.  If I attach a file, and it is listed under attachment, and then press Preview Post, the attachment seems to disappear ...

[altenbach]

(Yes, previewing clears the attachment box, so attach the files as a last step before posing.)

Anyway, I can confim that your VI does not work as expected. It seems the "open VI reference" does not complete until there is front panel activity. I would think it's a bug.

(Of course the VI in it's current form does not make much sense except for demonstrating the problem ;))

[instrumento]

>(Yes, previewing clears the attachment box, so attach the files as a last step before posing.)

Seems like another bug to me 🙂

>Anyway, I can confim that your VI does not work as expected. It seems the "open VI reference" does not complete until there is front panel activity. I would think it's a bug.

That's what I thought, but I need a workaround, or fix.

>(Of course the VI in it's current form does not make much sense except for demonstrating the problem )

Obviously.  In the real example the call to VI Open Reference is several VIs down the hierarchy.  The code is part of the GUI where the operator is supposed to adjust something moving it up (or down) until the button is released.  What is being adjusted can change, without having to change the GUI, through selecting different  inputs to VI Open , which won't work.

[TiTou]

Hmmmm... interesting !

Here is my attempt to explain this :
A "value change" event is when a value has changed, I mean has finished to change ; if you're still holding the button, its value hasn't finished to change yet and can not change if the mouse up happens when the pointer is outside the button, no ?

If you change the even to a "mouse down?" event (the one in red) it works....

[instrumento]

> A "value change" event is when a value has changed, I mean has finished to change ; if you're still holding the button, its value hasn't finished to change yet and can not change if the mouse up happens when the pointer is outside the button, no ?

Well, not really.  Value change shoule be when the event is called, by definition, i.e. the event structure should only be called,  process an event, if that event did happen.  I didn't ask for "value is half way changing", I asked for "value change".  In my original example the value has changed, as shown by the status field and boolean display.  Also, when the case structure with the VI Open Reference is disabled by the toggle the event structure finishes and goes on to the next event, the timeout, getting the clock to keep ticking.

> If you change the even to a "mouse down?" event (the one in red) it works....

It should, but  if the mouse moves out of the button and then it is released, one never gets a mouse up, which is needed to stop the action.  (Well, there may be ways to globally track mouse up and know that we last had a mouse down on that button, but now we're talking very cumbersome and error prone.)

[JeanPierre]

This is a known issue, Open VI Reference run in the UI thread so it doesn't execute when the thread is busy like when a menu is pulled, a modal window is opened or as it seems here, an event is processed. The workaround is to open the VI ref outside the event structure using for example a state machine.

[instrumento]

> The workaround is to open the VI ref outside the event structure using for example a state machine.

That's not much of a workaround and won't be very practical or even feasible in our case.  The GUI in question doesn't really know what is calling until run time and the Open VI reference is called several levels deep in code that doesn't have much to do with the GUI itself.  (It is trying to open a compare method vi passed to a sorting algorithm that can take different compare functions and which compare function to use may not be known until it is time to open it...)