Aristos Queue

QUOTE(bbean @ Dec 12 2007, 02:55 PM) In LV8.5, use the Inplace Element Structure with the Index Element option.

QUOTE(Paul_at_Lowell @ Dec 12 2007, 07:18 PM) What's the CAR for the open issue? I can look at the source code there.

QUOTE(Guillaume Lessard @ Dec 12 2007, 06:59 PM) Curiously enough, no one has ever made this suggestion before. It's a good idea. QUOTE (In a related gripe, creating and editing the mnu file for a class pop-up palette is also too circuitous). I can't help with this one. I don't get involved in palette editing. The palettes are the single most commented upon aspect of LV. Everyone has an opinion about how they should work that is 100% unique from all other LV developers, and almost everyone is pissy that their idea isn't taken as "well duh". I get involved in palette UI only under extreme duress.

QUOTE(Paul_at_Lowell @ Dec 12 2007, 06:33 PM) You should still be able to remove them. Post your VIs if you can and let's see if anyone else can replicate. I tried removing a dynamic dispatch member that was in a parent class with an overriding child, and it worked just fine. http://lavag.org/old_files/monthly_12_2007/post-5877-1197507260.png' target="_blank">

QUOTE(gmart @ Dec 12 2007, 03:06 PM) This is no different than if you copy any subVI -- the clipboard will hold the VI in memory.

QUOTE(Paul_at_Lowell @ Dec 12 2007, 01:42 PM) A class will stay in memory as long as there are any data instances of the class lingering around on VIs that aren't members of the class. That means hiding in the operate data of controls/indicators (controls of type LabVIEW Object or LVVariant are common hiding places), or even just sitting in terminals. The inability to close the .ctl window is a new one. I haven't heard of that before. If you can get it reproducible, please post it to ni.com so it gets investigated and CAR'd.

