Jim Kring

One of the main differences is that there are very few support VIs needed (as compared to other by ref patterns) when you are using DVR LVOOP (namely you'll want a constructor and destructor for each class, including descendants). Also, prior to DVR LOOP, most patterns used LVOOP as a wrapper around a reference (e.g. Queue) to data. With DVR LVOOP, this gets flipped on its head -- you have a reference wrapper around an LVOOP object. This is the first thing that really strikes you as different and unintuitive, but once you start using it you'll see that it makes a lot of sense (and, of course, you see some areas where things still need to be further improved). Dynamic dispatch only works on by value methods, not by reference methods. It would be nice if you could pass a reference into a by value method and LabVIEW would dereference and rereference behind the scenes. So, you'll find some duplication is required if you want users of your by reference class to call into by reference methods. You'll need to decide whether you want your users to 1) dereference/rereference the data themselves and then call your class' by value methods or 2) have a by reference method in your base class that calls the by value method. Also, it would be nice if you could wire a DVR LVOOP object into a Bundle by Name and Unbundle by Name and have LabVIEW automagically dereference/rereference the data behind the scenes. Right now, when you want to just get a value of an element of a DVR LVOOP object, you have to use an Unbundle by Name inside an In Place Element Structure. This is too much work for the programmer and makes the code look unnecessarily sloppy. The programmer's tendency will be to create a non-locking Get/Preview data method, but this isn't a great idea, because it makes a complete copy of the data -- by using an IPE Structure with an Unbundle by Name inside, you only copy the element. Those are the main things I've noticed. The bottom line is that if you do by ref LVOOP this way, you're going with the grain and you'll find things to be much easier now and in the future as more native features and usability improvements get added to DVR+LVOOP. Oh, one more thing that I noticed is that edit-time performance seems much better, which is probably due to a combination of: performance improvements in the LabVIEW IDE, WRT projects/classes/etc. fewer support VIs in the by ref classes

Yes, a data value reference (DVR) to an LVOOP object supports lots of great features, such as: use In Place Element Structure to get and operate on data, in place works with To More Specific Class and To More Generic Class DVR of Parent will coerce to DVR of Child LVClass can be configured to only allow DRV creation of its object from within a member of the class At JKI, we've been playing with this for a while and have worked out some cool design patterns that we're looking forward to sharing and discussing with the community, very soon (just need to fit this around NIWeek).

Download LabVIEW 2009 (755 MB) Download LabVIEW 2009 (64-bit, 822 MB)

how about a plugin to round the corners of wire bends?

JKI desperately needed this function while we were trying to write the RCF

That's right, because a ninja is silent and deadly.

I guess since Norm is always using LVSpeak, you can locate him by ear

Hey Veronica, Welcome to LAVA, a female-friendly and Canadian-tolerant establishment. See you at NIWeek! -Jim PS - Doesn't having Norm behind your back (where you can't keep an eye on him) worry you?

Hi Michael, Tomi's parser did the trick. I needed to parse the TD, not the data string, in this case, so I wasn't able to use your example. Thanks,

I'm now finding myself in need of a tool to parse the type descriptor of an LVClass. I can't use the flattened string data, since I'm actually parsing a reference (e.g. a Queue or Notifier reference). I'd appreciate any info on the type descriptor format, if anybody has it. Thanks,

Wow! I love the drag and drop reordering feature. This is super cool Here's are new features I'd like to see: Rearrange Cases >> Alphabetically: I'd love to have a context menu item (in the tree) for "Rearrange Cases >> Alphabetically" (or similar). Note that this should ideally preserve the separators and groupings as are standard in the JKI State Machine.

That was the whole idea! <object width="188" height="174"> <param name="movie" value="http://content.screencast.com/users/JKI_Software/folders/Jing/media/4c3b559a-aacd-4356-93b4-e5481999767a/jingh264player.swf"></param>'>http://content.screencast.com/users/JKI_Software/folders/Jing/media/4c3b559a-aacd-4356-93b4-e5481999767a/jingh264player.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/JKI_Software/folders/Jing/media/4c3b559a-aacd-4356-93b4-e5481999767a/FirstFrame.jpg&containerwidth=188&containerheight=174&showbranding=false&content=http://content.screencast.com/users/JKI_Software/folders/Jing/media/4c3b559a-aacd-4356-93b4-e5481999767a/2009-07-24_1614.mp4"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/JKI_Software/folders/Jing/media/4c3b559a-aacd-4356-93b4-e5481999767a/"></param>'>http://content.screencast.com/users/JKI_Software/folders/Jing/media/4c3b559a-aacd-4356-93b4-e5481999767a/"></param> <embed src="http://content.screencast.com/users/JKI_Software/folders/Jing/media/4c3b559a-aacd-4356-93b4-e5481999767a/jingh264player.swf" quality="high" bgcolor="#FFFFFF" width="188" height="174" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/JKI_Software/folders/Jing/media/4c3b559a-aacd-4356-93b4-e5481999767a/FirstFrame.jpg&containerwidth=188&containerheight=174&showbranding=false&content=http://content.screencast.com/users/JKI_Software/folders/Jing/media/4c3b559a-aacd-4356-93b4-e5481999767a/2009-07-24_1614.mp4" allowFullScreen="true" base="http://content.screencast.com/users/JKI_Software/folders/Jing/media/4c3b559a-aacd-4356-93b4-e5481999767a/" scale="showall"></embed> </object>

