JDave

So will LabView start having a scripting forum since it will be a licensed tool? It seems a shame to completely lose the ability to collaborate on a highly profitable area of LabVIEW development. If NI hasn't built the tool (such as diagram coloring or tunnel wizard) just build it yourself!! Hopefully there might be some avenue for continued community effort in this area. I was just about done with my first tool and I was so excited to post it and see what people thought. Anyway, thanks for the heads-up. I too will be pulling off all those scripting gems... David

Couldn't help making a reply before I can't do it anymore :thumbdown: I am not upset but I am saddened. I hoped to learn a bit more and contribute my first scripting tool... Oh well. In response, you can replace controls (Invoke Node - Replace) with the internal style. And if you do the standard 'replace' from the right click menu, the replace would be using the style. I wanted to use the style of an existing control. Now I am on my own... :headbang: David

After digging through PJM's Class Hierarchy builder, it seems that there is no such thing as a 'parent class' property. I like the scripting method for determining if a class inherits or not ("Find More Specific Classes"). That technique seems like it would work well. It seems that if I dig through enough posted example codes I will find most of my answers. Thanks for your inadvertent help, PJM. David

I am starting to cut my teeth on this scripting business. Many thanks already for the vast store of knowledge here. With some more time and experience, I may actually be able to contribute to this forum. Currently I just ready the posts and I am awed by all the Uber G Geeks here. :worship: I have seen some posts about generating the class tree dynamically, and such. Rather than create the whole tree, is there a way to bring the current class to some level in the tree? (without the tree, I know... ) Selection lists give an array of GObj references. These each can tell you their class name. I want to group objects that belong to a common super-class in the hierarchy. The reason I ask is the only way I have imagined and implemented thus far is to cast these GObj references to the super-classes I am interested in and take the one that doesn't give an error. This might be fast, since some types are more common than others, but is there a more elegant way of doing this? Thanks again, David

Does anyone know how to get at the 'style' of controls? For block diagram nodes this is a simple property. Controls seem to lack this property. This style is a string that corresponds to a ring control describing what kind of native object it is. Is there another way to generate it, maybe from the class ID? Thanks in advance. David

Are you asking how to make a vi that looks like the wood grain image earlier in this thread? Or what example are you talking about?

Here is the image then. Thanks for your help!

This is something I found out by accident. Probably old news to most. If you wire where an existing path already exists, your new wire path takes the place of the old one. Normally I would delete and rewire, or select and nudge, or right click and 'Clean Up Wire'. I was going to include a picture to help explain, but I couldn't figure out how to include anything that wasn't a URL. David And I meant that to be in the 'Tips and Tricks' thread. Showing off my newbie status today...

"the users could still open the VI, run it, see the BD, even open subVIs, but they wouldn't be able to edit the diagram..." You would also have to disable any copying abilities from that code. Forces someone to build that block diagram all by themselves. Piece by piece. At least for students that would be a nice feature. For proprietary code, just leave it with the BD locked completely.

Rings are interesting because they give two very nice added functionalities over an enum. They allow any number to be assigned to an element They allow run-time editing of list items The problem with rings is that their base type includes only the numeric. Using rings in your code requires you to have a front panel control and use the Properties node to get the string info. DAQmx uses rings and to play with the strings requires some interesting workarounds... It would be nice to have a different type that allows the strings to be bundled into the type, like an enum, yet allow any number to be assigned. Run-time editing would be gone, but if you need run time editing then you definitely have a FP object so you would use a ring. This would require some interesting type descriptor to allow for 'unassigned' numbers I don't know if this completely precludes the possibility, though. David

It seems like a good idea, but with an easy workaround. Just grab the code, Ctrl-C, then Paste it into an empty VI. You could add something that checks if ALL the code is selected, and send the copyright with the Paste. Maybe ANY copy from the code would include the copyright. Another problem perhaps: what if the destination already has a copyright? How would the Paste handle that? David

Thanks for all the feed back. Sorry I was so ambiguous with my first post. I am aware of the various work-arounds, and have used quite a few. I don't quite like having two separate inputs (string and enum) but polymorphism or a variant input are my favorites. The variant input requires me to see if the input was an enum, string, or something else. A bit of extra work. The reason for the "wish" is that sometimes there are vi's already written that take string inputs (or vi.lib vi's for that matter). If the enum contains the number and the strings in it's type, a coercion dot is not unreasonable. By the way, I have loved the OpenG toolkit and the Variant-Enum vi's have been very handy. Thanks for all your hard work. David

I tend to used type-def enum's to keep track of messaging commands, VI lists, whatever. Often I want to grab the text of the enumerated type, which is quite simple using the 'Format Into String' vi. If I have a sub-VI that needs a String input, it would be nice to simply wire the Enum into the node, giving me an automatic coercion without forcing me to put the 'Format Into String' vi inbetween. This is possible for numeric inputs to sub-vi's. And the Enum type is a combination of string and numeric, so it shouldn't be difficult to add. Not a big deal, but it has annoyed me recently. David

There was a thread a while back that discussed setting control values on a separate VI using the VI Server Invoke Node. I have created generic "Call VI" that can accept initialization values to write to the controls of the called VI, but it naturally gives an error if an INT is sent to a DOUBLE control. Being able to coerce the data being written would be very nice. The values coming in are variant, but they need to be typecast to a variant that is of the type of the control. Has anyone ever written a VI to change one type of variant to another? Either the Variant data itself or the type descriptor would be available from "Get Control Value" in order to do the coercion. Any ideas?