newbie, application event dispatching.....

[ronyd]

Okay, I'm a software engineer developed appls in many event-driven systems, such as Java, XWindows, Windows, etc.  Since I don't have a labview programming manual on hand, I'm trying to understand the UI Event structure.  If I may refer to Java as an example, you register for events, and your callback mechanism handles that event.  The main event loop mechanism is transparent to the programmer.  So, my general question is how do I construct an application (like a main panel vi) that may have more sub-panels (.vi's), that utilizes the UI event structure?  Do the main panel vi and any additional vi's have their own Event Handling loop?  For example, the main vi will have the menubar, with 2 additional panels that will have different functionality and have variety of button, edit, and indicator controls.  Any resources and/or example references are appreciated.

[Darren]

Hello,

Although I haven't used them much personally, I think what you're looking for are Dynamic Events.  Check out the examples that are available with LabVIEW in examples\general\dynamicevents.llb to see how to pass an Event Refnum into a subVI to handle events within a subVI.  Also see how to define custom events (also called User Events) other than the standard ones available in the Event Structure.

Good luck,

-D

[JLS]

Hello,

What darren notes is one way to handle events, which can be very useful.  Basically, the LabVIEW programming object which "handles" recognizing events and executing event code is the Event Structure.  You have two options for registering events:

1. static

2. dynamic

Static registration is done at edit time, when you right click on the event structure edit and add event cases.  Dynamic registration involves programming, where you can register and unregister events programmatically.  This API also allows you to define User Events, which basically provide a mechanism for you to fire your own custom events, with the option to pass custom data along with the event.  In the static case, relevant event data is available in the left data node inside the event structure; the data available in the static case varies by event type.

