smenjoulet

Yes, but it wouldn't help you. You have A.lvclass at version 1.0.0.4. You save lots of data. Now you rename the class to B.lvclass. You certainly could bump the class version in the file from 1.0.0.0 to 1.0.0.4. And you could cut and paste the mutation history from A.lvclass to B.lvclass. That's great -- you now have a version 4 of B that can load any data that was flattened as B versions 0, 1, 2 or 3. The problem is that all of your data was flattened as *A*. The name of the class and the version number are both part of the flattened data. It has to be because when I flatten data on an A wire, that data might be a child class like ChildOfA.lvclass. When I unflatten data onto an A wire, the data has to declare which class it represents. So, yes, you could preserve all the mutation instructions of your previous class on the new class, but it doesn't make any of your data accessible. To be able to unflatten old data, you have to be a new version of the same class and "same class" means same name. So admittedly this is the end of the day and I haven't given it too much thought, but would it be possible in future version of LV to decouple the Class Name from the .lvclass file name on disk? Would that allow us to avoid this issue with renaming a class? I'm willing to bet that in most cases (as Dave points out) we're just needing the *file* renamed and not the actual CLASS itself. If you actually needed to rename the CLASS, then it works as it does now and wipes the mutation history. Any problems that could engender? -Scott Nice presentation by the way!

Let's make it a three way fight...

Yea, and that's just the nesting you can see! And this is one VI out of hundreds. The original developer recently had to make some changes (I'm not gonna touch it; it's like a house of cards- remove one VI and the thing implodes) and we did a code review of the changes. One of the people in the review who doesn't know LabVIEW said, "Ow! That hurts my eyes!" Tell me about it. I've gone home with headaches after looking at this code.

Well you threw down the gauntlet, so I had to pick it up! Cleanup handled it pretty well, it took maybe 10 seconds. I can't say it's any more usable; in fact I'd say it's worse. Same code now spread out over 5-10x the real estate. Some messes you just can't clean up... Thanks Crystal. That's pretty bad too. Where do these people come from???

I think you're confusing this with the licensing for MathScript, which had a script node similar to the MATLAB node. MathScript used to be included with a LabVIEW Pro license (and maybe LabVIEW Full, don't remember). It is now a separately paid for license in addition to LabVIEW. The MATLAB node (to my knowledge) does not have any special licensing requirments from the LabVIEW side. Of course, you do need a MATLAB license to be able to use it. -Scott

For what you posted, you don't need to use the Locate File VI and you're using the Extract VI incorrectly. FYI, the Extract VI uses the Locate File VI in its implementation. See the attached for how to do what you want and have it work correctly. -Scott

Try these on for size! That little white block on that last one is my 1920x1200 monitor. I'd need about nine of them side by side to see the whole thing. At least I don't have to refactor, but try and understand and document that! If it were up to me, it would be rewritten from scratch. That may happen yet at some point.

Can't answer the RT part of the question. For your second question though, you could store the size of the table in the variant itself as it is not used for anything else in this scenario. Just remember to update the count whenever you add or remove a key/value pair. -Scott

I think it would be useful to have the date and time of when a topic was started shown along with the person who started it in the Started By column. This would be the same type of info that is shown in the Last Post Info column. Would anyone else be intersted in that? How possible is it to implement?

That was my first thought. Look Here. I only gave it a cursory overview. -Scott

While I'm not in this situation, I can envision a rare one. Both Jeff Phillips and I posted this scenario in our previous posts: 1) Buy LabVIEW 8.6 in October 2008 (get one year of SSP) 2) Get all 8.6 bug and maintenance releases. 3) Under SSP, you upgrade to LV2009 when NI releases it in August 2009. 4) You do not renew SSP in October 2009 5) You still get the 2009f2 and f3 fixes, but not SP1 as your SSP has expired At that point you are not required to "pay" for SP1 if you don't feel you need, but you also can't install it. But if you do you need it, you would need to "pay" for it by renewing the SSP on your license. The cost for that varies by how long your license has been inactive. Whether you interpret that as actually paying for SP1 or paying to renew your SSP (and getting SP1 as one of the benefits) is up to the indivdual. Like I said, I think that situation would be pretty rare. -Scott

