Francois Normandin

Hehe, and if you look at my profile, you'll see that I have the same friend twice.

What I meant was that you should have one class per message type (10 message types = 10 classes), not one class per message type for each channel (10 message types, 5 channels = 50 classes). Like Daklu pointed out, this is not what you did but rather the additional classes I saw in your hierarchy were for testing the functionalities. I'm home today, so still can't have a look at the code. I'll refrain from further comments until I do.

OK, I was afraid I might be misinterpreting the disk hierarchy. Without looking at the code (no LV2010 at home), I was prone to make a wrong judgement there...

John, I could not test it because I lack LV2010 at home. Will take a peek at work next week. However, I can comment on the data structure based on the class directories. It seems your implementation requires you to create a new class for each new message type, and do that for each new channel you create. I don't think this is a good way to use the class hierarchy. Your channels and your message types are not separate entities as they should. Each classes is supposed to do one thing. In this case, either act on a message received, or send a message to specific channels. Not both. I might be completely off since I only comment on how your file structure is represented, but it looks like that if you were to create "Channel C", you'd have to also create new classes named: Channel_C_SendToA.lvclass Channel_C_SendToB.lvclass Channel_A_SendToC.lvclass Channel_B_SendToC.lvclass For Channel D: Channel_D_SendToA.lvclass Channel_D_SendToB.lvclass Channel_D_SentToC.lvclass Channel_A_SendToD.lvclass Channel_B_SendToD.lvclass Channel_C_SendToD.lvclass And it gets ever longer for each new channel you wish to create. To use wisely the OOP strenghts, you'll have to devise a way to have only one class to create if you add a new channel, ad one class to create if you add a new message type. I'm sure there's a way to do that using Queues. Like you would say, these classes need to be decoupled.

Microsoft did something even bolder: they had a whole OS for the End-of-the-World prank of Y2K.

Hi John, The way I've gone about this with OOP in the past is to use Events. Now, I don't know how well this solution would work for you, but basically, it's a framework by which each loop would subscribe. The framework is based on very simple code I put in the CR a while back: LVOOP Event Handler. If you're not talking about lots of data (high streaming), it could be worth exploring. I've done an example (attached code) for which you'll have to install the LVOOP Event Handler package for it to work. Messager.zip In essence, it takes a message hierarchy with a single dynamically dispatched VI to handle each cases, plus let's call it a "Loop" hierarchy to run each loop asynchronously. The parent Loop.lvclass will take care of registering each loops in the Event Handler. Then each loop needs to be a child class of this common ancestor. The only code that needs to be duplicated in the child is the way to talk with the Event Handler (3 event cases). It's all controlled with a "Global Stop" that is part of the Event Handler framework. Each loop calls the parent "Run.vi" that will initialize the messaging events for each loops. It does it by scanning all available loops classes on disk. Plus, it creates an event to dispatch a message to all active loops. This should create n*(n+1) events in the handler. Each loops overrides Run.vi, in which you have the event management plus you put your normal code. The events cases are "Global Stop" which gets the signal that the main VI has called for a shutdown, "Handler Activity" which gets called whenever a new loop is created and has added new registrable events and finally, "Subscribable Events" by which you will get the message when generated by another loop. As you can see from the project layout, the hierarchy is very simple. Copy one of the loop child classes and modify the Run vi. That's it. <object id="scPlayer" width="1376" type="application/x-shockwave-flash" data="http://content.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/jingh264player.swf" height="818"> <param name="movie" value="http://content.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/jingh264player.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/FirstFrame.jpg&containerwidth=1376&containerheight=818&content=http://content.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/quick_demo.mp4&blurover=false"> <param name="allowFullScreen" value="true"> <param name="scale" value="showall"> <param name="allowScriptAccess" value="always"> <param name="base" value="http://content.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/"> <iframe type="text/html" style="overflow: hidden;" src="http://www.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/embed" width="1376" frameborder="0" height="818" scrolling="no"></iframe> </object>

If you resize the MCL, you can hide the data by showing only the first column. However, if you want to keep it separate, you can make an index in a functional global variable. Store the data associated with each listbox element in the FGV and retrieve it on demand whenever there's a value change for the listbox.

