Leaderboard

Sure thing, I had to clean it up a bit but here it is. Attached is some code that I originally found in this thread showing how to read the contents of a control file, and replace a section with a new PNG. I think one caveat is the PNG that is being replaced needs to be larger (in file size) than the new PNG but in my tests I haven't seen an issue. https://decibel.ni.com/content/thread/4901 Extract the attached code, and run the Replace Button Decals\Create Multiple Controls From PNGs.vi It should set the control values on first run to paths relative to the running VI to use the example images and controls included. It will make a control for each PNG in the directory chosen. This will replace the decal, the VI Icon, change the label, the button text, and VI title so that it can be packaged up with VIPM nicely. I also included a VI to extract images from controls. Create Multiple Controls From PNGs.zip

Three points jump out at me from an implementation point of view.. The user is expected to propagate the error list. This is fraught with foot shooting possibilities (forgetting to wire a case through, for example, will clear all the errors). Try and encapsulate the errors into your API so that storage is handled and managed by the API itself. Creating and passing arrays around as you have will become a performance and memory concern as the array grows and is not deterministic. This will make it a no-go for real-time systems. Instead of just a string for your labels. Consider using a typdef'd string combo box. Then you can give the user a drop down list to choose from to avoid spelling mistakes but still allow them to enter their own custom labels.

I haven't looked at his code, but I want to clarify this: for unbundle/bundle, the IPE structure just enforces the "magic pattern". It doesn't add any logic behind the scenes at all. As for diagram legibility, that's subject to preference. (The magic pattern is when you use unbundle by name on the same items, in the exact same order, in a path of unconditional logic (i.e. bundle node not in a case structure). If you change the order, or fail to bundle an item, or bundle an extra item, or put the bundle in a case structure the compiler will duplicate the entire cluster in order to finish the operation. If you follow the pattern, it'll update the items in-place.)

Nope. Painfully tedious manual steps. Trial and error learning all the weird LabVIEW minutiae. I aint doing this twice.

I include a radio group with buttons in the package (calling it "Selection Buttons”). It also works well if you use icon decals instead of text. Can’t do the nice borders like in that package, unfortunately. That’s an example of something that (to me) should be a checkbox, since it is part of a form that must be submitted. Part of the reason I chose not to add the ‘X' is that it makes it more like a checkbox: check for true and nothing for false. But that requires the User to learn what the funny circles are, and what “white circle to the left” means.

I've had issues with switch controls like these in the past with users who aren't exactly sure what the states of the switch are the first time they use it. I don't want to say it is unintuitive, it is just one of those things you need to some times learn the first time. Don't get me wrong I like the look of the flat controls you've shared and I can see using them, but I can already hear some of my users when they see the switch the first time, and see the text "OFF" they will ask, "Does clicking this turn it off or is it off right now?" As soon as you've seen the two states of the button it is quite clear which is ON and which is OFF As a result I generally try to use system checkboxes, radio buttons (with two states with text for each), or a drop down, like a system enum.