jgcode

No, it preserves the wire type, so no need to "cast back”:

Ha! I didn't know LabVIEW had that functionality (and it is all the way back to 8.2).

Just need to have a thralled(?) connection between the input and output for it to work.

Man, I wished this worked for an array of LabVIEW objects....

Anyways, I just commented on the image and just downloaded the VIs then - this function would be better than a Merge VI.

I’d like to suggest these three VIs (or similar) as possible LVOOP-object additions to the OpenG Toolkit:

“Get Class Name” is a modification of “Get Name of Class of Object” posted by AQ. Here it just returns the basic class name (which I use often in custom probes and the like).

"Get Default Object” is inspired by this discussion and uses AQ’s zero-iteration loop method. This is a very simple VI, but using it instead of the raw code is much clearer to the reader.

“Same or child class” just uses “Preserve Runtime Class” as a tester. Again, the advantage here is code readability (or it will be, as soon as someone comes up with a good icon for it).

Thoughts?

I like the suggestions to add functions like these to OpenG.

Get Class Name would make a splendid function IHMO.

OpenG does contain 'simple' functions where people sometimes argue that it is easier to just code the nodes each time.

I am feeling the same with the proposed Get Default Object function as any time you are not using the LabVIEW Object you would have to drop the VI and cast back to the Object (to e.g. use method VIs).

Therefore I believe it may be easier just to drop the For Loop and N=0 each time?

Maybe we could do this with a Merge VI instead?

Unsure if I feel the same as above about Same or Child Class.

Also thinking whether mje's Same Class test would be useful too?