This tool is going to rock (even more)!

I *could*, but it's actually part of an internal library that does a whole lot of VIPM pre/post build hook stuff, some of which doesn't make business sense for us to distribute. Someday I might release the post-build documentation generator that builds and adds linked chm documentation to all your package files, but that would require me to do some work, and I just don't have time pre-NI-Week. If you remind me in a couple of weeks, I'll have a look at releasing it, as well as some other stuff that supports VIPM package creation... maybe... François: I'll try to temp crelf with lots of beer at NIWeek to convince him

Beautiful and simple

Nice work! This tool has quickly become a thing of beauty The only thing I would add is to remove the tree's column header -- this just takes up space. These changes are all awesome! I won't get annoyed

Yes, let us know if you have trouble making this work. Here's how we do it with the JKI plugins in VI Package Builder: crelf's utility should do the trick. Let us know if you have any trouble making this work.

Hi Jim. Thanks for keeping the new versions coming! I'm sorry for not commenting more on the code. The UI is so much easier and more fun to critique. Along those lines: * I'd get rid of the big "OK" button -- move it off screen and just let the user press the Close Window button to close the window. This will really stream-line the usability, IMO. * It would be nice if the vertical scroll bar would auto-hide itself if it is not needed -- there is a VI that can do this automatically for you, but I can't recall off-hand where it is located (somewhere in vi.lib perhaps)

Hey Norm, This behavior is true for any links between LabVIEW files under a Symbolic Path, not just user.lib. In order for a VI to "look relative" LabVIEW would need to know its own previous location under the symbolic -- does this information (it's own relative-to-symbolic path) exist in a VI that's saved under a symbolic path? For example, if I save a VI as "<user.lib>\Jim\MyVI.vi", does it persistently store information that it was last saved to "<user.lib>\Jim\MyVI.vi"?

Great! Also, a couple other packaging-related comments: 1) While there are no real official requirements for JKI RCF plugin packages, JKI has prefixed the Package Name with "RCF" to make them easy to find in VIPM's package list. For example, this might be preferable: normandinf_lib_rcf_insert_typecast-1.0.1-1 2) The package's homepage points to here: http://www.monpapyrus.net/ . You might want to update this to point to this discussion topic (the package's actual homepage), or put a link to this topic (and a list of your RCF plugins) on your personal homepage. I say this, because the package homepage URL should help the user find new versions of the package and obtain support. Thanks,

VERY NICE!!! Minor technical point: the operations inserted are not really a type cast, but a type conversion -- casting means changing the type, but not the data; whereas conversion involves changing both the data and its type.

A very nice improvement! Here are more suggestions: Its window should be set to "floating" It should run as an asynchronous process -- it should not close its front panel after the user double-clicks on a value (you should probably invoke it with the VI.Run method so that it doesn't block the Right-Click Framework) It should allow multiple instances -- make it reentrant so that I can use to work on two Case Structures at the same time. It should make sure that the user actually clicked on a named cell (using the PointToRowColumn method) -- it is currently treating a double-click on the tree node expander ([+]/[-]) as a frame selection. Cheers,

Oooh, that's a good one! I don't think that was on our list -- I'll add it, but don't let that stop you from the exercise. Yes, the List of Community RCF Plugins page is configured to allow anyone to edit it. I would also recommend creating a new page in the RCF group, similar to the Build Array of References and Explore plugins pages. There, you can post documentation, a download of the latest version, revision history info, a link to a discussion topic, etc.

Hey Jim, Great! Thanks for posting this. This is totally useful. I can think of a couple additional features and usability improvements. For example: How about using a listbox (or tree) instead of a 1D array of strings? The window should be resizable and the list should auto-grow with the window (this might not be possible with 1D array) PS - JKI has considered creating some "helper tools" for the JKI State Machine. You might even see some demos at/around NIWeek that will BLOW YOUR MIND (I just had my mind blown this morning by some prototype stuff I saw). Also, I've added this to the List of Community RCF Plugins.

You beat crelf to that one