Method to handle events within events

[Ben]

---

kphite wrote:

Maybe I should have mentioned that I have a table that shows the progress of testing. As each state (test) executes the user sees the appropriate display to tell them it's running. They also have an abort button that will fire to stop the inner and outer loop.

I've done quite a bit of easy labview programming but this is my first foray into the event driven world.

kph

---

Then is a good time to try and get this right (not only so you can learn and grown but also avoid frustration on your part).

If you have not done so already, work-up a state diagram that illustrates the states of your application.

Follow this up with notes on what prompts the transitions between states along with where these events come from and what pieces of code should know about them.

For the most part events that come from the user interaction could be detected by an Event struture and transfered via queues etc.

THese diagrams help me quite a bit while developing and when you imbed these images in your code, you and others in the future will be able to quickly discover how the code is structured.

Here is a quick example:

I'm developing an app that needs to collect WHILE displaying WHILE logging

The "WHILE" is a clue that these function should not get in the way of each other so I broke them into thrre seperate VIs to run in parallel. The functions performed by each are outlined by the State Diagrams for each.

Main

DAQ

Logging

 

I use a System Sequence Diagram to capture the entire program run and highlight the interactions.

The deatils of the interaction define the structure of my queues etc.

 

So.....

If you work-up a goode st of diagrams, your coding experience should be more enjoyable and rewarding.

Still trying to help,

Ben 

Message Edited by Ben on 02-17-2009 08:14 AM

[kphite]

Here is a simple mock up simulation of my real vi. I would appreciate it if you guys could look it over and tell me where the problems are. I believe it works pretty well but I've noticed that when I pause in mid execution and then restart the starting test is off by 1. I could "fix" that but I would prefer to understand the reason first. Thanks.

kph

[mikeporter]

A structure I have often used is to first build an event driven program structure to handle the button presses. I then add a timeout event with a very short timeout (say 1 ms) and inside this timeout I create my state machine. If I want to be able to pause the state machine I pass the timeout value through a shift register. Press the pause button and I set the timeout to -1. Press it again and I set it back to 1.

Mike...

[kphite]

Hello Mike. I think I understand what you mean but it would be very much appreciated if you could put a simple example together.

Also, do you have any ideas on how to handle a situation where there are 24 to 48 switches? That's why I chose a listbox control but I'm not sure how to fire events based on individual selections from the listbox.

thanks, 

kph

[mikeporter]

I can't post code for you but if you take a cut at it I can advise you on your implementation.

Secondly, firing events from a listbox is easy. A value change event fires whenever the user selects a new item from the list. Alternately, there is a double click event that fires when the user double clicks an item in the list.

Mike... 

[kphite]

"I can't post code for you but if you take a cut at it I can advise you on your implementation." Not sure I get that but okay.

I'll try to take a stab at it today but what I'm really asking is -- do you think your method is a better approach than the method I've already chosen (e.g. reliable behavior). My real code has a lot of other things going on and it seems overly complicated to me. I'm looking for ways to simplify and I'm not trying to impress people with my coding skills (because I have none). I'm probably going to have another project with similar requirements soon and I don't want to have to redo the framework.

kph

[mikeporter]

Event-driven program structures can be a great way of simplifying code. The interface is responding directly to your inputs and the event driven nature of the beast provides a nice structure for decomposing the functional requirement for the application into modular, reusable pieces. In brief, the approach I take is basically pretty simple. If I have something that needs to be happening all the time, that goes into the timeout event. The rest of the structure is creating events that respond to actions by the operator, or other pieces of code. For each input I ask myself, when this button is pressed what needs to happen? - and I put code to do it in that event. Once you've done it once or twice you'll wonder how you every got by without it.

Oh yes, you often will need to maintain some kind of state information that defines what the system is doing. Put that data (which is typically in a typedef cluster) in a shift register and pass it through all the events. If you do things right you may find that implementing a new capability simply requires manipulating that data. For example, want to pause the process that's running in the timeout event? Just set the timeout value to -1.  Want to turn it back on? Set the timeout to a positive value and now it's running again.

Don't worry if this seems a bit strange at first, it does require a slightly different way of thinking about design.

Mike...