Yair

This is an appropriate place to link to the relevant idea, which has way too few votes - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Case-structure-prevent-automatic-change-from-selector-value-list/idi-p/1687284

I don't think I ever ran into this myself, but I have a vague recollection that this had to do with compiled code separation. I think there's a long thread in the NI forums on the subject.

You already have numerous options, but I think the simplest one in terms of similar functionality is replacing the color box with a picture control and coloring its BG transparent. Then, you just need to draw a rect of the appropriate size and for the transparency you can either use the T color for the rect or use an empty picture. The main potential disadvantage with this is that picture controls can be problematic in terms of memory usage, but I think you should be fine in this case.

That description makes the behavior sound a lot milder than it actually is. If you do this, you might find events disappearing completely or being handled by more than one ES at the same time. You might find event structures freezing for no apparent reason, etc. In short, like I said, a big no-no.

I do see something which is very wrong - you use the same event registration refnum for both event structures. That is a BIG no-no. If I change that and wire the cluster of event refnums into a separate register node, then there is no crash. Now, I'm not saying that a crash is the right behavior here (because it isn't), but you should definitely change your code. If you use an event registration reference for more than one structure, you will get various irreproducible bugs, because the system wasn't designed to work that way. There's a caveats section for events in the LV help which talks about this a bit, but the rule is simple - an event registration refnum should belong to only one event structure. The easiest way to enforce this is to always place the register node right next to the event structure itself, but you can also do the registration in a subVI and then bundle the reg refnums into the dynamic terminal. If you do that, make sure the VI outputs a different refnum for each call.

A couple of other examples you can look at are Jack Dunaway's cognizant UI example and Xtab, both in the NI communities.

I'm pretty sure that in recent versions the programmatic interface to poly VIs has improved considerably. The PolyVI class has an InstanceInfo property which I believe allows you to control the members of the poly VI.

The main reasons are probably cleanliness, code safety and efficiency. A variant will cause a data copy, which is not a big deal if you're comparing a boolean, but could be an issue if it's an array with 10M elements. If you also make all your VIs work only with variants, then you will either start getting variants in the BD or the user will be forced to repeatedly convert back (and possibly make mistakes). In the end, if you create a tool which will be reused many times, it takes considerably less effort to make it easy to use upfront than it does to make it simple to build. If you create an automated tool to help with the polyVI creation, then the effort becomes even more minimal. The real thing we need here is for LV to be able to automatically adapt VIs to work based on input type. NI has known this for years, but so far hasn't managed to come up with a stable and reliable mechanism. Hopefully at some point they will and then we won't have to deal with this any more.

You'll be happy to hear that people have thought of similar things before (for instance - http://forums.ni.com/t5/LabVIEW/LV2OO-Style-Global-VIs-from-NI-Week-2007-presentation/td-p/562527) and that LV has a much simpler mechanism for doing this - create a regular class, then create a data value reference to an object of that class. The DVR allows you to access the object using the reference. If you create property folders for the class, then the property node can even accept a DVR and get the object out of it automatically. A simple example:

Same here.

Maybe I'm misunderstanding you, but that example already has exactly what you want - folder 6 has a parent transaction class with undo and redo methods and you inherit the undo and redo methods from that.

I can say that I've seen the driver error several times since then (including this week), but in all those times it was for the entire site. Trying to go to anywhere on the site produced that error. I don't know which error specifically you referred to still having and whether you still have it now, but obviously you managed to post to this thread successfully.

I would suggest that you open the BD of every VI whose state is Run Top Level and then manually inspect their BDs for subVIs with the green arrow. This would at least minimize the amount of VIs you have to check (unless you open many dynamic VIs). The other alternative is that if you have actual stuff going on that you do use tracing but you only enable it when you get stuck. Presumably, at this point in time it won't matter even if it does alter run-time behavior. Of course, this won't help if there's nothing actually happening for you to trace.

As far as I know, the answer is no. Things you can do - Add special code to the VI so that it logs when it starts running. Use the Desktop Execution Trace Toolkit, which should give you the VIs which are actually running. I think that it might also be possible to tap into that data yourself somehow, but that's not public knowledge. Maybe if you know the right people at NI you could get that info.

And I saw that one coming from a mile away.

I posted an example here which shows how to create an "array of subpanels". You can use that to have graphs with separate properties. http://forums.ni.com/t5/LabVIEW/User-interface-problem-list-of-clusters/m-p/2311770#M726599

The app builder uses the same value as the IDE to decide whether to do full optimizations. You could have a pre-build step which sets the global property to a low value (or is it high? I don't remember) to get more VIs to be optimized and a post-build step to reset the property.

Duplicate - http://lavag.org/topic/16614-fuzzy-logic-controller/ WC, keep your question in that thread. It has nothing to do with these other threads.

Yes, it does. You can't use them across instance boundaries.

Use the Key Down? event for the control and discard the event if it's a tab (ASCII 9, if memory serves).

I just did a manual test (I pasted the generated image into Paint.NET) and it does seem to work - feeding 24 into the Image Depth input generates an image where the boolean terminal is 0,127,0.

I'm pretty sure that the default color depth for the method is 8 bits, so you get a limited palette. Try using 24 bits.

If there are a lot of them, the best way is probably to recreate the original (if you can simply revert from SCC, that's the best), load the code and then do a replace all with the new one.

There is another option I can think of, but I don't know if its performance will be any better - Get the VI's connector pane reference and use that to get the reference to the controls and the pattern. Then, use those reference and call the Application class method Data Type Color to get the color for each terminal and then draw the connector yourself based on the pattern. I'm assuming that the color is the one which actually appears in the con pane. You might be able to use code people already uploaded to make editing the con pane easier (I believe Mark Balla has one in the CR).

I don't really have much experience with editing palettes, but what you might be talking about is the readonly.txt file in the menus folders. If you rename it, LV should allow you to edit the built-in palettes.