The final distinction I'll make about events has to do with whether the event is fired and processed on the front panel before OR after the code in the corresponding event case fires.  The terminology used to distinguish those event "flavors" is Notify and Filter events.  Notify events are the case where the event happens, front panel activity is registered, and then code executes.  For example, suppose you register for a button click event... then when your program is running, and you click the button, it's value will change (it's a boolean so it would go from false to true) and then the code would execute. The Filter events are the case where the event is triggered (say by a button click again) but the value does NOT change first.  Instead, the code inside the corresponding event case executes, and you have the option to dispose of the event (for filter events there is a right hand side datanode as well).  If you choose to dispose of the event, the event is discarded and the button will not change value.  If you do not dispose of the event, the button will then indeed change value as a result of processing the button click event.

Ok, I think if you read the above few paragraphs carefully, and play around with the event structure (and event api for registering dynamically, and creating and firing user events - see the All Functions -> Application Control -> Events palette) you'll have a pretty good idea of how to start programming using events in LabVIEW.

Best Regards,

JLS

PS - the callback mechanism is something not entirely foreign to LabVIEW.  First, functions in general are just subVIs, and putting those inside the event structure is basically like "calling your callback function" when the event occurs.  Actually, to handle ActiveX events, you CAN register a "callback VI" which will execute when an ActiveX event occurs.  See the All Functions -> Communication -> ActiveX palette for the ActiveX API, which includes a function "Register Event Callback" where you can indeed provide a reference to a VI, which will cause that VI to execute when the corresponding ActiveX event occurs.

[ronyd]

thankx for info JLS.

Since yesterday, I've done alot of browsing the this forum in regards to handling events. From the design pattern templates provided by LabView, and ways to implements handling events utilizing these design patterns. All pretty interesting, but many comments on which pattern may or may not work for the particular application one is trying to build is of concern. In general, my application needs to service GUI events (menu, buttons, etc), and periodically process DAQ inputs. Which design pattern fits my needs that will be reliable without any pitfalls?

Sorry for this confusion. But, designing with other event-driven system, like Java, XWindows, and Windoooooze, this is pretty much transparent. I'd rather be spending more time on the application content, and not designing the event-driven mechanism that could in itself be a nightmare if not designed properly.

[JLS]

Hello,

The architecture of your program will depend on a few more details I'm afraid.  From what it sounds like, you can use a tradition UI handler, which is basically just a while loop with an event structure.  I am not sure what you mean by "periodically process DAQ inputs" - do you mean you need to acquire some data or read data from a buffer periodically (where I mean here, with some software timed definite frequency)?  If that is the case, you could choose many implementations to integrate that.  First, you could have a separate loop in parallel with the UI handler noted above.  This new loop could have a wait statement (based on your required frequency of data collection).  To get better software timing, use the "wait until next ms multiple" function, so you have more deterministic time between iterations - the other simple wait function will wait a specified amount of time in addition to code execution time, which therefore varies as code execution time varies... since you'll have UI handling in parallel, the time to completion of your DAQ subVIs in that new loop may vary as execution switches back and forth to handle your UI requests.

One important note is that you don't have to use a predetermined design pattern.  Subtle variations or even dramatic variations may fit your application better.  You just need to think about what tasks need to be achieved, what priorities they have, and then write code that makes sense for those requirements.  Perhaps what I have suggested above will be what you need!

Best Regards,

JLS

[ronyd]

JLS,
Disregarding DAQ processing for the moment. Currently, I constructed an application that is constructed with the following structures:
1. outter structure using "stacked sequence" to provide splash screen handling. Frame 1, sends VI off screen, Frame2 displays Splash vi. when splash screen is finished, Frame 3 is used to bring the front panel back on screen, and consists of an event handler.
2. The event handler is composed of while loop, event structure to handle menu item selection, and any other controls on the front panel.

Now my question is:
For an event that requires time consuming processing, how do I run the time consuming task asynchronously, so I can get back to the event handler to process other events? For example, if this task requires a while loop, which continuously generating values (like temperature values), and updates an indicator on the front panel.
Would a notifier loop do this for me? I guess I'm thiinking of threading, but can;t quite make an analogy for LabView.

[JLS]

Hello again,

LabVIEW has been a multithreading application for many versions now, but for most users the choices it makes are abstracted away from the programmer.  In any event, it sounds like you just want a parallel loop for your time consuming event.  A good way to make sure it doesn't dominate CPU time is to use a wait statment inside that loop (such as wait ms or wait until ms multiple).  The latter will give better iteration to iteration synchronization because the loop iteration is less senstitive to the time it takes to actually run the code inside, provided the delay is an upper bound to that code's execution time.  Note that even a wait statement with a 0 wait time specified will give LabVIEW the opportunity to swap threads... ie. service your other loop when the user starts clicking or something.

I think that's what you're considering - repost if I have misunderstood your question or you have a follow up!

Best Regards,

JLS

[ronyd]

JLS, thankx again.  I finally figured it out on Sunday that I can utilize additional loops for each time consuming tasks. Can a while loop (outside the event structure) start off as stopped, then started/stopped whenever I choose to do so?  I was thinking that I could wire a boolean button control  to the conditional terminal, thereby starting and stopping the loop.

[johnsold]

You cannot start and stop the loop that way. It sounds like you need to review the basics of dataflow programming. A section of code (such as a loop) will execute when all the incoming data to that node are available. If a node does not have any wires coming into it, it may execute immediately. Once it has completed execution it will not start again unless it is called again, for example by being inside a loop. Changing a data value does not produce a new call.

A state machine may be able to provide the functionality you want. Its loop will run until you tell it to stop, but you can put an idle case in it to do nothing until a button is pushed. A particular case can run as many times as need under the control of your boolean.

Lynn

[ronyd]

Thankx Lynn. After I posted that question, I realized this is no different than text based programming. Can't start and stop a while loop at will either that way. The light bulb is finally getting brighter with LabView processing. My parallel while loop polls every 500ms waiting for the button action to occur. A case structure within this loop handles the extra processing. At this point, I think I need to buy a LabView book. Sometimes jumping in with both feet and just utilizing help, tech papers, and discussion boards isn't the correct method to learn a new environment. But in all fairness, in 2 weeks time, from not having any knowledge about LabView, I constructed an event-driven application that I can now extend as needed.
thankx again for help on this thread.