How to catch events and pass that information

[doradorachan]

Hey guys,

I currently have a Queued Message Handler with an Event loop and a Message Handling Loop.

And sometimes it would run a sequence and it would run like the following, top to bottom.

state A

state B

state C

I originally had it so that at the end of state B, a dialogue window would pop up to ask the user "go to state C? or go back to state A?"

It works fine but there was customer feedback that basically said the dialogue was a bit annoying

because it blocks the view of the main UI. He just wanted an "instruction" indicator that would say

something like "press Enter to go to state C and Escape to go back to state A"

I was just thinking of ways to catch that user event within that same Main VI without using a view-blocking dialogue.

So far I came up with 2 ways to implement that change.

-Implement an invisible dialogue window that catches keyboard inputs. 

Implementation basically doesn't change from the original way, but now user can still see the UI in the main VI because the dialogue is invisible basically the same as the dialogue window. But when the dialogue is popped up user cannot interact with basic UI function of main VI like, scrolling through a graph.

-Catch events through the Event Structure loop and pass that information through a notifier

This seems like a better way but I was wondering if there way any down side to it.

Any thoughts? 

[Norbert_B]

Without seeing your code (and UI) we cannot really give good guidance. Nevertheless, i see two options:

a) Stick with a dialog VI which is displayed in front ("focus") but can be moved to background (non-modal). This has the issue that the user can "click it away without closing it". That could result in a "hang". But you can use keybinding on that dialog to have ENTER bound to "OK" and ESCAPE bound to "Cancel".

b) Do what you consider to catch these two keys in your event structure and enqueue appropriate elements in your QDMH worker. The only thing i wonder is how you want to guide the user properly through that "how to use"....

Norbert

[doradorachan]

It sounds like you got the idea but heres my code anyways.

Invisible Dialogue is just "Main original" with an invisible dialogue instead of the one that shows up 

[Norbert_B]

I hope this is functioning as you want it to do.

Nevertheless a couple of feedback points:

1. The notifier is a waste. Remove it. Simply use the case structure to enqueue the proper state for the consumer directly from the producer (State A with '1' and State C with '57').

2. Maybe you should change the Key Down notify event to a Key Down? filter event to discard the pressed key. Otherwise, it could have weird sideeffectes if the user has set the key focus to an editable control.

3. In order to prevent fals execution, you have to keep track if State A and State C are enqueued "properly" (read: only if State B is in execution). There are several ways to solve it. The one i recommend you is to keep a boolean in a shift register of the consumer, init it with FALSE. Once you execute State B, set it to true. Nest a case structure in State A and State C which queries that boolean. Once TRUE, execute the State's code, if FALSE, skip it. Set the boolean to FALSE in both State A and State C. Remember to assign TRUE to it in Start State, otherwise your first State A wont execute.

hope this helps,

Norbert

[doradorachan]

Thanks for your response

Here are my responses

1. I agree that notifier is an over kill, but it's a nice way to pass along information down to consumer loop.

But I think a case structure would complicate this further. Currently I have about 10 dialogue windows that I have to get rid of.

Most of them ask users to press Yes to keep going, or Cancel to stop the sequence and return to main menu.

Cancel is easy because it goes directly to the closing state. But keeping track of which state to go in the producer loop would cause a headache since this key entry would 

cause a state transition to many different states.

2. That makes total sense.

3. Not exactly sure what you are referring to and why the state varible for boolean is necessary.

[Norbert_B]

---

@doradorachan wrote:
[...]

Most of them ask users to press Yes to keep going, or Cancel to stop the sequence and return to main menu.

[...]

---

I recommended to get away from the notifier as you use it as a boolean switch. This does not scale.

I want to dig deeper for some advise:

State C is the final step of the sequence. This is also the case for your final application? Read: In case the user cancels, the last step in the sequence is to be called?

If so, there is a simple solution:

If Cancel is pressed at any time the sequence executes, you enqueue that last step of the sequence by the producer. The consumer feeds its sequence states by itself (as you already do for Start Sequence -> State A).

In case of the last step of the sequence, you flush the queue to get rid of possible invalid enqueued steps. Maybe you want to analyze the deleted elements for a "STOP" as this is something you want to re-enqueue.....

Norbert