wwbrown

QUOTE(Aristos Queue @ Jan 15 2007, 10:36 AM) I cannot find 45E85U1Y in the LabVIEW 8.2.1 release notes. Was it fixed? W. Brown

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

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

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.

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?

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

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.

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?