Leaderboard

A) I'm completely with Jon on this one. If you have a subVI that does all this work, why not just call the dynamic dispatch VI inside the inplace element structure? B) If you really want to go with your solution, the following code does the same thing as yours but will seriously outperform yours:

Nope. The code for those dialogs is all written in C++. When a VI compiles, it generates assembly code for its run proc. For those VIs, when they load, we swap the pointer to the code block with a pointer to C++ code already compiled into LV. The diagram never executes.Can you dynamically register for the "Close Panel?" event on every VI in memory? Put up a poll for "all VIs in memory" that runs every 1/2 second or so and register for the "close panel?" event. I don't know how well that would work but it seems like something you haven't tried yet.

Sorry, I meant, removed compiled code from VIs. Darn..., to be clear the VIs posted at bitbucket should have the blockdiagrams present! The world of SCC now gives me the power to get the latest version -1, remove the compiled code and recheck in. EDIT:And if I really had removed the code, you could always get a version earlier. Ton

Seriously? I can't tell if you are plugging a product, or are confused about the topic, or are just trolling.

You might also consider a model where a single DVR refers to a cluster of the two objects or a third class has an instance of the other two classes as members and you use a single reference to that third class. For the record, you could just fork the wire, but that creates a copy of your object -- potentially expensive. The zero-iteration for loop uses the type of your object and constructs a default object -- which, on desktop targets, is essentially free since we have only one instance of the default object that gets shared around. Because the original class wire isn't modified on either branch, LV doesn't create a copy of the original object. There's another way to get this that might be considered less of a hack -- use the Preserve Runtime Class primitive. Fork your class wire into the center terminal of that primitive and wire a LabVIEW Object constant to the left input. Ignore the error out because there will always be an error doing this, but the output is a default instance of the class of the object on the center terminal.

Congratulations to Darin.K who was named Grand Champion of the competition. I highly recommend heading over to the darkside to check out his Math Node example. Cheers -JG

Using procmon is fun. I found a lv_subvi.vit. Boah! Well the first hint was googling for lv_quit.vi; I found a server where I don't have access to (but somehow I got some google-hit which displayed the line). It seems to be some lego toy library. So anyone who has a kid at that age, please search for these files on your kids PC. Well, any attempts to use it resulted in a crash. I thought I could upgrade my old 7.1 to 2011. As another dark alternative, I found some obscure ini keys that give access to some internals. First let's me load but not modify some menus, I think it's the the real IDE menus. The second one gives me all the 'dialog' that show up but are not present as a vi. Well, they just consist of the FP, the terminals are not connected. Wonder if I could place some code there. Anyhow, I'll need to setup a sandbox to mess around with this. Well, lesson learned as young novice of the black magic. Feed that google-engine the right keywords, and you get access to too many secrets you shouldn't know. Otherway round: if you need to keep a secret, fear big brother google. For the historians, there is an old lava mailinglist out there in cyber space . Felix