Leaderboard

Inspired by this idea, these are just a few, one-day-of-coding functions that implement a simple, regex based markup for string controls. For those not familiar with it, markup allows inline text to modify the displayed properties of the text. For instance, **bold** becomes bold, _italics_ becomes italics, etc. The code currently supports: Bold Italic Underline Colors (in #XXXXXX format) Text sizes (verysmall, small, large, verylarge) Strikethrough Some font setting Of course, it's still limited by the string control capabilities (no hyperlinks, no superscripts, no embedded lists). If people think it's worthwhile, I'll develop it into a somewhat more complete solution (or, of course, they can!). An X-control that supports it seems like an obvious extension, but I'm open to ideas. Note: this was developed in LV2011, and back-ported to LV2009. If you spot a problem with it, please notify me. Use: open and run LVMark_TestString.vi for a demonstration. Thanks, Joe Z. LVMark2009.zip

Hello Everyone I've been following this thread intently and comparing the comments to a framework that Rob Humfeld, and his team at JET and I have been working on since the CLA summit. Rob presented an idea that he and his team were working on called the JAMA framework. I was able to video record the presentation and the next week when I got the code from Rob I dove in and began working with it. Since then we have made many refinements and used classes to make the framework more powerful. Since this thread has discussed many of the issues that we have tried to design into the framework I thought this would be a good time to introduce it in its current version. At the CLA summit someone said that this framework was akin to an observer pattern. Since I wouldn’t know an observer pattern from a quilt pattern I will leave it up to others to decide what it is. I currently call it the Msg_Routing framework the fully tested version will come from JET sometime later this year. The framework has 4 major components Modules, Msgs, Couriers and Routers. There is a 5th component called Module Router but it is not necessary to use the framework 1. Modules are any vi that needs to sent and/or receive Msgs. To work within the framework the Module will need to create and manage a Courier and a Router for each Msg</li><li><font face="Calibri">2. </font>Msgs is a defined data set that is transferred from one Module to another. All child Msg class will inherit from the parent Msg class.</li><li><font face="Calibri">3. </font>Couriers: An abstract class which is the Msg transfer mechanism by which the Module will receive messages. A Module will create a courier child class and register the class to receive Msgs. Child classes Queue_Couriers,Event_Couriers, and Notify_Couriers are already a part of the framework</li><li><font face="Calibri">4. </font>Routers: These hold the information that tell a shipping Module how to get it’s Msg to other Modules. A Router is created for each Msg and they share the same name. A Router is a named single element queue so all Modules can access the same routing data. The Router’s data is an array of Couriers.</li></ul><br><br>Framework features<br><br>Modules are totally autonomous and can connect and disconnect from the framework at run time without affecting other Modules. The Module is responsible for connecting and disconnecting to and from the framework and is not dependent on its caller for anything. Modules have no knowledge of each other only the Msgs they deal with.<br><br>Modules are responsible for creating and destroying their own Msg transfer mechanism called Couriers. One of the attributes that I have use from the Actor framework is that a Module is responsible for creating and destroying its Msg Courier. Callers no longer have to create a reference and pass it to the callee. <br><br>Msgs are Global in scope and are usable by all Modules. Any Module is allowed to ship or receive a defined Msg. Msgs and Routers are the only two things that connect Modules to each other making this framework very loosely coupled. <br><br>The Msg transfer mechanism or Couriers is abstracted. This allows one modules to use "Events" to receive Msgs and another to use "Queues". The decision to use Queues, Events, Notifies, or any other is made on a Module by Module decision and does not have to be a system wide constraint. <br><br>A Module must register for every message that it wishes to receive. To receive a Msg a Module must find the Router and place it’s Courier in the routers shipping array. <br><br>To send a Msg a Module gets the Routers shipping array for the target Msg and ships the Msg to each Module via its Courier. Data consistencyis maintained because Msgs are copied and sent to Modules not stored. <br><br>Here are some diagrams to help visualize the framework. They correspond to the demos in the attached code.<br><br> <br><br><br><br><br><br><br><br><br><br><br>Developers<br><br>Module Developers only need to care about few things to work within the framework. What messages to receive, how those messages will be received and what messages to send. Developers can choose which method of Msg transfer works best for the module requirements by using a Courier child class that implements a specific mechanism. Only the Msg format is defined by the frame work how those Msgs are sent is up to the developer.<br><br> <br><br>Major Points<br><br>Msg transfer is completed without any kind of mediator loop.The Msg Router provides the information on how to send the Msg and the Module Shipping the Msg does the actual work.<br><br>Because it is the shipping Module that does the shipping and not another mediator loop, there is little loss in performance. <br><br>Modules are only coupled by Msgs and not the way in which they are transferred.<br><br>The full framework is attached complete with code, demos and images. It is written in LV 2010. <br><br>To start using the framework load the project and open the [Module Tree].vi all of the instructions are in the block diagram.The diagrams and instructions are inside the cases of the case structure.<br><br>Please let me know what you think of the framework good, bad or otherwise.<br><br> MSG_ROUTING.zip<br><br>Mark

Here's a list of ideas that just appeared on the Idea Exchange... they're all from a user "jcase", whose name is in blue, meaning he's an NI employee. JCase is the main developer of the new ACBR feature. As you might guess from the list of ideas, he sees a lot of ways that the ACBR could be extended in the future... Allow Remote Asynchronous Calls Allow Asynchronous Call By Reference with Strict, Static VI Reference Add Asynchronous Call By Reference to Call Setup Dialog Typeless Call By Reference and Asynchronous Call By Reference [/url] Add Timeout Input to Wait On Asynchronous Call Node Integrate Asynchronous Call By Reference with Event Structure Please kudos as you see fit...

Multiple people have requested I post the limericks I recited at the BBQ this week. Here they are, as best as I can recall from memory: There once was a coder named Kring He sure liked to right-click on things He once claimed he was faster Than the coding challenge master Yet he’d never step into the ring! There once was a coder named Mercer Who always had a class on his cursor Then Christina stopped by With her eyes on his VIs And said, “Clusters would make this code worser!” There once was a coder named Aivaliotis Who had a cool blog that he showed us It’s called VI Shots And we all love it lots But on facebook he keeps trying to poke us! There once was a coder named Goeres Who spent all his money on... ... ... There once was a coder named Justin Whose popcorn machine kept on bustin’ The problem, he knew, Was in no way LabVIEW Turns out, the real wires were rustin’. There once was a coder named Norm Who made writing VIs an art form. But not akin to Van Gogh, Or Michaelangelo, More like, a 5-year old with Colorforms. There once was a coder named Relf Who was always promoting himself. If only he knew “Image Acquisition and Processing with LabVIEW” to this day gathers dust on my shelf.

Is this a situation in which you only ever want to call the parent VI? If so, then just don't make that VI for the child. If, as you state " I want to force the child to call the parent method" Assuming that you want to selectively call the parent or the child, then you need to have and input to the VI that declares which one to call. Then from within that VI, take that input and either exectute what the child has for code in one case, or within the other case call the parent function using the 'Call parent method' primitive. This will give you exacly the type of behavior that your wanting, you just need to add an input to the function, or add a piece of private data to the parent and then call a function that sets that value, then within the function your trying to selectively choose, read that value and do the same kind of selective execution of code as mentioned above. Best ~,~

The problem comes from your choice of inheritance hierarchy. Inheritance should always be a "Is A?" relationship. In your case here, multiplication is not an addition... so multiplication should not be the child of addition. They could both be children of a parent class named something like "Arithmetic operation". Addition is an arithmetic operation, multiplication is an arithmetic operation. Now it does not mean that you cannot perform an addition in one instance and a multiplication in another, but this should be implemented differently and never forced arbitrarily from the outside. Consider this example where you have a parent class that is a generic 2D geometry where you have stored a collection of points that delimit any geometry (array of points). You could have a child class for a triangle, which would always have 3 points. And you could have another child for rectangles, which would have 4 points. When you call a method that is common to both children, for example "Measure Area", you will be calling the parent method which will dynamically dispatch the appropriate child method depending on the object type that is propagating on your wire. The implementation of the children methods will differ.

You should be able to us a 5V input SSR. Something like this Cyrdom CN024D05.

Do a google search on computer controlled relay or look at the Andurino documentation for schematics on how to do what you describe. Connecting a TTL directly to a relay would be bad. Tim

Based on the title, is this meant to be MarkDown compatible? That would be very nice! Ton

My point is that you shouldn't have to pay for stability and upgrading to a new version is not a bug fix, it is a project risk.

You forgot Lady Gaga.

Only foolin'. But... The DisplayLInk drivers for iPad work as advertised. You can use your iPad as an extended display under Windows... Set the iPad screen as my primary to move the Window toolbar to the iPad... http://itunes.apple....d411678720?mt=8 Install the PC client, and also install the app from iTunes (currently free!)

Olivier, FYI: your second link point to a non-existent page. It appears you have an extra "s" at the end of "software" You can handle drag and drop by using the Windows API. As a quick way to get started I modified the example that comes with the Windows Message Queue library which you can download from NI. The primary reason for this is that it has a message loop. You can then tell Windows that you're going to accept drag and drop, and register for the WM_DROPFILES message. The DragQueryFile function will tell you how many files were in the drag, and you can then call it repeatedly to get each filename. Attached is the modified example (LV2009) to get you started. You will need to download the library separately from the NI site. All it does is display the dragged files to an array indicator. I also do not check to see where the drop actually occurred (i.e. to see if the user let go of the mouse on the tree control as opposed to somewhere else). If you need this I'll leave it to you to add it in. Windows Drag Drop Example.vi

Splitters and panes are a big help in implementing resizable interfaces. Basically you use splitters to get one control per pane, and you can control how the splitters move as the window is resized (via right-click options on the splitters). Then if your controls have the "Size Object to Fit Pane" option checked, then they will resize reasonably well. The splitters can be resized to be very thin so they don't look as goofy. It still takes some effort to get things working well, so don't do it unless you need to.