Leaderboard

Name: Multi-Column Listbox XControl Submitter: Karissap Submitted: 02 Jul 2009 Category: X-Controls LabVIEW Version: 8.5 Version: 1.2.0 License Type: BSD (Most common) Make this available on the VI Package Network?: Undecided Copyright © 2007, Karissa Purcell All rights reserved. Author: Karissa Purcell --see readme file for contact information Description: An XControl with enhanced features for the multi-column. To access X-Control features select More… from the shortcut menu. Features Automatic Ordering -. The Rows are ordered by a selected column in either ascending or descending mode (alphabetically). Columns can be selected by clicking on the column header with the hand tool. The sorted row is displayed in bold font with a \/ or /\ marker at the end of the name. Value Filtering – Rows can be hidden by applying value filters. The value filters will apply upper and lower limits (alphabetical) for columns. Alternate Line Colouring – Gives the Multi-Column Listbox a professional look by applying an alternating background and text row colour. Dependencies: Labview 8.5.x or higher Open G Array Library: oglib_array Change Log: 1.2.0: Fixed edit cell behaviour. Improved ability to convet older versions. 1.1.0: Added more commenting. Fixed bug in cell editing of column headers. Added saving of adjusted column widths. Added example vi. 1.0.0: Initial release of the code. Click here to download this file

I suppose I'll clarify my point for just a sec, then I'll try to follow my own points (about to be given) and provide alternatives. I think using (not even abusing) the Val(signaling) property is far far worse than globals depending on usage. Hence the fervor. I don't expect pretty code out of the gate but I don't know how to stop a newbie from adopting poor practices out of the gate other than striking the fear of god into them. Agreed, using dynamic events 'as truly dynamic events' is not a beginner topic, but I believe the use of 'user events' are beginner material which only requires knowledge of the mechanics of wiring them up. and summing up those last few points: I think that a smarter person than I would not need the 'fear-o-god' tactic to discourage poor techniques. Rather it would be much more classy and eloquent to give knowledge to them through some simple example programs demonstrating the bad aspects and demonstrations of better ways to do it. Now onto my attempt at eloquence: Jim Carmody did a great job with exactly what I think San was gunning for so I'll try not to replicate that First on some of the dangers of using the Val(signaling) Some simple programs are created that are fully reactive (waiting for some event to happen) and you will see this as just an event structure in a while loop. <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/8689b74b-ac72-44c8-952e-80c386e03c21/2009-11-29_1536.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/8689b74b-ac72-44c8-952e-80c386e03c21/2009-11-29_1536.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/8689b74b-ac72-44c8-952e-80c386e03c21/2009-11-29_1536.png" width="448" height="226" border="0" /></a> And depending on the scope of the code, this can get the job done just fine and avoid extra coding that may never be utilized. But the problem, and this sounds much closer to what San was looking at, is what happens when you now need to invoke the code within this state without the user hitting a button? By default, if the user doesn't know any better, they'll use the Val(Signaling) property. This is typically because it will require almost no extra code to be written other than dropping that property node. Well this starts to snowball into a bigger issue when someone decides that they just don't want to execute that one event state, but rather I need 4 states executed and I want that state to always be the second of the 4. What typically happens, is that the end user just starts stringing together multiple Val(signaling) properties for multiple controls to call multiple event states. This is particularly bad because there is no guarantee that as you string together Val(signaling) properties that they'll execute in that order, so you've just introduced potential bad logic in your vi. Now it gets even trickier if you like to use property nodes all over you code because if you need to better understand the flow of the program, how do you know who and what is controlling the state firing? Search for Val(signaling): you get all usages of that property (fail). Search for all property nodes of a given control: you now find every property of a control and you only find the property nodes that are directly linked to that control and you miss any non-linked property node. <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/54b79210-0b47-42d6-9770-4be1f36bbe13/2009-11-29_1555.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/54b79210-0b47-42d6-9770-4be1f36bbe13/2009-11-29_1555.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/54b79210-0b47-42d6-9770-4be1f36bbe13/2009-11-29_1555.png" width="437" height="142" border="0" /></a> And just to re-itterate. Don't underestimate the need to understand the flow of a program. You will someday need to re-learn what you wrote. Someone's LAVA tagline is perfect for this "Imagine the next person to work with your code is a deranged psychopath and knows where you live" So now onto some alternatives and notes about the Val(Signaling) property. Its intent in life is to provide that 'if all else wont work' kind of functionality to the LV language. An example of this is when using the data terminal of an event case. In this case you want that data on the terminal and the only way to programatically fire that event and still have that data is through the Val(signaling) property <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/41648ccd-13e7-4e07-9cce-b867b4dc6821/2009-11-29_1605.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/41648ccd-13e7-4e07-9cce-b867b4dc6821/2009-11-29_1605.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/41648ccd-13e7-4e07-9cce-b867b4dc6821/2009-11-29_1605.png" width="448" height="223" border="0" /></a> Now the alternative or smarter architecture associated with this, is to have the event cause a reaction in some other piece of code somewhere else that you have more control over than an event structure. This is where a solid event driven producer consumer design pattern comes in handy. I won't go into the architecture of this here but what this does allow you to do is have the code to be executed in a place that can be easily invoked programatically or interactively. Do the amount of wires increase? yes. Does the architecture increase in complexity? yes. Do you have a much more flexible and debuggable piece of code for just a little more effort? No question about it absolutely. So for the how-to-do-it portion of the code. San, It sounds like you are monitoring your code for the 0xFF Byte and want some other part of code to react when this happens. The code that Jim sent is about spot on and the only other thing that you'll need to do is share the reference to that newly created user event around your codebase. <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/6f18fd2d-c4a3-4e6b-9c38-c62bac86edf8/2009-11-29_1617.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/6f18fd2d-c4a3-4e6b-9c38-c62bac86edf8/2009-11-29_1617.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/6f18fd2d-c4a3-4e6b-9c38-c62bac86edf8/2009-11-29_1617.png" width="316" height="265" border="0" /></a> The part of code that needs to fire the event, will use the 'Generate User Event' vi <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/8a8cf0e9-cc0d-445d-acf9-b9483e37fbcf/2009-11-29_1619.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/8a8cf0e9-cc0d-445d-acf9-b9483e37fbcf/2009-11-29_1619.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/8a8cf0e9-cc0d-445d-acf9-b9483e37fbcf/2009-11-29_1619.png" width="235" height="488" border="0" /></a> And all parts of the code that need to respond to that event need to dynamically register for that event and then have an event case that registers for it. <object width="810" height="612"> <param name="movie" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/jingh264player.swf"></param>'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/jingh264player.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/FirstFrame.jpg&containerwidth=810&containerheight=612&content=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/2009-11-29_1624.mp4"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/"></param>'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/"></param> <embed src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/jingh264player.swf" quality="high" bgcolor="#FFFFFF" width="810" height="612" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/FirstFrame.jpg&containerwidth=810&containerheight=612&content=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/2009-11-29_1624.mp4" allowFullScreen="true" base="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/" scale="showall"></embed> </object>

The first thought I had when reading your original post was to use a User Event. These are events similar to Front Panel object events, but you determine the data type and you write code to trigger them wherever you want. In your case, you'd trigger it when you get the xFF from the microcontroller and your Event Structure will respond. Here's an example. UsrEvent.vi