"Key Down" event use in one page of tab control prevents using "Value Change" events on another page, even though separate case structure blocks handle the two

[cebailey]

The attached VI has a tabbed control with two pages. On one page, titled "Using Value Change Events", there is a control and an indicator, and the underlying code processes a Value Change event on that control by adding one to the number and displaying it on the indicator. On the other page, titled "Using Key Down Events", there is an indicator, and the underlying code processes a Key Down event by displaying the scancode on the indicator. Both these underlying code blocks are in different cases of a case structure chosen by the tab control. Some extra items are necessary to be able to stop those blocks from cycling if the tab is switched or the End VI button pressed.

Or, at least, that's what I wanted.

What actually happens agrees with the above, if the Increment/Decrement is used to change the value in the control on the Value Change page. But everything stops responding if I type in the control to change the number.

I think the problem involves the Key Down event structure, which is in what should be an inactive case of the case structure when this problem occurs. If I put a Disable structure around that Key Down event structure, the Value Change page items all work fine. Of course, the Key Down page items don't do anything with the Disable in place.

Why does having a Key Down event handler in an inactive case structure make a difference? How can I use both event types on different pages of a tabbed control?

Thanks!!

[Dennis_Knutson]

Placing an event structure inside a case statement does NOT disable that event structure. Each event structure is always active and capturing events. Right click on the event structure and select Help and then click on the 'caveats and recomendations for using events' link.

[TCPlomp]

If you want to disable an event structure you should use 'Dynamic Event Registration'

Ton

[altenbach]

You need to learns the magic of dataflow and simplify your code. It is extremely convoluted.

All you need is a single while loop and a single event structure with all the cases you need (including stop). The case structure is completely useless because the code does not need to change based on tab state.  The value change event can only happen on one tab state anyway. You can check it a the "key down" filter event and ignore it if the tab control is on the wrong tab.

Also none of your local variables are needed, just connect the controls and indicators directly to the wires. (You are still stuck in a text programming mode).

[altenbach]

Here's a quick modification how you could do it quite a bit more streamlined!

(no locals, one event strucuture, one loop, one simple case structure, no timeout case, understandable code).

See if it makes sense. Modify as needed. 🙂

[cebailey]

Thanks, everybody.

Especially, altenbach, I see how much cleaner your vi is. It didn't occur to me my event handlers could be making the choices my case structure was. My example is a proxy for a more complicated real-life situation, not surprisingly. The rules for exiting activities in my tab control cases are different for the different cases and depend on other variables. I'm rethinking the basic logic of it all. Maybe I can do it all with just event handlers, or maybe do the logic of the user interface with event handlers and do the big work of the system elsewhere, someplace consuming the choices produced by the user interface.

The change from text programming has been slow. While loops and for loops elsewhere are checking and sometimes changing values for what seem like given physical experimental reasons. It seems like this keeps forcing values to involve variables and not just dataflow, but then everything keeps looking more and more like variable-based thinking. Does this mean this particular situation really needs variables, or that I'm getting stuck in non-dataflow thinking? It's not that easy to tell yet.

Also, thanks all for the correction about how events work. There is certainly a way to fix what I originally identified as the problem, IF it still looks like that's the wisest thing to be doing.

This is a lot to think about.