Leaderboard

Well an FGV is the most trivial solution in terms of needing to code. It's not as explicit as a specific semaphore around everything and not as OOP as a true singleton class, but in terms of LabVIEW programming, something which is truely tried and proven. I would also think that it is probably the most performent solution, as the locking around non-reentrant VIs is a fully inherent operation of LabVIEW's execution scheduling and I doubt that explicit semaphore calls can be as quick as this. Also for me it is a natural choice since I use them often, even when the singleton functionality isn't an advantage but a liability, simply because I can whip them out in a short time, control everything I want and don't need to dig into how LVOOP does things. And reading about people complaints of unstable LabVIEW IDEs, when used with LVOOP doesn't exactly make me want to run for it either. I know this sounds like an excuse, but fact is that I have apparently trained myself to use LabVIEW in a way that exposes very little instability, unless I'm tinkering with DLLs, and especially self written DLLs during debug time, but that is something I can't possibly blame LabVIEW for.

Dearest LabVIEW, Sometimes there are simply no words that can adequately express the depth of a person's feelings that are plagued by regret, guilt and sadness for a wrong done. I know it can't undo what has been done and it won't ease the pain in your heart. Instead, let me write this to let you know that I regretted my actions, and cheating on you is certainly an unforgivable mistake. I totally deserve any the anger and resentment from you for what I have put you through. I was tempted by text-based programming, and I was weak. Not because the love between us was weak, but because I was coerced by another - let's just call her "the customer". I knew at the time that it was wrong, but she was so purseuasive. She bought me gifts, she told me I was handsome, she laughed at my lame software engineering puns, she made me feel special. I know now that these were all underhanded tricks so that she could have her way with me. She didn't care about me, ahd only cared about herself, and how I could help her. It pains me to see you suffering as a result of my misbehavior. Guilt burns in my heart thinking of all the hurt that you must have felt because of my recklessness. Each time that I think of you, I get angry with myself, my blindness and foolishness, and my indiscretion. I know there is still a strong love for you glowing in my heart. I truly want us to be happy again with me still being a part of your life. I know I don't have the right to ask anything from you when I have foolishly betrayed your trust in me, but I hope you can find it in your heart to forgive me and give me another opportunity to prove to you how much I love you. Give me another chance and I have faith that, one day, we will look back at this and laugh, albeit uncomfortably. Loving you always, crelf

One of these days (I have said this before) I will dust off my XNode Wizard. It automates a basic set of common tasks and makes it easy to create a certain class of XNodes: Growable nodes, dropping template code and mapping the terminals from the template to the XNode, and drawing the image. My own experience is that with the limited set of features I have managed to reverse engineer, they are stable, yet you can still write a broad spectrum of useful nodes, especially since a vast majority of the time you want a subVI with something resembling the type adaptation of primitives without writing hundreds of polymorphic instances. The fact that XNodes ship with LV (ie. Match Regular expression) means that stable objects can be created. Express VIs are using very similar if not the exact same framework. I can corrupt a VI with scripting, with Write to File, or even setting the current values to default. And just because I can wreak havoc with my reciprocating saw does not change the fact it is my favorite tool in my garage. With great power comes great responsibility. I do wish that someday I could package XNodes in Packed Project Libraries, they are made for each other. A single package containing one useful top-level object and a bunch of specialized subVIs that are best kept private. In the meantime, besides the existing resources on LAVA I would check out the following: http://forums.ni.com...ode/m-p/1293680 (a cool, simple XNode example. Shows handling clicks, type adaptation, and updating the image) https://decibel.ni.c.../docs/DOC-15362 (a bit of a play, shows a few more abilities and techniques) Attachment: This is a picture constant which allows drag and drop of common image types (JPEG, PNG). You can place this constant on the BD and then drag and drop an image file to get a constant picture. When you are finished, you can right-click and replace the XNode with a simple picture constant (this avoids the need to distribute the XNode with your VI). I like it as a quick way to get a picture constant without the usual method of read file, draw to picture indicator, create constant, copy, paste. Simply extract the folder and drag the .xnode file to your BD. XNodes can be added to your palettes, just remember to choose the 'All Files' filter when browsing for the .xnode file. enjoy! PictureConstant.zip

All IP. If I own a piece of metal and cut it into a shape that [you believe] 'belongs' to you, I've legally 'stolen' something from you. I think this is absurd.