wwbrown

QUOTE(Aristos Queue @ Jan 15 2007, 10:36 AM)

Can't find that CAR number... but I did find one with a very similar CAR number that includes a link to this post. That CAR is 45E85U1Y.

I think we've got enough to identify what's up, so no need to post any further code.

I cannot find 45E85U1Y in the LabVIEW 8.2.1 release notes. Was it fixed?

W. Brown

This bug also appears in 8.0. See this posting.

Are your posts about the Wait on Notification from Multiple icon or the Wait for All Notifications library VI? Do you mean to say that the same problem occurs with both methods?

The CAR is 45E8091Y. I have the original before and after code leading to this problem. NI should let me know if they need the original code to resolve this issue.

WB

The VI also works correctly if you popup on the 2 that is wired to the Index Array and select "Change to Control".

The bug seems to be something in the constant folding. I'll let JeffK know... did you already file the bug with NI?

I will do so this morning. WB

I may have seen this somewhere before, but the attached demonstrates a terrible bug. The indicator should update to "Ignore Notification". Remove the outer case structure or enable debugging and the VI suddenly works! I will submit this to NI shortly.

Download File:post-4503-1168388945.vi

Yes and the name of that technique is dqGOOP and all of that "clutter" is taken care of with wrapper VIs.

Brian

The way I see it, the 8.2 class becomes a subclass of the dqGOOP class. One implementation is the 8.2 class (itself a cluster) is the only component of the dqGOOP class data cluster. Then the dqGOOP wrapper VIs (the methods) are used to call the 8.2 class methods to access the data. Inheritance and automatic dispatching come with the 8.2 model so one of the few remaining issues is efficiency. Another issue is how to dynamically create the 8.2 class in the first place, though I think this is addressed in a recent NI white paper (attached).

I'll see if I can run some benchmarks with the above versus standard dqGOOP. Whatever penalty might be worth the hit to capitalize on future OOP enhancements coming from NI.

W. Brown

Download File:post-4503-1155396456.doc

QUOTE

This is one of the ways that I was thinking that could be used to give the by reference feel. Another that I think would work is if you use the endevo GOOP as a wrapper for the LVGOOP. Although it may seem a little redundent, I think it would give you a lot of flexibility for when by reference becomes implemented in the LV package. I believe you could probably ( not tested and only mildly thought about ) use the endevo GOOP package like normal, using the LV Object as your Data Member. Then in each of the methods you call the LV Native Methods for your object and pass in the Object Data Member. One thing that crosses my mind if this would work or not would be how LV actually protects its private and protected methods, so I'm not sure if that would cause any problems trying to implement.

Thanks! My thoughts have been along the same lines. I am using dqGOOP which is LV queue based using clusters. As long as you can enqueue and dequeue a class instance, I should be good to go. I hope the extra method call required to access the LVGOOP class data does not add too much overhead.

Alright, well I almost feel a little guilty about being so quick with my first post. After giving the overall concept more thought and discussion ( had a great chance to talk to many of the LAVA Guru's at the Salt Lick about this implementation), I don't feel nearly as cheated in this new implementation. I see the reason that this version of GOOP was a great feature which was lacking which is the passing by value (dataflow). After some dialogue with a few folks, it really doesn't sound tremendously difficult to create some wrapper vi sets to use your objects with to create the by reference feel of other current GOOP toolkits.

What techniques have you learned for wrapping by value GOOP to get a by reference "feel"? I have 10 openGOOP classes I need to rewrite using the new model but they rely on the by reference approach. Any referrals would be appreciated.

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 never liked it either. I needed it for some active classes (top-level, with FP) implemented with your openGOOP model under 7.1. By the way, have you tried dqGOOP?

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

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

Actually, you can get rid of them. Just add the line showTipStringsOnDiagram=False to your Labview.ini file.

The wonders never cease!! Thanks Yen - this one has been bothering me for YEARS and no one I talked to at NI had a clue. How did you find this flag?

I have concerns about many of your points - especially the typedefs. Also add the one about tip strips over case statement selectors that you cannot get rid of (they inevitably cover a comment you are trying to read). That one, however, has been around since LV7.0.

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

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?