Aristos Queue

QUOTE (PJM_labview @ Mar 17 2008, 08:05 PM) No such document exists. No one has asked for it until now. But I can summarize it pretty easily: If the property/method would cause a change that would be saved with the VI, that operation is not allowed on a clone. No "make current value default", change control to indicator, changing labels/captions, etc. They're called "reentrant clones" for a reason, and I don't think you've been led astray. Again, if you don't want clones, use .vit files. File a documentation bug report if you want this documented in a future LV version. It won't be an easy thing to document -- there's no line item for that in the configuration of new properties and methods, so someone would have to run each individual property/method and determine whether or not it worked on a clone. That's pretty tedious work that probably wouldn't get a lot of priority.

It is not a bug. The reentrant clones are able to support their own panels/diagrams without significant loss of performance because they share large quantities of properties with the master. If you want to start with one VI and do such edits as changing tip strips, start with a VI Template and instantiate from that. Template instances are independent of the original .vit.

QUOTE (eaolson @ Mar 14 2008, 10:15 AM) No, it would not. You don't need a dynamic output to override. Only a dynamic input.

QUOTE (Jim Kring @ Mar 14 2008, 10:46 AM) The only class I've put in the palettes myself is LabVIEW Object, which is built in and so the draw code knows how to draw it. The red/black pattern is just the random pen that happens to get selected when nothing has been specified, drawn at 8 pixels wide, which is the "hey, notice me, there's a problem" width when nothing is specified. ;-)

QUOTE (normandinf @ Mar 14 2008, 09:13 AM) I believe the solution in your situation is a) Make the output terminal be of the Parent class type and b) do not make that output terminal "dynamic dispatch output". The dynamic dispatch input must preserve data type from input to output, and so must be the same class as the input. But a regular output is free to output any value of the output type, which, since the output will be some type of Parent, can be any child type you want to change to. Is this what you're looking for?

Tomi! Jim! I feel like you let me down! Here it is, 19 months after the release of LabVIEW classes, and only now someone tries to put a LabVIEW class into the palettes? Don't worry too much -- I'm kicking myself just as much for not noticing this one. The following bug exists in LV8.2 and 8.5. If you add a VI to the palettes that uses any LabVIEW class other than "LabVIEW Object", the Context Help for that VI, when you hover over it in the palettes, draws a funky 8-pixel wide red and black wire, as shown here:

Investigate XControls. You could easily implement at "f(x)" XControl, which always displays the results of f(x), where x is the current value of the control. You could add a property to the XControl to give it a VI Ref that is the formula f. Then you would just wire the numeric control directly to the numeric indicator. Complete modularization of display from value.

QUOTE (Yen @ Mar 12 2008, 02:01 PM) I assume you mean by left clicking. I actually didn't know about that route until recently -- and right click is easy to do. But I can do the left click, though I definitely understand what you mean about it being tricky. Basically, just aim for the left side of the symbol and it works. And it does seem like a control key modification would be useful in this case to expand the region that the left click works. QUOTE (Yen @ Mar 12 2008, 02:01 PM) I never use it. What do you need it for? See my post above.

It's not a bug. No, I don't actually believe that. But I felt I should say it so that you could win your bet. I like supporting open source software efforts.

QUOTE (jdunham @ Mar 11 2008, 12:17 PM) I code on my laptop with the touch pad and have zero issues with it. Except for boolean buttons on the front panel, I'm even to the point of rarely using the control key.

QUOTE (neB @ Mar 12 2008, 06:36 AM) Or, in one of my favorite Star Trek quotes: "[The universe] is wonderous -- with treasures to satisfy desires both subtle and gross -- but it is not for the timid."