To retrieve your data in the second column, use the "Item Names" property and index both column and row.

Yeah, it took me 9 years to finally decide to dive in... Oh, you mean about the posts!

Hi Ton, my kilt was indeed made in Ontario (don't know which city) and rented (yeah, way too expensive to buy, although I have regrets...) through a tailor in Montreal. The guy is retired and closed his boutique downtown Montreal, but still does some business from his home because of nice guys like me who still want his business! So it's entirely probable that he had it made in Hamilton, although I have no way to find out. Perhaps you can ask your aunt if she made a "Sons of Scotland" kilt for a January delivery. There must not be that many at any time period... 9-yard kilts are not that common.

Thanks Jon. Actually, this kilt is part of the reason I slowed down lately. I haven't had much opportunity to sit down and do good LV programming since Xmas. I was way too busy with the final preps for my wedding with Isabelle on January 29th... and I'm still day-dreaming about all the good time we got on our honeymoon. Since you already noticed the new pic in my profile, here's a more official photo with my new wife. photo credit: Chamsi Dib I had to look on the Australian slang dictionary for this one. I'll give more time to the rumors before I answer that.

"Edit mode" refers to the fact that you can only script an object while a VI is in Idle state. You can create an indicator or control on the front panel of a VI that is not running. For example, a VI cannot execute code to add a control on its own front panel.

You simply can't. GSW is a private VI in the Getting Started library (GettingStartedWindow.lvlib). The only public VIs from that library are "getting_started.vi" and it will fail if you have any FPs opened... and Close_GSW. There are two options here: 1- Idea exchange, as suggested by Jon. 2- Contact Christina Rogers (Eyes on VIs) and ask her for a quick fix, if she (or NI?) is willing to accomodate your request.

Here are some pointers for you. The list is not extensive but you might be in one of these situations: 1- One of your Dynamic Dispatch VI doesn't have the same connector pane (and datatypes) as its parent counterpart. 2- You have a Dynamic Dispatch VI that is set to require all child classes to override it, and one of the children doesn't override it. 3- You have a private VI that has Dynamic Dispatch input on its connector pane, which is prohibited. 4- You have one of the dynamic dispatched VI that is broken. Check all the hierarchy up to the parentmost VI.

Install this package from JG. It's a repack from Aitor's Scripting Workbench. You'll have all the super secret stuff you need at the tips of your mouse: Tools menu. thanks.

That would be the Application:MenuLaunch:VI App_MenuLaunch_VI.vi (LV2009)

I don't think there is any way to do it as of now. As a workaround, you could create a XControl containing a Graph and a self-made Palette Tools... more work for such a simple thing as positioning.

Unfortunately, the password you mention has been put there by NI, not myself. That's why I mentioned that the API is non-existent for the control editor. If you want to dig into this, the Control Class add-on creates controls based on templates stored in the LabVIEW Data directory. If you were to somehow create these templates dynamically to the size you wish, you can use the Control Class API to add images and text where you want and the size you want it. The setback here is that those controls cannot be edited (apart from text) once created... The image becomes part of the button background, so I can see why you'd want to stay clear of this solution.

Hoooo. Cat fight.

You can't with the "Modern Framed Color Box". It is possible to change it on the "Classic Framed Color Box" only using the paintbrush. At least, I don't know of any exposed property to do it programmatically. In any case, if you use an array, there is no way you can have different elements with different color frames. It's a property of the element type, not the single element by itself. (Changing the color of the frame for the nth element will change it for all), so I don't think you can use it in the example you published. trick color cluster.vi

There is no way to script your way through decals. The buttons API is non-existent and has never been refactored by NI since, I might be wrong here, LabVIEW 2.0. You need to play with the PNG's encoded in the .ctl file to manipulate them programmatically. Below are links to the code that Jon was talking about. First, install UI Tools Then, the Control Class Add-on. Once you restart LV, you'll get "Control Generator" in the Tools menu. The rest is supposed to be intuitive from there.

Jon's LVOOP Assistant renames Front Panel objects.