panel resize event bug?

[Intaris]

I'm having a bit of hassle with a panel resize event.

For reasons best known to me, I have some parallel loops monitoring certain UI behaviour and reacting appropriately.

I have noticved that when a loop which is monitoring the "Panel Resize" event stops, (No dynamic registration) the next panel resize will freeze the VI.  It's as if the Event case is not releasing the handle to the "Panel resize" event.

If I handle the "Panel Resize" event via a dynamic registration and subsequent release, everything works fine.

This is in LV 8.2.1.

Shane.

[Intaris]

Just tested LV 8.5.1 and the problem seems to be there too.....

Shane.

[Intaris]

Oops, just realised I linked to the wrong event in the "Doesn't freeze" Example.  This causes it to freeze too.  Sorry.

Here's a version which really doesn't freeze (In 8.2.1 and 8.5.1)

Shane.

[tst]

I think this has to do with LabVIEW locking the FP (as configured) even when the event structure should not execute any more. I actually created a simple example of it recently, but saved it in one my projects instead of where I would see it, so I forgot about it. I now dug it up and back saved it to 8.0. You can also simplify this example by removing the value change event and making the key down event lock the UI.

Message Edited by tst on 11-10-2008 02:14 PM

[Intaris]

Yeah, looks like a FP locking issue, but surely a terminated Event structure should not block the UI if an event it is no longer monitoring occurs....

I'm reporting this as a bug, unless someone can tell me it's fixed in 8.6.

Shane.

[tst]

---

Intaris wrote:

unless someone can tell me it's fixed in 8.6.

---

It's not.

Please try to have the bug description relatively generic, so my example will get in as well.

[TCPlomp]

---

tst wrote:
I think this has to do with LabVIEW locking the FP (as configured) even when the event structure should not execute any more. I actually created a simple example of it recently, but saved it in one my projects instead of where I would see it, so I forgot about it. I now dug it up and back saved it to 8.0. You can also simplify this example by removing the value change event and making the key down event lock the UI.

Message Edited by tst on 11-10-2008 02:14 PM

---

Sorry Yair,

but this is not a bug!, it is explainable behaviour and expected behaviour.

What happens, the front panel is locked on the second edit. (use exectuion high-lighting) The event structure is always listening for events where it is registered for, even if the event case will never execute, on the first edit (key down) the event is triggered and the VI is locked and unlocked. The second edit the event is triggered again and the FP is locked. Because the event structure can't execute the FP stays locked.

Shane's behaviour is truly a bug.

The same behaviour is seen with the 'Pane:size' event. (in 8.6)

Ton

[Intaris]

I personally  don't see the real difference between Tst's version and mine except that different Events are being used.

In both cases Event structures are no longer active yet Events triggered which they were listening for IN THE PAST cause a lock-up.  Surely a finished Event handler should "un-register" itself.  I can,however, see problems with Events which occur in the meantime not being "caught" if the Event structure automatically un-registers and re-registers itself all the time.  End result would be lost events.

Perhaps the best course of action would be a terminal on the right-hand side of the event case to manually "Unregister" the standard Event, just as one does with user events (Could look like a stop terminal in a loop perhaps).

Whatever way is best to deal with this problem, I think the current behaviour is a bug.  An event structure is ALWAYS registered at the moment.  It can be worked around by keeping all Event structures running until the end.  Another workaround is just to stick exclusively with user events for such cases.  These can be manually unregistered and hey presto, the problem goes away.

Shane.

Message Edited by Intaris on 11-10-2008 10:24 AM

[TCPlomp]

---

Intaris wrote:

I personally  don't see the real difference between Tst's version and mine except that different Events are being used.

---

Your event structure locks the FP even if 'Lock FP' is unchecked Tst's doesn't do that.

An event structure is always active, this is by design and mentioned in the 'Caveats for event structures', Tst's code is explicitly mentioned in the help.

Your code looks similar, but I cannot see why a FP resize would lock a FP.

Ton

[tst]

I agree with Shane that there is no difference between the examples (in Shane's example, the mouse down event locks the UI, so you don't actually need the resize event to show this). However, I think I also agree with Ton that this is probably not a bug.

Shane put it nicely:

---

I can,however, see problems with Events which occur in the meantime not being "caught" if the Event structure automatically un-registers and re-registers itself all the time.

---

Because I'm so used to using the ES in a loop, I forgot that it's essentially a one-time deal. You HAVE to run it over and over and it always ends, which is why it's always listening for events, even when it's not actually running. The reason I thought mine was a bug was that I didn't notice that my example had Update Value While Typing checked. This does cause the Value Change event to be fired, so I do understand why the VI gets stuck. It even makes sense that the UI is locked as soon as the event occurs, even if the code didn't start to handle it, because otherwise you can make other changes.

P.S. As I mentioned, this was an example I did quickly a while back while coding and I meant to go back to it and look at it more closely. I then forgot about it, so I didn't. Had I done that, I would probably have figured out the problem.

Message Edited by tst on 11-10-2008 07:18 PM