Leaderboard

This from the guy who turned himself into a gigantic penis in 7 seconds... I'll ask my wife, but I don't think she will be very keen on the idea... Oh, oh, oh... you mean the state machines.... That'll be a little tougher since I almost never use them. When I went through QSM rehab I chose the abstinence path and swore off them. While I was exploring how to convert QSMs into regular (non-queued) state machines, I discovered my application requirements aren't really met by the state machine pattern. So I switched over to messages and message handlers. (One thing I noticed in my QSMs is that my "states" weren't states at all; they were processes. Step back from SM implementations for a minute and think about the states of a can of soda. A few possible states are "wet," "cold," and "closed." If you shake it up and give it to your girlfriend to open it would be in the "overflowing" state. (And she'd be in the "pissed off" state.) These are all adjectives. They are describing a noun. Now look at the state names in your state machine. How many of them are describing a noun and how many are commands to do something? Is "spray soda" a valid state for a soda can?) What's the difference between a state machine and a message handler? In my mind the main difference is when you diagram a state machine you end up with states leading to other states, similar to this. (Ben posted this quite some time ago. I hope he doesn't mind me using it here as a good illustration of a control flow diagram.) Diagramming a message handler results in an asterisk pattern. It sits in an idle state waiting for a message to come. When it receives one it enters the case statement to process that message and immediately returns to wait for the next message. Each message is an independent and atomic operation. There is never a direct transition from one "state" to another. There are also terminology differences that (I believe) exert some influence over how programmers use these patterns. The very nature of state machines is to enter a state, do some work, and choose the next state based on its state at that point in time. That's what makes it a state machine. In contrast, message handlers only handle messages. By calling it a message handler instead of a queued state machine (which it closely resembles when implemented) you are giving it a different role in your application; one that when implemented is less apt to result in a messy maze of mixed-up machine states. (QSMs are the demon offspring from the unholy mating of state machines and message handlers.) Now that my excuses are out fo the way... The only code I have at the moment is some stuff from the first MVC app I wrote a while back. These are diagrams from the process loops of the Model ("Engine") active object and the View ("UI") active object. This particular UI was a prototype I used primarily to test out the rest of the app. It has only 5 buttons and a status bar--not nearly as complicated as yours. (Turns out they didn't really need all those fancy UI things they originally asked for...) In any case, I think this at least illustrates the idea. (In this particular application my active objects receive messages on a queue and use events to communicate to external listeners. Also, you'll notice I was quite liberal with my application of objects, going so far as to wrap every message, event, and the event's data in its own class. Neither of these details are important to the way I use a message handler. In fact, the two loops could be implemented on the same bd without the active objects.) This is the engine's process loop. There are only four messages this loop handles. See that vi in the middle, CalTableEditor:ExecuteCalProcess? Instead of creating an endless list of states to execute each of the 2 dozen calibration processes, all that complexity is hidden from the user here because the purpose of this vi is to handle messages, not execute a calibration process. The calibration process is delegated to the CalTableEditor object. (More precisely, it is delegated to each of the 2 dozen CalTableEditor child classes. CalTableEditor is an abstract class and is never directly instantiated. Each of the child classes is responsible for executing its own calibration process.) I send out events before the cal process starts and after it finishes so the status bar on the UI can be updated. Here's the UI's event structure to handle front panel events. If the user selects a valid calibration file from the dialog box, the path is bundled into a LoadCalFileRequestEventData object and the LoadCalFileRequestEvent is fired. (Whether or not anyone handles that event or what the actual outcome of the load request is doesn't matter to the UI. When something happens the user needs to know about, another module will send the necessary information to the UI. The UI only "decides" how to present the information to the user.) This is where the UI handles messages that are sent to it. Since this is a simple UI there aren't many messages it exposes. If I wanted to disable controls or have other kinds of UI changes I would add new message cases here to do those things. In this example an external module (the Controller in this case) has sent a ShowDialogBoxMessage object to the UI. Contained in the ShowDialogBoxMessage is a child of DialogBox.lvclass. Like the CalTableEditor class, the DialogBox class is an abstract class and the actual act of showing the dialog box is delegated to the child classes. (BTW, this is an example of the command pattern.) This app has six different dialog box styles that can be called by simply using a different DialogBox subclass when creating the ShowDialogBoxMessage object. The notifier is there in case the caller is waiting on a response from the dialog box.

Name: Advanced Database Query Submitter: Bruno Costa Submitted: 01 Jun 2010 File Updated: 03 Jan 2011 Category: *Uncertified* LabVIEW Version: 8.6 License Type: BSD (Most common) Description: This component automatizes the work of: format sql statement, execute sql query and build a cluster with data output. This function accept a sql statement with parameters like format into string and you can resize this function to the number of input parameters. The output data can be a cluster or an array of cluster defined double clicking on function. How to use: Wire db connection input. Wire sql statement with parameters like format into string function. Resizes the function with the number of parameters into sql statement, If the sql statement produces data output, double click on function to Edit columns of data outuput. Requirements: Database conectivity toolkit Scripting tools This function isn't 100% complete. It's need to complete some abilities and code improvements. If anyone want help me, be welcome. My email is bitcosta@ig.com.br Click here to download this file