Jim Kring

Far enough, but did anyone internal coin a phase when they put the two together?

Also what do you prefer?

Did you/where you involved in creating the DVR's?

My thinking: LVOOP objects are "data values", so a DVR to an LVOOP object is an object reference.

Is "LVOOP-DVR" is a little long winded

Does the LabVIEW community have a name for LVOOP-DVR'ing?

Is it too confusing to call it GOOP with Endevo, Sciware, DqGOOP etc already out there?

Was there a name that came up at NI Week 09 from NI?

Or is it too soon yet to have one? Can we vote on one?

With all the flavours it would be to be able to distinguish it when talking about it.

I have a feeling that people will/should just call this "native OOP" or "LVOOP" and start refering to DVR's as "references" (and DVR's to LVOOP objects as "object references"). This is the "right" (sanctioned) way to do OOP in LabVIEW, so there's really no need to qualify it. But, if you must qualify it, then the term "native" seems fitting.

*sigh* I wish we had heard about this during the beta program...

It might be a good idea to have (re)design discussion in a more public setting (like the idea exchange or here on LAVA) prior to reaching the beta phase, since:

• It's harder to change something that's already implemented
• The time window for the beta program is relatively short
• The conversation isn't visible to a wide audience

Of course, the flip side of it is that you don't get real usability feedback until people can actually use the feature (when it hits beta). I guess that I would also add is that it would be great if features like this would have a setting/option that allows users to revert to the original/legacy behavior. And, I think that this is one of the guiding principles of the new annual release cycle of LabVIEW -- features should be implemented in such a way that allows them to be switched ON/OFF, based on whether they are ready at the time when the product is scheduled to ship.

I hope this is helpful

Thanks,

I agree completely -- I really don't like the probe watch window or the fact that all new probes are automatically added to this window.

I recommended adding this to the LabVIEW Idea Exchange.

After playing around with the new probe watch window, I'm on the fence about it. I find it useful to have a centralized location with all my probes, but I also find it to be "not the way I'm used to doing it". I sort of think that I'd like the best of both -- have a probe watch window that shows all the probe values but optionally let the probes float freely, by default.

I agree completely -- I really don't like the probe watch window or the fact that all new probes are automatically added to this window.

I recommended adding this to the LabVIEW Idea Exchange.

Talk to Darren N. He's the one who felt these went with Quick Drop.

I talked to Darren in the hallways, here at NIWeek. He said that we can easily create an RCF plugin that calls the VI that performs these scripting actions.

I successfully activated LabVIEW 2009! No more evaluation mode

Only been playing with 2009 for a few minutes or so...

Is this the by ref implementation of LVOOP?

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

You actually could make a RCF plugin for this one

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

Since ages I am missing the context menu entry "Finish this VI". It should simply finish programming the code for the selected VI according to my ideas and the requirements. Does anyone has such a function?. Any idea how to make it?

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

That's just the sound of LV bending to my will....

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

Don't tell Norm -- we're having bars installed on the door to his cube... ;-)

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?

Tomi has made one parser that you can find in the OpenG root class template.

I've a version of that code in one on my VIs, it looks like this:

//Mikael

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,

What does an LVClass look like when we flatten it? The string has four parts...

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.

Uh ... um ... er ... I don't know about using Spoolie. He reminds me too much of "Clippy" (or whatever his name was) in Windows help.

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>

or, make it able to rearrange states! I hate the built-in method. I'll make it prompt the user in case the drag/drop was an accident.

I was thinking about making it handle Event Structures as well. I've got some work ahead of me. Thanks for the input.

This tool is going to rock (even more)!

Thanks, that worked like a charm. You know you could make that available in the Code Repository, right?

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

In that case, here's another iteration.

Beautiful and simple

I added a menu to the Tree to facilitate expanding & contracting.

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.

This has got to be it for today or I'm just going to get annoying...

These changes are all awesome! I won't get annoyed

I did put _rcf_ in the build page. I was about to report this on jkisoft.com forums. I'll try again tomorrow, but I didn't succeed in changing the package build name. Perhaps something I put in the ini file. I'll double-check.

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:

BTW, is there any way to include a readme.txt file in the VIP file? Strictly speaking, my submission doesn't conform to LAVAcr standards since I linked the VIP file directly. I guess I should just zip it with the readme file...

crelf's utility should do the trick. Let us know if you have any trouble making this work.

Fixed issue where letting go of the scroll bar inside the tree acts the same as a selection. I didn't like that behavior.

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)