QUOTE(Guillaume Lessard @ Dec 12 2007, 01:36 PM) The generic probe for an LVClass does show the data as a cluster. To create a custom probe for a class, just popup on any class wire and create a new probe using the probe wizard, same as you would for any data type. You may want to add the new VI to the class if you want to directly access the private data in the probe. What aspect would you want simplified? (Note: I'm not disagreeing with you that it could be simpler. I'm asking what specific tools you're looking for.)

The one that has a buffer allocation is an element of the array. The one that does not have a buffer allocation is a subarray. A subarray is a reference back to the original array and does not require any data copying. An element is an independent item and gets copied out of the array. If the output of the first Index Array was an array data type, we could have a subarray of a single element, but it isn't an array output -- it is an element.

QUOTE(shoneill @ Dec 12 2007, 05:17 AM) No, it is not only not possible, it is explicitly worked against (The reasons have been discussed elsewhere in the forums; look for posts from Jason Dunham). All paths to setting the value of an object are through the object's programmatic interface; you cannot construct an object by any means other than running a VI. This comes close to guaranteeing that all values of the class conform to limitations imposed by the class' API and no internally inconsistent objects exist. (The one path to an inconsistent object is to create an object, make it the default value of a constant, and then edit the VIs so that the constant value is no longer one that could've been validly created. There's nothing I can do about that case.) PS: Please use the term "object" for an instance of a class. Your posts above talked about having to create a new class, and that really confused me. You create a new class once, and then you create objects of that class type. It'll make the conversation clearer for all of us.

QUOTE(george seifert @ Dec 11 2007, 03:06 PM) The warning letter is about the *driver CD*, not LV. The LV on those CDs is exactly the same LabVIEW that was on the August CD -- we haven't released any LV patches/versions since then.

QUOTE(TG @ Dec 10 2007, 10:17 PM) Try cooking the spaghetti longer... :ninja:

I found it fairly boring. Does it ever get more interesting than just putting weights on the scales? Click-hold-to-size-release --- if we slowed down the growth of the ball, the game would be trivial. The challenge of visually guaging the size of the ball and releasing at a particular time isn't exciting, to me anyway. Michael, what makes this particular game worth posting instead of the many other physics model games?

QUOTE(hfettig @ Dec 11 2007, 10:39 AM) Um... backwards. The dialog to ask "do you want to apply lib icon to members" was new in 8.5. It wasn't there in 8.2.

On the front panel, it means the control/indicator has a default value different than the class' default default value. On the block diagram, it means the class constant has a value different than the class' default default value.

I strongly suggest that you not push this... because the fix is likely to be preventing instance VIs from being referenced through VI references entirely -- given that the design was that these VIs are purely behind the scenes and are designed to have only one caller, it is a bug that they're in the foreground at all. You mentioned only expecting stuff to work that is actually documented. Instance VIs aren't documented at all.

Thank you, Michael.

QUOTE(Tomi Maila @ Dec 9 2007, 04:01 AM) Your logic would hold except for one bad assumption -- you're assuming that instance VIs are like any other VI. But instance VIs aren't regular VIs and were never designed with your use case in mind. They cannot exist without the calling node, and if you strip the calling node during app building then the instance VI goes away. These VIs make a lot of assumptions -- notably that the only caller they ever have is the owner VI. You mess with this assumption at your peril, but it can be done.QUOTE(tcplomp @ Dec 9 2007, 04:18 AM) Reentrancy? Actually, Reentrancy might be the solution, but for a different reason. If the instance VI itself was made reentrant, then you could open a VI Server reference to that instance VI and have a clone of the VI, so even if the subVI was reserved for direct invocation in a case structure (as opposed to a comment node) then you'd still be able to run it independently, I think.

QUOTE(Jim Kring @ Dec 9 2007, 03:13 PM) Successful invocation of Freud grants victory (just as invocation of Hitler causes automatic loss). So for the moment I'll grant Functional Globals status as OO tools, subject to review of decision one year from now. Nevertheless, GOOP is an inaccurate name for the forum since GOOP is a specific type of technology (whether it was intended that way or not originally, it is now).

QUOTE(Jim Kring @ Dec 8 2007, 12:38 PM) GAH. They should certainly be one of the first data storage techniques that one learns in LV. But although I suppose they are a form of functionality encapsulation on a piece of data, I wouldn't ever have classified them as "object oriented", especially since the need to code every operation that you want to do on the given (string, number, your-favorite-datatype) is seen as a limitation of such VIs, not a strength. Your views are warped by your history, my friend. The only tools a caveman has are rocks and sticks, and perhaps he uses one to pound and the other to poke, but let's not equate them to a hammer and nail.

QUOTE(Tomi Maila @ Dec 8 2007, 04:18 PM) It's not a mistake to exclude the instance VI... you commented out the Express VI node, thus app builder would assume that the instance VI would never be callable. Try using a case structure with constant FALSE instead (use a control, not a block diagram constant or LV may again get too smart for you). Again, just a guess.

QUOTE(Jim Kring @ Dec 7 2007, 11:23 PM) "Functional Globals" --- what the??? Where did this one come from? At any rate, I conceed OOP or spelling out the acronym would be better generally. I think given the confluence of the various forms of OOP that while subforums might be useful, there'd be an awful lot of top-level posts. So I'm abvivalent about whether or not subforums exist.

QUOTE(Jim Kring @ Dec 7 2007, 08:17 PM) OOP would be ok naming wise, but it wouldn't help with folks who search for "LVOOP" or for disentangling the names.

The forum is currently named GOOP. There's an awful lot of posts there about LVOOP. The new GOOP Toolkit blurs the line between these two, but there's still a difference. Can this forum please be renamed to be "GOOP/LVOOP" ?

That's a good suggestion. I also use the "labels on constants by default" option.

QUOTE(crelf @ Dec 6 2007, 01:27 PM) He kept generating CARs at such a rate that I started thinking, "You know, in the video game Gauntlet, the trick to killing the monsters is to go after the monster generator first..." Seriously, though, the rest of you are now cleared to work on projects up to 4499 VIs in size as he has cleared the way for you.