As Chris and others have noted, I think that is an unfair characterization. I think this born more out of anger at the SP1 terms than of the general bugginess of 2009. It is my anecdotal experience that the quality of NI software has generally improved over the years. There have been hiccups here and there, but I find LabVIEW, etc. more stable than in the earlier years. Let me preface my following comments by saying that I don't agree with NI's verbiage on SP1 nor am I trying to defened them. I am just trying view it from the opposite side to understand the motivation. Let the flames fly. On the requirement of an active SSP for using SP1: Stop for a moment. I think it affects relativley few LabVIEW users. If it does happen to affect you, that is little consolation. But you might need to adjust your "upgrade" practices. Let me explain: 1) If you purchased 2009, then you have 1 year SSP built-in. No charge for bug fixes. 2) If you buy the upgrade to 2009 from an earler version, ditto above. 3) If you have an active SSP (per SP1 terms) there is no charge. 4) If you are not using 2009, you're not affected. The only users it would affect are those that had an existing SSP (ealier LV version, Dev Suite or VLA) and let it expire between the release of LV2009 and the release of SP1, but they used that SSP to upgrade to 2009 before the expiration. If you are upgrading to a new version, you might want to question the practice of letting SSP expire. Everyone else should be covered. Like I said at the beginning, I don't agree with terms, but if affects few users and those it does affect had a choice. On the motivation of NI to adopt these terms: I think it comes down to users getting up to two years of SSP for the price of one. Take the following example: I purchase LV8.6 in Oct 2008. I get my 1 year of SSP. I get the 8.6.1 maintenance release. NI releases LV2009 in August 2009. I upgrade to LV2009 in September. I let my SSP expire in October 2009. I get 2009f2 and f3 fixes. NI releases LV2009 SP1 to active SSP users only. I am "locked out" of the additional bug fixes by not keeping SSP active. But if NI let me have access to SP1, I'd be getting a year and a half of SSP (minus the priority phone support). That could extend close to 2 years if they have additional fixes come out. I'm not defending these terms, just offering up this viewpoint for you to chew on and spit out as you wish. If you disagree with NI, make your voice and case known. [EDIT] Jeff Phillips has made some additional eloquent arguments from the NI side above. I second that 100%. If you have a good a DSM/FSE then work with them. Have the above discussions with them and raise the issue. I've usually found them willing to do whatever is reasonable to help out. -Scott

smenjoulet (LAVA) / Scott Menjoulet (NI) {rarely} I think that might actually be true.

Eric, Ben, The issue in this case is not with VI snippets, but how they are attached and/or displayed in forums or web pages. Often the image is just a placholder for the real image file. The placeholder image doesn't contain any of the VI code for the snippet feature to work. When you drag it, you get the circle with line through it (operation not allowed). When you find these cases, right click on the image and select "Save Target as..." (not "Save Picture as...") to save it to you computer. Then drag the resulting image file to your LabVIEW VI and the snippet should work fine. I was able to get all the snippets you referenced into LabVIEW, though some searched for missing VIs or typedefs that aren't saved in the snippet. -Scott

Sweet! More toys!

Mike, Here's the non-OO implementation. Norm, I was not trying to imply that the OO design should not be used going forward in any substantial project. I was making the point that to understand the concept, especially for a LVUG presentation as Mike is doing, I think it is easier to start from a non-OO base, especially when you have limited time. I agree that once you get the concept, moving to the OO approach should be the goal. I don't know 'bout genius , but it was fun. Thanks for the props! -Scott LVx Example.zip

It does work although I think it deserves a better example. This was Norm Kirchner's OO implementation. My original implementation (circa 2004/2005, ~LabVIEW 7.x) was not OO as native LVOOP did not exist in LabVIEW at the time and I have never used Endevo GOOP. I think it might be better to start with a non-OO example and then work up to OO as appropriate. I'll see if I can dig one up or put a simple one together. Mike, Norm and I were going to put a similar presentation together for NI Week one year, but it never made it off the ground. I'd be happy to collaborate on part of it with you. Just send me a PM if interested. -Scott

Kudos, Ben! Oh wait, wrong forum... -Scott

You don't need to specify a 0 timeout if you want to enqueue something as fast as possible. If there is room in the queue, it will be put on it. If you are using an unbounded queue, then theoretically the function will happily enqueue items until you run out of memory no matter what timeout value you specify. If you have a bounded queue (as in your example) and it is full, then the enqueue function will wait until the timeout expires or space becomes available. If the timeout happens first, no enqueue takes place. You will not get an error from the function, but you can check the 'timeout' output to see if a timeout occurred. -Scott

