Dynamic Events - multiple controls of the same type

[James_W]

OK, so I'm trying to tweak my UI.
It's a simple dialog, it's got a few boolean controls on it and it's based on the Formula express VI.
I want to test it externally with some tests that invoke button pushes - and I'd like a technique which is scalable across all of my UIs in the project.

Currently I have grouped the boolean controls into 4 groups:
OK & Cancel
FP actions (home, end, backspace, delete)
standard operations
custom project variables...

Testing externally I can't close the VI as OK & Cancel are latch booleans. (and I'd like to be able to act on any latch boolean anyway)
I want to fire a value signalling / event to the buttons, maybe put the even registration in a subVI so it is testable.

unfortunately, from what I can see at the moment, instead of having 4 event cases, I now need a seperate dynamic case for each control as I can't see how to get the control/event name that fired the event from the event structure if I build an array or cluster of boolean events.

Any pointers as to how to make the events more testable from a scripted test that mimics a button push please?

James

[wiebe@CARYA · Accepted solution]

---

@James_W wrote:

unfortunately, from what I can see at the moment, instead of having 4 event cases, I now need a seperate dynamic case for each control as I can't see how to get the control/event name that fired the event from the event structure if I build an array or cluster of boolean events.

---

You don't need separate cases, you can add all individual cluster controls to 1 even case.

You have quite a bit of options. Here are some ideas:

EDIT: search for a True in that last example.

[wiebe@CARYA]

---

@James_W wrote:

Any pointers as to how to make the events more testable from a scripted test that mimics a button push please?

---

You can simulate the push of a latch button, but you need to use Windows APIs. Also, you need a coordinate to simulate the button press. This can be hard if your application uses (nested) subpanels and\or (nested) reentrant VIs.

[James_W]

Thanks weibe,

I've given up with the latching action and gone for a switching action with locals to reset the OK and Cancel states because it's such a PITA to use the windows functions.
found I can fire Value signaling now to all my Booleans and scan the FP for the boolean by name to control in my tester function - so I'll just steer clear of switching actions for the sake of testability. 

Cheers

James

[Kevin_Price]

As another variation on ways to approach this:

We use a modified QMH scheme quite a bit.  There's generally one top-level "main brain" that coordinates a number of subservient QMH loops.  For the sake of unit testing the subservient loops, we'll often give them a simple GUI and an event-handling loop in parallel to the main QMH.  (The whole thing is typically in a conditional disable structure so it will be excluded in any executable build.)

All the working code belongs in message cases of the QMH loop.  The event loop merely catches GUI events and dispatches the corresponding message to the QMH loop.  This lets us easily do interactive unit testing for the various messages.

It's a little extra work upfront but it scales rather nicely. 

-Kevin P

[wiebe@CARYA]

---

@Kevin_Price wrote:

As another variation on ways to approach this:

We use a modified QMH scheme quite a bit.  There's generally one top-level "main brain" that coordinates a number of subservient QMH loops.  For the sake of unit testing the subservient loops, we'll often give them a simple GUI and an event-handling loop in parallel to the main QMH.  (The whole thing is typically in a conditional disable structure so it will be excluded in any executable build.)

All the working code belongs in message cases of the QMH loop.  The event loop merely catches GUI events and dispatches the corresponding message to the QMH loop.  This lets us easily do interactive unit testing for the various messages.

It's a little extra work upfront but it scales rather nicely. 

-Kevin P

---

I typed something similar about separating GUI and logic a few times and deleted it (the same number of times)..

It is a common and valuable technique to make testable code. Good practice in general to keep things clean and decoupled.

If you really want to automate the entire application, you still need to simulate (stimulate?) the GUI though.

[billko]

---

@James_W wrote:

Thanks weibe,

I've given up with the latching action and gone for a switching action with locals to reset the OK and Cancel states because it's such a PITA to use the windows functions.
found I can fire Value signaling now to all my Booleans and scan the FP for the boolean by name to control in my tester function - so I'll just steer clear of switching actions for the sake of testability. 

Cheers

James

---

This is pretty much the only way if you put your GUI in a subVI.  Well, not exactly like this, but you would pull in the reference to the control and set the value to FALSE with a property node because you won't have access to the local variable inside the subVI.