Set alternating diagram colors.

[Michael Aivaliotis]

Well, a very BIG thank you to PJM for this post! He's opened up a whole can of worms. I immediately started diving into the different classes and tried to figure out the hierarchy. Now I can finally get the feature I knew NI would never add to LabVIEW. I think our wish list will slowly disappear since if we need something we can just program it ourselves.

I always wanted to have LabVIEW automatically color my diagram a slight shade of grey. But I also wanted every other structure to have white. So you would end up with grey-white alternating. Well, I just created a VI to do this! The process of building this VI was fascinating. It turns out that the VI diagram reference is only useful for listing diagram objects outside of structures. If you want to explore objects inside of structures then you must get a diagram reference to each structure. In addition, each frame of a structure requires another diagram reference. A simple comparison can be made between this and nested clusters in controls on the front panel.

Of course this could only be resolved with recursion. I've attached the complete code that does this. By the way, If you don't need alternating colors then just make both colors the same.

Hmmm.... what should I create next.

Download File:post-29-1081666033.llb

[PJM_labview]

Hi Michael

That utility was far on my todo list but it was there. Thanks for shorting my list !

Well, a very BIG thank you to PJM for this post! He's opened up a whole can of worms. I immediately started diving into the different classes and tried to figure out the hierarchy. Now I can finally get the feature I knew NI would never add to LabVIEW. I think our wish list will slowly disappear since if we need something we can just program it ourselves.

You are welcome. This scripting is indeed extremely usefull.

It turns out that the VI diagram reference is only useful for listing diagram objects outside of structures. If you want to explore objects inside of structures then you must get a diagram reference to each structure. In addition, each frame of a structure requires another diagram reference. A simple comparison can be made between this and nested clusters in controls on the front panel.

This was indeed what did stop me initially, but once I recognize (like you did) that a diagram is very similar to a giant cluster, I went on writing my own recursive VI to get different type of objects on the diagrams (such as Functions, SubVi, Diagram, Wire, Decoration, All Objects ). Since my grasp of recursion using Call by ref is weak, I wrote a recursive VI using a while loop (see Attached image).

Also, I notice the following class hierarchy (can simplify the recursion):

Structure [downcast to = (-->) ]

-->MultiFramStructure

------>EventStructure

------>CaseSelector

------>Sequence

Loop

-->WhileLoop

------>TimedLoop (Whatever it is)

-->ForLoop

FlatSequence is alone (downcast to nothing)

So really, when trying to get for example "All Objects" one does have to recursively check only for Structure, Loop and FlatSequence.

Hmmm.... what should I create next.

There are actually so many things that can be done with it, that it is quite hard to select what to try next . I have made tools like VI inspectors that look for certain type of objects (it did actually help me to uncover more exposed srcipting features among other things ). Another one that I made is called "Relink SubVI by Name". The possibilities are endless.

[Jim Kring]

One, "next step", that I suggest is a VI that outputs the inheritance hierarchy of a specific class. This can be represented as a path or and array of strings. The inheritance hierarchy of all VI Server objects could be stored (inside the VI) in a linked list. From this, one could populate a Tree Control with the structure of the VI Server inheritance hierarchy as well as doing more functional programming tasks.

I propose that these utilities and type definitions be organized in an OpenG package so that we can more easily collaborate and use the utilities. For example, I would like to create an OpenG package that puts the "New VI Object" and "Open VI Object Reference" (as well as some other recently discovered tools) into the palettes for easy access.

[PJM_labview]

Hi Jim,

One, "next step", that I suggest is a VI that outputs the inheritance hierarchy of a specific class. This can be represented as a path or and array of strings. The inheritance hierarchy of all VI Server objects could be stored (inside the VI) in a linked list. From this, one could populate a Tree Control with the structure of the VI Server inheritance hierarchy as well as doing more functional programming tasks.

Hmm, I dont see any elegant way to do that. The only approach I can imagine is brute force (meaning create a class specifier constant, then create the "to more specific" primitive then create another class specifier constant wire everything (all using scripting of course) and see if the first class specifier constant can be downcast (to more generic) to the second class specifier constant without error then repeat this process for all classes). Well someone might have a better idea (or inspiration might struck me ) ...

I propose that these utilities and type definitions be organized in an OpenG package so that we can more easily collaborate and use the utilities. For example, I would like to create an OpenG package that puts the "New VI Object" and "Open VI Object Reference" (as well as some other recently discovered tools) into the palettes for easy access.

Sure, I am willing to donate what I have wrote so far to the OpenG community.

PJM

[Jim Kring]

Well, there are only 88 Private Classes so how long could it take? Let's see... 88! = 1.855e+134. But, I bet if we apply a little logic it shouldn't take quite that long :laugh:

And, I bet that with the scripting tools that are exposed you can even create an "intelligent brute-force" utility that writes the "to more generic class" conversion and then runs it to test to see if it is valid. For example, start with any object and try to convert its reference type to a more specific class over all object classes. The types that do not result in an error are ancestors. Now perform the same test within (and only within) this set of ancestors to determine the inheritance hierarchy. Once these ancestors are determined, you no longer need to determine them. So, the tree structure can be generated dynamically and efficiently. One caveat... when you do the object typecast test you must be referring to a valid VI Server object, not just a null object that flows out of a Class Specifier Constant.

