Why are "Lock Panel" and "Limit Max Instances" in event structures mutually exclusive?

[richjoh]

Putting slow or fast code in the Event handler is a relative thing so to speak. Will it hang up your "code", maybe, maybe not. Adding property nodes to Event, is that too slow? What is too slow, its a relative question.

I suggest try your code with the "lock panel" checked and fire off events. Then try your code  with the "lock panel" UNchecked.

Open Event Inspector Window and see how or when and if your Events are handled in a timely manner.  There is no way to troubleshoot Events without using the Event Inspector Window. You may see you can generate Events that crash you VI by successive UI events. Then, possibly if the "lock panel" UNchecked, a crash doesn't happen. Some Events may even go unhandled and stuck in a Queue... endless possibities.

[billko]

---

@richjoh wrote:

Putting slow or fast code in the Event handler is a relative thing so to speak. Will it hang up your "code", maybe, maybe not. Adding property nodes to Event, is that too slow? What is too slow, its a relative question.

I suggest try your code with the "lock panel" checked and fire off events. Then try your code  with the "lock panel" UNchecked.

Open Event Inspector Window and see how or when and if your Events are handled in a timely manner.  There is no way to troubleshoot Events without using the Event Inspector Window. You may see you can generate Events that crash you VI by successive UI events. Then, possibly if the "lock panel" UNchecked, a crash doesn't happen. Some Events may even go unhandled and stuck in a Queue... endless possibities.

---

I've never opened the Event Inspector for anything other than for curiosity.  I never experience events getting piled up in the event queue, even when running some stuff with a lot of user and dynamic events.

I made a video game that has massive UI events going on, including updating a large picture control at 35 fps.  I don't drop any user events, nothing gets queued up, events triggered by a menu selection happen "instantly".

I think the rule of thumb is, if it takes more than a tenth of a second to execute, it doesn't belong in the event case.  But organizationally speaking, for anything of even moderate complexity, the event structure shouldn't be more than a traffic cop.

[JÞB]

A few clarifications 

Event inspector window.  The EIW  can show where lots of duplicate events enqueue unexpectedly. Silly developer errors, like selecting a value change event for a slide control, can be seen easily in the EIW. HINT: Use mouse up not value change for knobs, sliders etc.. and mouse leave for any control showing inc dec buttons.  But, the EIW really earns it keep in situations that enqueue events from more than 1 source! In that case sometimes events happen in unexpected ORDER possibly causing race conditions or deadlock.  Its a great debugging tool!

Is it OK to have an event case that takes some time to execute?  Well, yes, I suppose that it is BUT, RESPECT THE USER!  Simply locking the FP just doesn't do.  Options:

• Set unset Busy. Not ideal yet the User has been trained to expect that hourglass or spinning "curser" means its time for them to curse.
• Display messages.  Users will happily wait until the cows come home if there is a message like "Waiting for the cows to come home." Especially if there is a progress bar showing "x of n# of cows home"
• A Modal popup.  A filename prompt or a log-in shows the user that their input is valued and decisions must be made. Really any UI that you can think of would fit in this category and is so customary for things like Menu actions that we don't even think of doing anything else.

Great topic!

[gksloane]

Sorry, but why are "Lock Panel" and "Limit Max Instances" in event structures mutually exclusive?

Why can't I lock the panel, and limit the number of (perhaps ValSgnl'd) events that can queue??? You call it 'sneaking around' the UI; but we generate events that are NOT UI triggered; and some of those can also BE triggered by the UI (for instance in test mode to simulate a hardware event). So my (unanswered) question still stands...