Jim Kring

Chris: Thanks for the heads-up on this. It's never too late for a good solution to a common problem :thumbup:

Sure - there's nothing new in dqGOOP, but it's a particularly eloquent implementation of it - and also a IMHO great place for those unfamiliar with OO to start understanding the concept.

Sorry, I should have been more explicit. I was not trying to detract from dqGOOP -- I was just answering your question about whether OpenG, or anyone else, could legally use a similar implementation. IMO, a pure G GOOP implementation is best if it is open. Stay tuned, interesting things to come.

Darren: Thanks you for the answer, extra effort, and CAR number. Five more stars, for you

Personally, I'm a big fan of GOOP using queues (I'd implemented my own version prior to the dqGOOP release, but the dq version is a lot cleaned than mine) - it's easy, fast and covers a lot of what I need to do (I'm certainly not a GOOP 'power' user). I'd sure welcome an openG version (is there any legal issues here? Can OpenG release an open under LGPL that's very similar to the dq version?)

Does anyone have any ideas of what's under the LabVIEW OO engine (soon to be realeased)? Is it going to be queue based, or something else entirely?

As you mentioned, dq was not the first to use queues for GOOP. And, the author has stated publically that it is a combination of ideas mentioned first elsewhere.

Do you have the OpenG Toolkit installed? I believe there is a function that will give you a quick conversion. It's not a coercion dot, but it's pretty easy.

Right, you will need to make the input a Variant, which anything will coerce to, and then extract the string value of the variant using the Get Strings From Enum function in the lvdata (LabVIEW Data Tools) package.

Lastly, if we were not meant to eat rabbits, they wouldn't be made out of meat ...

Yeah, and purple's a fruit.

mmmmm.... purple.....

There's more to the story.

By the way, have you tried dqGOOP?

Yes, I've seen and used the queue data store technique. Mark Balla has put in some effort refactoring OpenGOOP to use the queue data store. I'm not sure when this will be released, but it will happen.

Thanks Jim - I was unaware of this new feature in LV8. Does this mean there is no longer any reason to use a VIT?

I can't think of any reasons to use the VIT technique. Personally, I did not like it, due to the requirement that the VIT cannot be in memory when it is instanciated. This means that you cannot statically link to it in your application, which makes dependency management in stand-alone application builds more complicated and error prone.

I have not tried the .exe approach, but I am not optimistic. My classes are "active" classes (they are top-level and have a meaningful front panel), so use of re-entrant VIs is not an option.

In LabVIEW 8.0, each instance of a reentrant VI has its own front panel and debuggable block diagram. These are referred to as "clones".

Warren,

> Seeing as how the last couple of LV beta installations have broken something with the existing/working/installed versions of LV on my machine I'm not sure I'm going to accept though.

Get yourself a copy of VMware Workstation or Virtual PC and use a virtual machine as a sandbox for installing/testing the beta.

Cheers,

I seem to be having a minor problem. When I did that Firefox reported that it could not find page <filename> and I noticed that the name ended in ht not htm. So I tried it again, except that the more help button does not even press now. Any ideas?

Mike: I've seen this, too. I don't know whether to blame LabVIEW, FireFox, or Windows. The problem seems to come and go. Does it work for you in LabVIEW 8.0?

This is pretty cool... :thumbup:

For me personally, I'd leave out the Error in and out. We all know what they do and they just clutter up the documentation page. (Wish NI would do this too..) And maybe some nice headers for grouping inputs and outputs.

Jeffrey: That's a great idea. Those error clusters take up a lot of valuable space. It might take a =bit of work to exclude these controls, since I am just delegating the task of generating the input/output control/indicator documentation to some built-in functions.

Has anyone else noticed the degradation in VIT load time over LV7. I have a large application that starts a number of VITs as part of a class implementation for 10 power supplies. It takes an order of magnitude longer - less than a second under LV7 versus 10-15 seconds now. Has anyone heard of a workaround?

Have you noticed a different between the development environment and the run-time engine (built EXE)? I think I noticed a significant improvement in built EXEs.

I just checked with some of my colleagues in LabVIEW R&D and this is what I found:

Static VI Reference issue: This is expected behavior. A Static VI Reference will not appear in the Callees' Names or Callees' Paths property list. This is because a Static VI Reference allows you to have a VI call itself recursively, and the Callees' properties do not support recursive VI calls. I have filed a CAR (3VJDFQF2) against the LabVIEW documentation so we can indicate this fact in the help for both the Static VI Reference and the Callees' properties.

SubVI with Required Input issue: This is a bug, and I have filed a CAR (3VJDCQF2) on this issue as well.

-D

Talk about great customer support! Thanks, Darren. And, welcome to the LAVA forums. You get five stars for your first post.

It's a good thing that I only use Build Array in a loop.

Mike: That could be it. FYI -- I've pinged some people at NI about this, too. Hopefully we'll hear back soon.

The Special Characters for Match Pattern documentation states:

If ^ is the first character of regular expression, it anchors the match to the offset in string. The match fails unless regular expression matches that topic of string that begins with the character at offset. If ^ is not the first character, it is treated as a regular character.

What does "topic" mean in the above definition. I don't see any other reference to "topic" in the documentation. Does this relate to the algorithm used by the Match Pattern function? Is "topic" a subset of the string?

Jim's gone over 500 posts and has been promoted from "Extremely Active" to "<customize this text>" - congratulations Jim!

Off the chart! Woohoo :laugh:

The documentation for the Dictionary library of the OpenG toolkit is generated dynamically. Show the context help for one of the library members and then click on the online help link to open the HTML help in your browser. For extra fun, click on the example links.

This bug was NOT fixed in Labview 8.0.1.

Did you see this in the Release Notes? I couldn't find it. Maybe it wasn't considered significant. :headbang:

Jim, I see you had yours on St. Patricks Day. Happy belated Birthday!

I hope you had a great day and enjoyed the green Beer. :laugh:

Thanks, Christian. I did have fun. My wife took me out to a nice french restaurant. I tried sweetbread, which was great until I found out that it wasn't sweet or bread.

OK, it's time to pass the birthday baton...

Happy Birthday to Christian Altenbach.

Happy Birthday to Jim Kring who turns the big 30 today!!

We'd all like to thank Jim for his enormous contributions to the LabVIEW community including the founding of OpenG.

Keep up the good work Jim and may you enjoy many more years of LabVIEW development time...

Thanks, Michael. But actually I am only "e"teen years old (that's 0x1E, as I prefer to use the hexidecimal system for keeping track of my age )

The BD is like a "giant cluster", you have to traverse it to get all its objects.

That is a great analogy. :thumbup:

Just finished a mass compile using Jim's tool on a brand new 2GHz PXI controller - 14 minutes and 50 seconds! :thumbup:

That's a new record, I'm sure! Are there any other contenders?