[PJM_labview]

One caveat... when you do the object typecast test you must be referring to a valid VI Server object, not just a null object that flows out of a Class Specifier Constant.

Jim,

Actually I just remember that the "to more generic class" has broken wire if one does not wire the appropriate class (in the appropriate "order"). So this way it should not be necessary to get a reference to the a valid VI server Object. To find out if a wire is broken or no, one just have to invoke the run method and a broken wire should return an error (Wire conflict probably).

PJM

[Jim Kring]

Actually, I think that you don't need to run the VI. You should be able to interogate the state/type of the wire to determine if is is (un)broken.

[SULLutions]

So, guys, does a hierarchical list of class specifier constants exist yet? I couldn't find it on the site.

Specifically, I'm currently looking for the highest levels at which I can elicit the Label.Text property.

[PJM_labview]

So, guys, does a hierarchical list of class specifier constants exist yet? I couldn't find it on the site.

Specifically, I'm currently looking for the highest levels at which I can elicit the Label.Text property.

3656[/snapback]

I believe this this what you are looking for.

Note: this is for labview 7.0.

New classes have been introduced in 7.1, but the end result is similar. If people are interested, I can post the code for 7.1.

PJM

[SULLutions]

I believe this this what you are looking for.

Thanks, PJM, that is exactly what I needed. :thumbup:

[SULLutions]

PJM,

This was indeed what did stop me initially, but once I recognize (like you did) that a diagram is very similar to a giant cluster, I went on writing my own recursive VI to get different type of objects on the diagrams (such as Functions, SubVi, Diagram, Wire, Decoration, All Objects ).

In the thumbnail attached to this post, there is an apparent OpenG Scripting palette. I can't find it on this or the OpenG site. Is it available?

[Michael Aivaliotis]

PJM,

In the thumbnail attached to this post, there is an apparent OpenG Scripting palette. I can't find it on this or the OpenG site. Is it available?

3703[/snapback]

This is PJM's personal palette. Perhaps with a little coaxing, we can get him to submit an openg package with these goodies...

I believe the closest thing OpenG has to scripting is the ogmnu_appcontrol_plus package. It can be downloaded with Commander.

[SULLutions]

This is PJM's personal palette. Perhaps with a little coaxing, we can get him to submit an openg package with these goodies...

Thanks, Michael. I'll give him a nudge, but I'm not sure how much weight I carry.

I believe the closest thing OpenG has to scripting is the ogmnu_appcontrol_plus package.

Only three functions instead of the zillions PJM tempts us with?

[PJM_labview]

Thanks, Michael. I'll give him a nudge, but I'm not sure how much weight I carry. 

Only three functions instead of the zillions PJM tempts us with? 

3707[/snapback]

Paul,

Ultimately I am planning to make a package of these VIs (along with more from other developpers may be ?).

I already posted about 20%-30% of these in different LAVA forums through examples. Another 10%-20% are just wrapper around exposed private properties. The more usefull (in my opinion) is the recursive VIs that look for Diagram object (such as the one seen on the above image you mentioned), and I think its accessible through relink all vi by name example or clean all wire (which are part of the palette as well) .

Happy digging.

PJM

[SULLutions]

Paul,

... The more usefull (in my opinion) is the recursive VIs that look for Diagram object (such as the one seen on the above image you mentioned), and I think its accessible through relink all vi by name example or clean all wire (which are part of the palette as well) .

Happy digging.

PJM

3713[/snapback]

Thanks for the hints of where to dig. I'm off.

[Mike Ashe]

The really neat thing about Michael's original diagram coloring tool was showing how to traverse a diagram hierarchy. I have modified it to do a couple of specific things before, but keep waiting for a truely generic spider to be released. Did I miss something somewhere? Did PJM ever release the package he mentions above?

[baturin]

I like this tool

I have made some small modification to it. Now dirs of vis can be recolored (and with recursive also). Modification require openg file tools. I attach the file to message.

Hope this will usefull to someone

[mseb]

Well, I used to like this tool very much, I however use LabVIEW from times to times only and it seems that it does not work with LV 8.2 anymore. Did you, by chance "upgrade" it ?

[Cool-LV]

this tool is nice, but why I can't find the property node's item selection at the property putdown menu,e.g. "diagram" and that property which is not red one (because red property node tells that is an old version). even I have actived the ini file with SuperPrivateScriptingFeatureVisible=True

my LV's Version is 8.6, any setting I should append ? or LV8.6 remove that function ?

see attached png file.

[Yair]

Scripting has been put behind the license engine in 8.x and NI does not sell licenses. The floated threads in this forum probably refer to this.

[Cool-LV]

QUOTE (Yair @ Mar 6 2009, 12:07 PM)

Scripting has been put behind the license engine in 8.x and NI does not sell licenses. The floated threads in this forum probably refer to this.

Well, Thanks, but I really like and want to know how I can get this function, just tell me how Michael has this ? anybody gives any thread that I will appreciate.

[Yair]

Michael probably used LV 7.x. Others have some methods for this. Look through the threads.

[Michael Aivaliotis]

I can attach an 8.6 VI with that property but it won't help you much since you can't generate the sub-properties from it. You need to do all your work in 7.1. I think there is a wind of change which may see scripting come out of the shadows. Hopefully sooner than later. If you feel strongly about it post your support here.