I debated with myself on whether it was worth it to reply or not and lost. I stand by my comment that "there is no difference", as I believe (correct me if I'm wrong) you missed the point of my statement. Of course there is a difference in what data was actually sent in our examples, but that isn't what I was referring to. Yep. Now looking at your example, notice the "Generate User Event prim *thinks* the queue is typed with the parent object". Sure, there is a difference in data being sent. I explicity chose to send a parent object, while you say you are restricting yourself to sending a child object. It doen't change the fact that both examples are the same in that a child event refnum has been cast to a parent. Yours was explicit with a type cast. Mine was implicit with the refnum coercion "bug" in 2009. But the result is the same. Again, no disagreement in principle, but I could have sent a child object and I would have the coercion dot as well and it all would work fine. That would defeat the point of the experiment. In your example, you could also send a parent object (consciously or accidentally) and you wan't get any coercion. You'll end up sending parent data to a child object. It will 1) wire up correctly 2) compile 3) run and 4) CRASH... probably hard! If you look back at the rest of my statement, I say: But if you're careful to ensure that you don't send the wrong data, I'm betting it works fine. That's what you're doing. Being as careful as you can with the structuring of your framework to ensure that doesn't happen. Conclusion- Technique: SAME Data: DIFFERENT I'll split the pot with you, how about that... Ditto that! -Scott

Well, depending on the circumstances, you're both right. And also partly wrong. It's all a matter of perspective. I identified and tried the following four cases: 1) Dynamic dispatch where all members are available. 2) Dynamic dispatch where just the child method was available 3) Static dispatch that does nothing 4) Static dispatch that passes out data All were tested with the parent data being dumped on a child wire: 1) Functions normally, maybe to the chagrin of AQ. Parent and child VI's dispatched appropriately depending on the type 2) Gives the "This dynamic subVI cannot execute because the needed member VI cannot be found" error. 3) Does essentially nothing. No errors. No crash. 4) Ahh... well the devil he no like this case. As a fine a lady as Miss LabVIEW is, well she try tado da dance on that high wire and she trip and fall flat on her face. And a big flaming pit open in the ground and she be dragged straight to hades. As expected you cand perform tha same cast in 2009. Strictly speaking, I am betting AQ will call this a "hole" that needs to be covered as I don't see that it is any different than what I tried above. So from that perspective I'd say that it is bad. But if you're careful to ensure that you don't send the wrong data, I'm betting it works fine. So I think we're all in agreement that having parent data on a child wire or control is BAD. But instead of not allowing these typecasts or polymorphisms and causing broken wires, I wonder if there isn't a compromise. I would think that even though a child basd user event (or queue, etc) refnum has been cast to a parent type, LabVIEW would still be able to check the true type and throw an error from the primitive at runtime. This would allow this type of technique to operate and still provide type safety at runtime. Admittedly, I haven't tried to think through all the implications of that, but hey, that's what Stephen get paid for... -Scott

What error do you think it will come up with?

So I have to ask: Why did you ignore it when I posted similar examples using USER events (see previous posts)? Is it because you don't see the same issue with user event references? I can see why this is BAD for other references (queues, etc), but I'm really trying to dissect whether it is the same for user events. Unlike queues, where it was quite easy to get a child control that contained parent data, I am having more difficulty doing this with user events. When you have an array of class user event refs used in an event structre, the event data is of parent type, so I can't see in that scenario how you'd get parent data on a child wire or control. Maybe I'm missing it, but the attached image appears to be a valid operation and it does work properly. If you see other issues, I could use the clarification. I have other thoughts, but I'll hold them for now. -Scott Just answered my own question... I don't know if it's possible to get the "parent data on child" violation with a single event structure, but it's easily doable with two. Occurred to me right after my post.

It depends on how you wire it up. You can get a class conflict error on the parent event wire or you can get it to wire up correctly. It has to do with how you wire through the cases. If you wire the parent event through the FALSE case and the child event through TRUE, it will wire ok. If you do the opposite, you get a class conflict error on the parent event wire. I don't know what NI calls it, but I call it the master case rule. I don't know if my understanding is completely correct, but it seems that case structures (and probably others as well) have a "master" case that governs the type of a wire coming out of the case structure if other conversion/casting rules fail. The master case is normally the first one listed (FALSE, 0) when you drop the structure, but you can rearrange or relabel it after the fact. -Scott

Is LV2009 at all an option for you. Based on the image below, it seems to get you farther down the rocky path. It seems that it supports some level of polymorphism on class-based user events where 8.x doesn't. I was hoping AQ would shed some light on this based on his previous comment of never supporting polymorphism of user event wires. I can understand that comment when applied to types that are completely different (say string and int), but when the types are part of a class hierarchy and follow certain constraints, LV2009 appears to contradict his statement. -Scott