jgcode

See here for original thread.

This tool has been packaged up on the LAVA-CR I will look at adding it to the LVTN in the near future.

Name: LVOOP Property Popper Submitter: jgcode Submitted: 17 Jan 2012 File Updated: 17 Jan 2012 Category: LabVIEW Tools Network LabVIEW Version: 2011 License Type: BSD (Most common) Copyright © 2012 Norman J. Kirchner, Jr.; 2007-2012 JGCODE ~,~ - The Captain was here... This package is Open Source LVOOP Property Popper is a tool that aids in debugging Class Property Nodes. Instructions: * Open the LVOOP Property Popper UI * Select a Class Property Node * Press 'Get Properties' * Double-click a property in the listbox to open that properties Block Diagram Restart LabVIEW to refresh Menus after installation Tools Menu: Plugins can be found under Tools>>LAVA>>LVOOP Property Popper 'Run' - opens the LVOOP Property Popper UI 'Open Example' - demonstrates features of this tool Installation Locations (relative to LabVIEW directory): '\vi.lib\addons\_LAVA\lvoop_property_popper' - main code '\project\LAVA\lvoop_property_popper' - tools menu plugin code '\examples\LAVA\lvoop_property_popper' - example code Click here to download this file

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 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? 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.

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.

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

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

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

Thanks for your replies, but I am unsure how to use this to solve the OP: 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.

Apparently he's bogan certified.

Damn straight!

That's kinda what my first dot point said. But it would have to be on a code by code basis - not a blanket. It's not just that. I like the etiquette involved, and knowing that I am free to do what I want with it. 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).

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?

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) ?

And this one too, right?

No probs. 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.