How does "Get class name" work through inheritance? Does it return the correct class name at each level? Even whan called from dynakic dispatch method? (I don't have the time to test it right now...)

Yes, it flattens the Object which is on the wire - so the name of whatever you pass in will be returned.

Ok check this out!

<!-- copy and paste. Modify height and width if desired. --> <object id="scPlayer" width="1135" height="757" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/f39af9e0-aa03-4ae1-b2cf-af4dd76378b5/jingswfplayer.swf" > <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/f39af9e0-aa03-4ae1-b2cf-af4dd76378b5/jingswfplayer.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/f39af9e0-aa03-4ae1-b2cf-af4dd76378b5/FirstFrame.jpg&containerwidth=1135&containerheight=757&content=http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/f39af9e0-aa03-4ae1-b2cf-af4dd76378b5/LVOOP%20Propery%20Popper%20-%20Override.swf&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/f39af9e0-aa03-4ae1-b2cf-af4dd76378b5/" /> Unable to display content. Adobe Flash is required.</object>

From the help of my LAVA friends the tool is now able to open the correct override VI of a Child Class!

AQ provided the Get Name of Class Object VI.

I need to refactor the code to make it neater (backwards wire etc...) and would use subVIs to make this easier to read however, I wanted to post it in the easiest for anyone to test - but here it is.

App Vars.vi

Get Name of Class of Object.vi

LVOOP Property Popper.vi

Needs to be run in Project Environment.
Also, (if not open) probe window seems to flash briefly even tho it is set to hide, which is a cosmetic issue, no biggie.
WINNING!
P.S. - I will contact all authors and try to get this into a package, refactor it, then distribute it.

JG,

Can you add a probe to a running VI, also? What about a clone VI? (I have a use case that would be valuable, and perhaps I’ll dive in to scripting.)

— James

Don't know - I am 'swimming' myself at the moment with this probe thing.

My use case is edit time - that's what I am testing at the moment.

If so, you could connect a custom probe and have the probe send (via a queue or whatever) the retained object on the wire back to the VI doing the scripting.

Well what do you know...

I had looked at probes quickly before but with no luck - so I just went back in, found some nodes, converted AQ's VI to conform to a probe, tried it out and have my code 'working'.

Need to neat up the process, but I think I definitely have the tools to do it now.

Thanks everyone!

-JG

Que` pasa? I am able to use the tool, but installing it wasn't clean. I like the way you think

Nada mucho.

Weird - it works for me?

I was able to test 32-bit LabVIEW versions: 8.2, 2009 & 2011 on 2 PC's.

The LAVA Palette is up on the LVTN so assuming a connection to that is all good - I have no idea... ...lol

The only weird thing I have seen was that in 8.2 the PNG gets stretched when dropped as a MergeVI from the palette.

And it was to do with the Grid Size you use for the FP.

Changing it to a smaller Grid Size before you to the drop removes the issue.

This was no a problem in 2009 so it must have been fixed somewhere in-between.

Thanks for the VI AQ, but I am unsure how to use it correctly in the use case I presented.

If I pass in the Terminal's Data Type it always returns the Parent (even if a Child has run on the wire).

Here are the scripting properties I am browsing through which are available for terminal (left) to the wire (middle).

As Yair has mentioned - can it be done? What should I be using?

Cheers

-JG

Well if we have identified that that is what we need to do (certify every upload), then we should start doing it...

• A tool to add it to a VI before it is posted (I would be happy to make one)

Maybe a LAVAG template VI with the appropriate verbage would be appropriate? Create VI from template, upload with (choose your method)

Ok, here is a simple package that contains the CC0 license.

I can get this released on the LVTN under Team LAVA initiative.

With it you can apply the CC0 License in the following ways:

Create a New VI from a Template

Drop a Merge VI on the FP of an Existing VI

Include in a Snippet

lava_rsc_cc0_license-1.0.0.5.vip

I really like this tool and so, as per the video, I went ahead and worked on it a little.

The attached version:

• Opens only 1 VI - the correct Read or Write method, which matches the method on the property node selected
  
• Contains error handling and user feedback
  
• Attempts to remove the initial lag by initialising the listbox (need more feedback on this as to whether this has worked on other systems - please post)
  
• I have added Read or Write in parenthesis for a listbox item, in the case where a PN may have both
  
• You can re-click on the listbox to open another n properties (easy fix - the lvclass ref just needed to be cache'd back into the SR)
  
• Opens FP and BD of method VI
  

One issue I am having trouble with is opening an overridden method for the correct data on the wire (which I have inquired about here).

If the wire's type is a Parent but a Child is the Actual Data Type and you have Retain Wire Values on, it would be nice if the Child's overridden method opens (for such cases), but at the moment the Parent's method will open.

The code is a bit smooshed and the BD is large, but I wanted to keep it on 1 VI for distribution at the moment.

LVOOP Property Popper.vi

Use the Flatten To String primitive and take the name off the front. The details of doing this are posted somewhere on LAVA... I forget where. Try searching the OO category for "flat format".

I searched and found this prior conversation.

Thanks for your replies, but I am unsure how to use this to solve the OP:

... at edit time from a terminal input reference / wire reference

I.e. How do I tell what Class data is on the wire with an arrow...

...(assuming that it is run at least once and Retain Wire Values in ON) using a terminal (or wire) reference for that node?

Can you please provide more detail.

Cheers

-JG

I think this may be a bug - I tried this in LV2009 and get the same effect.

[LabVIEW 2011]

Howdy

If you probe a LVOOP Object it tells you the Actual Data Type e.g. the wire maybe that of a parent, but it will display the child's name if the child ran on that wire.

Is there a way to get the Actual Data Type of an LVOOP Object at edit time from a terminal input reference / wire reference (assuming the VI has been run and the wire has been 'executed' on).

There is a datatype property for the terminal but it just returns the parent class in the above use case.

I managed to locate this control which is part of the probe (<resource>\dialog\NI.LVClass.Probe.NameStr.ctl) hoping to find the complete probe and see the code - still searching tho:

Cheers!

-JG

dannyt: crelf's idea is really good and I concur - we could proceed with this change to the VI and everyone is happy (and backwards compatible).

Now anyone feel free to comment on the below:

So...

Functionally: this would occur inside the VI if the boolean was set to TRUE:

Name: Ignore Incoming Errors (F) - with a default of false

Input Type: Optional

CP: Add input here

For anyone else interested ->

I downloaded the tarball in Ton's link and created a wrapper VI for the action of interested.

If you run Main in the same folder as OpenG.vit and the extracted tarball folder than it will update the OpenG Tags on the FP.

Main.vi

OpenG.vit

opengtoolkit-build support.tar.gz

All files in LabVIEW 2009.

Nah - I don't know the guy who suggested that, but he looks like a real bogan.

Apparently he's bogan certified.

Be careful while scripting, not because of the "rusty nails" but more because it could be more fun than what you're supposed to be working on...

Damn straight!

I think that would be a pain. It should be sufficient that they have to check a checkbox that they agree to the sites T&Cs for software uploads (of course, the T&Cs have to exist ;p ).

That's kinda what my first dot point said. But it would have to be on a code by code basis - not a blanket.

The fact is that stopping it all is neigh on impossible (thinking about posting other peoples code). It's just the "arse covering" for Lavag that's important since it will be the first in line for the lawsuits if you do get a shirty uploader.

It's not just that. I like the etiquette involved, and knowing that I am free to do what I want with it.

Examples I provide here or on the dark side are usually created from scratch.

Maybe a LAVAG template VI with the appropriate verbage would be appropriate? Create VI from template, upload with (choose your method).

A tool to apply the license onto an existing VI would still cover this case but there is no reason we couldn't do both (and the user chooses what is appropriate for their use case).

I would like to suggest that this VI is a good case of a VI which should just ignore the Error in state and still do its job in this case just passing any error out obviously merged with its own error line.

This is just my opinion...

Although I really like the VI, I don't use it as I have my own API for setting up a UI which is my part of my UI templates.

But my initial response to this suggestion is why would you want that behavior?

If there is a downstream error then possibly something that feeds inputs in this VI may be wrong - and if an error did occur in just setting up the UI for display - then I probably would opt out on showing the UI to the user and report and error because other weird stuff may have happened to the UI setup.

I see that the change could be handy if you are not worried about the above and are linking errors to specify dataflow.

Of course one could get the effect of both of the above use cases by overriding the behavior e.g. like this:

...Having said all that, from an OpenG perspective things can always be changed.

As this is a change in behavior, this VI would have to be deprecated, and a new VI created to do what you are proposing.

What do others think that use this VI?

A community site like can never be as reusable as you would like without that certification on every upload, not just the highly scrubbed CR.

Well if we have identified that that is what we need to do (certify every upload), then we should start doing it.

Maybe this could be made easier for the code uploader:

• With an option when posting in the forum, or
  
• A tool to add it to a VI before it is posted (I would be happy to make one)
  

?

This is actually one of my favorite new 2011 features

And this one too, right?

No probs.

(NI hasn't published any sort of object model for the scripting engine have they?)

Not that I know of - maybe you could script one?

Right clicking a node and trawling through the menus is one of the things I do.

I am no scripting ninja, but if u get stuck on something just post or PM me - like anyone else on this forum - I am happy to help.

Hi Dave

Someone might be able to reply with a better answer who worked on older releases as I was responsible for upgrading the sources to VIPM - I know there was scripts that updated labels with build information (I know as a wrote code to remove these artifacts) but AFAIK the license stuff and documentation was static.

Having said that it would be super easy to script code to find a label (which had e.g. a tag on it) and update the VI Properties Documentation or vice versa.

Great news - congrats on the new role AQ.

Who can LAVA and the rest of the LV world count on for the "real story" and for a strong and clear advocate for users, esp knowledgeable and experienced users?

I say we lean on Mike?

So if I'm following this, jgcode you would "approve" of FGVs as an accessor but not as a wrapper, whereas others are OK with using FGVs as wrappers, using either a (large) typedef cluster for the inputs and outputs, in that sense turning the FGV into an "accessor" if you will to a collection of methods, properties, etc.

I don't 100% follow the above (I think our definitions of things are different - but that's ok).

If it helps here are my posts in summary:

• I agree with using FGV/MFVI/AE's etc... on a module per module basis
  
• I think all approaches discussed are valid - there are good reasons for both (I particularly find ShaunR's perspective in his last post above very interesting)
  
• I just personally prefer creating an API for a module
  
• I really like the 'LV2009' approach and hence wanted to post it in this thread to share with the OP
  

but as a warning VMs tend to make direct hardware access difficult or impossible, in case you were planning to run DAQ/Vision/etc.

Haven't tried linux distros (don't know what DAQ drivers are supported anyway) but I have had success running DAQmx in Window VM's with the later VMware releases (as opposed to a few years ago).