No reason to stay away from variants any more than a reason to stay away from strings, arrays and paths (ie they're not flat data types and can require memory to reallocate depending upon how you use them, thus blowing away real-time determinism). What in particular are you worried about?

QUOTE(BrokenArrow @ Mar 10 2008, 05:55 PM) Yep. LV cleans up all the refnums that LV opens when the VI that opened them goes idle. For the vast majority of programmers, that's enough. But some apps do lots of opens/close in tight loops that run for days/months/years, and others do open-modify-unload and they need the unload to work, so it is important that the refs all be closed. For those 10% of users, knowing when to close is important.

QUOTE(neB @ Mar 10 2008, 12:16 PM) http://lavag.org/old_files/monthly_03_2008/post-5877-1205191680.png' target="_blank">

90% of loving the autotool is knowing this one little known fact: If you don't like the tool you've got, holding down the Control key gives you "the second most useful tool". Armed with that little tidbit, virtually every customer I've ever visited who was unhappy with the autotool has come to like it.

My comments are in the image.

QUOTE(Tomi Maila @ Mar 10 2008, 02:39 AM) I still have not been able to get it working.

The post is not as far fetched as it might seem (though, yes, it is a stupid post seeing as how there's no answerable question actually asked). I have a friend who used to be a programmer for the "Sexbox 360", a hardware and software extension for the XBox 360 which allowed for remote interaction between players, considered a revolution in the field of "teledildonics" -- I'll let you parse the prefixes and suffixes of that one. They were considering using LabVIEW for their hardware testing. My friend moved to a new company before they made a call about LV.

QUOTE(Daklu @ Mar 7 2008, 05:03 PM) You only close a reference once no matter how many times it branches or where you send it. Once it is closed, it is closed for all branches. That's the nature of references -- the reference points to the same object and it is only the ref number that is duplicated when a wire branches. This is its power and its curse. In LabVIEW the only time when one section of the code can affect other sections of the code is when references get involved. So if you do close the reference in one branch, or in a subVI, the reference is no longer valid in any other section of the code, and if that other section of code was still supposed to be using the reference, that other section will start returning errors.

It's being worked on. It's more than a bit frustrating just how hard this problem has turned out to be. It seemed like such a simple little feature when originally proposed. *sigh* In the short term, all I can offer is the ability to define a custom .mnu file that will appear when you right click on a class wire. So if you build a type that you use commonly or are creating as a deployable API, you can build the menu that you're asking for. But an on-the-fly sort of thing is not likely any time soon. On the flip side, the project works so well as an always-pinned palette (assuming you have the screen real estate for this) that it may not be that important a feature as the project window continues to improve its behavior.

Please post a picture of your block diagram. It is always easier to give advice in these situations if we can see the code.

QUOTE(Omar Mussa @ Mar 5 2008, 06:01 PM) Conditional disable structures do change build dependencies. Any commented out subVI will not be included assuming there are no other references to those subVIs elsewhere. Unfortunately, in the case of LVClasses, the class itself is a reference to all of its member VIs. When a class is built into a built app, the entire class gets built in, even if all of the methods are not necessarily invoked. That's the behavior because of the very common pattern of dynamically loading classes into memory, classes that might use methods of the parent that aren't otherwise invoked, and they'll expect those VIs to be there. If you don't want certain member VIs to load into memory, you're going to need to remove those VIs from the class in some fashion. The easiest method I can suggest is to have a member VI that loads the desired VI into memory and returns a VI Refnum. You override that loader VI in each class and have it load the functionality particular to that class. There are other methods more creative, but that's the easy one to point to.

QUOTE(jaegen @ Mar 5 2008, 05:00 PM) No. It shows you one possible order. Remember that the order that parallel nodes execute in can be different every time that section of code executes. There are parallel threads *within* the VI and those threads go in whatever order they want to proceed.

Remove the unused child class from your project tree. If it is really unreferenced, it won't load into memory. You can dynamically load the class into memory if you discover that you need that piece of hardware. This is *exactly* the behavior of the Getting Started Window in LV8.5. There's an indepth discussion of this method of programming at the Eyes on VIs blog ( http://eyesonvis.blogspot.com/2006/08/obje...ted-window.html and the next few posts to that blog).

QUOTE(neB @ Feb 29 2008, 01:54 PM) Only a probability, not a certainty. The first dropped node is on the node list first, so whenever the LV compiler doesn't care about the order, that one will tend to go first. But... a) If you have a multi-core machine, this is substantially less likely to occur because the first node may go to one processor and the second node may go to the second processor and it depends on which processor gets around to handling the node first. That's OS and hardware dependent. b) The LV compiler may care about the order and explicitly schedule them in reverse. c) Turning on execution highlighting tends to smooth out parallelism so that things are easier to watch. Using single stepping obviously forces serialization of node execution even when the nodes would normally be parallel. QUOTE(PaulG. @ Feb 29 2008, 10:25 AM) Some of us seem to have forgotten the (unwritten) First Rule of NI Tests and Certifications: The "correct" answer is not necessarily the answer you think is right, but the answer NI wants to hear. And, as a result of this conversation, there's now a discussion internally about what answer we want to hear. The wording of this question may get some adjustment. :-)