Aristos Queue

That's just plain old compiling. And that's what we call it. :-) The fact that you as user don't have to explicitly invoke it is a service on our part, but the compilation happens before you run, which is exactly when it happens in every other compiled programming language.

Daklu, the style of my writing below is fairly terse and occassionally EMPHATIC. I've done this to emphasize key points that I think you've missed in How Things Work. Some customers in the past have felt I'm insulting them writing this way, but it is the only way I know through the limited text medium to highlight the key points. My only other option is to post just the key bits and leave out a lot of the exposition, but that doesn't seem to be as helpful when communicating. So, please, don't think I'm calling you dumb or being disdainful. I'm trying to teach. The problem is that you're almost right. Customers who are completely off-base are easier to teach because they need the whole lesson. Here, I'm just trying to call out key points, but presenting them in their full context to make sure it's clear what fits where. Throughout the post, refer to the graphic at the end of the post as it may clarify what I'm talking about. Dalku wrote: No. If there is, that's a bug that needs to be reported to NI ASAP. Think about what you just asked for... ignore the DVR part for a moment. You just asked for a PARENT object to invoke a CHILD class method. That cannot ever happen. You cannot pass a parent object directly to a function that takes a child object. The parent object in question IS NOT a child -- the parent object does not have the child's private data, nor does it have all the methods that may have been defined on the child class. For this reason, LV will break the wire if you try to wire a parent wire to a child terminal -- the wire is broken because there are zero situations in which this can successfully execute. You CAN pass a child object to a parent terminal. That is because a child IS an instance of the parent -- it has all the necessary data and methods defined to act as a parent object. What you can do is take a child wire, up cast it to a parent wire and make a Parent DVR out of that. Alternatively, you could take a child wire, make a Child DVR wire, and then upcast that to a Parent DVR wire... these two processes produce the idenitical result: a parent DVR that contains child data. Upcast and downcast DO NOT create new objects EXCEPT when they return an error. The point of a cast is to say, "I have an existing object. Please check that it is this type and approve it to go downstream if it passes this test." You use this only when you need to do something for a specific type of object and you do not have the ability to edit the parent and child classes in order to add the appropriate dynamic dispatch VIs to both. Preserve Run-time Class (PRTC) is the same thing. "Allow this object to pass downstream if it passes this test, otherwise create a new object that does pass the test." The test in this case is "Does the object in have the same TYPE AT RUN TIME as the OBJECT (not the wire) on the target object input?" If the left object is the same or a child class of the center object then there is no error. You will ALMOST NEVER WIRE PRTC WITH A CONSTANT FOR THE CENTER TERMINAL. I would say "never" because I can't think of any useful cases, but maybe someone has something out there. If you are wiring the center terminal of PRTC with a constant, something is wrong in your code. You use the PRTC to assert that the left object, which comes from some mystical source, is the right type to fulfill run-time type requirements of dynamic dispatch VIs, automatic downcast static VIs, and the Lock/Unlock of Data Value References. In all three of these cases, there is some input (either the input FPTerm or the left side of the Inplace Elt Struct) that must be passed across to the output (either the output FPTerm or the right side of the Inplace Elt Struct) WITHOUT PASSING THROUGH ANY FUNCTION THAT CHANGES THE OBJECT'S TYPE. You're free to change the object's value, but not its type. Sometimes you pass the object to functions where LV cannot prove that the type is maintained. Easy example -- pass the object into a Global VI and then read the Global VI. You'd never do this, of course, but it demonstrates the problem. LV cannot know that the object you read from the global is the same object you wrote in -- some other VI elsewhere might have written to the global in parallel. But you, as the programmer, know that there are no other writes to the global VI, so you use the PRTC to assert "this is going to be the right object type." You wire the original input (as described above) to the center terminal, and the output of the global to the left terminal, and pass the result to the original output terminal (as described above). Does that make sense?

Good news! LV 2009 fixes the issue. LVClasses can now build all their files into the executable.

The Source Distribution is the most reliable option, definitely the one that NI designed to solve this problem.

Can you post an image of a couple of these sequences you're proposing? It would help to see in order to suggest data passing mechanisms.

Talk to Mikael... putting the DVR inside the class sounds an awful lot like the GOOP Toolkit implementation where they wrap a raw reference to data in a class to give it dispatching behaviors. Mikael may have some info about the deadlock potential of this situation.

> Dropping a Variant Collection object on a VI creates a Variant > Collection with a CollectionImp object instead of one of the > childclass objects. Go to Variant Collection.lvclass:Variant Collection.ctl. Change the default value (not the type, just the value) of the CollectionImp control to be an instance of one of the concrete types -- HashTable, for example. Now whenever you drop VariantCollection.lvclass, you get one that has a hashtable unless/until you change it to something else.

There are no plans to add this in a future version. It was explicitly rejected as a possible feature during brainstorming... I posted about this in the beta forums, and I *think* I updated the Decisions Behind The Design to talk about this. (If I didn't, remind me to update it soon.)

Replies to this topic should be made in the Idea Exchange where this was cross-posted. That way the evaluation of the idea can all be in one location.

The following was written on my whiteboard at my desk for most of the time we were developing LVOOP: El Voop == Spanish for strength! Le Voop == French for style! Al Voop == Arabic for quality! LVOOP == LabVIEW for class! And for the record, we didn't have any way of pronouncing "LVOOP-DVR" during development because DVRs are not specific to objects.

Please post all further comments on the forum for the idea itself... that way this conversation stays all in one place.

Here's another suggestion: Create a new state called "Update Indicators". Put all the indicator FPTerms in that state. Now instead of displaying the values in the state that generates the value, you wait to get to the Update Indicators state to update the indicators. Of course, this would require one of two things. Either: A) a queued state machine so that you could queue up the Update Indicators state followed by the next state that you really wanted to go to, o B) you make the next state to transition to another value in a shift register that the Update Indicators state can use.

*sigh* I wish we had heard about this during the beta program... the only feedback during the beta program was that this was a great feature and a major improvement to the usability of probes. We discussed a popup option on wires "Create Probe Inside Watch Window" and "Create Probe Outside Watch Window", and we decided that was loading up the popup menus too much. We talked about the multiple-select to pop probes out of the watch window, but the feature wasn't implemented because there didn't seem to be any desire for it from our users, so the developer spent time on other aspects. In his opening post, PJM_LabVIEW says he wants to see multiple probes at the same time. The text view in the Probe Watch Window does show you the value of the probe, and for all the use cases that we heard about, this was not only acceptable for that use case, it was preferred because it meant that all the probe values were lined up in a column where it was easy to monitor which value didn't match the other values in the list, instead of having probes scattered all over the screen. If the text portion of the default probe does not show you the information that you are most interested in, one workaround is to create a custom probe. There's a new output from custom probes, a string, that is the string that will be displayed in the text portion of the probe watch window. To the best of my knowledge, there is no undocumented config token to change the behavior of the probe watch window.

Mark Yedinak answered this part succintly in his post above regarding friendship and community scope. The class would not be broken if the XControl was missing. This is an editor only feature and we wouldn't want it to affect the run-time behavior of the class itself. This is merely an annotation on the class that says "when the user is creating a control/indicator of this class, if that ctrl/indicator is not on a member VI of this class nor of any subVI used by the class then the new control/indicator should be of this particular XControl instead of the cube." The intended use case is for this to be something that the designer of the class creates. Thus if I create the Timestamp.lvclass, I could go ahead and create Timestamp.xctl which implements the calendar FP control. That way when users of my class are working, they don't see a class, they see a native LV data type with all the bells and whistles that everyone expects from a LV built-in data type. Users of the class can already create an XControl for any given class that they want. What's missing is the hook into the LV editor for that XControl to be the default display for the class whenever LV needs to automatically create a display for the data. Currently LV uses the cube whenever it automatically creates one. I'm sure we would encode some way to explicitly drop the cube, but the use case this is intended to handle is one where such an option would rarely/never be desirable. Suppose I use "Create SubVI From Selection" to create a subVI with a timestamp input. Would you want an opaque cube to show up instead of the calendar display? Almost certainly not. LV users are used to being able to see the values of their data on the FP in every subVI. Is there runtime overhead associated with this? Only if the FP is loaded. As long as the FP is not loaded into memory* then the XControl doesn't get updates and its code never runs, so it doesn't get in the way of fast subVI execution. You suggest that for hiding large clusters, this might be useful. A) For a class where you're not interested in seeing the private data, don't create any default XControl. :-) or B) You can always create a small XControl that only displays a small portion of the relevant data, or is perhaps growable/shrinkable to crunch down to small form. * FP is not loaded as long as window not open, no open ctrl/vi refs, no use of local variables or statically bound property/invoke nodes. I agree. It should be as easy as "Create new child class. Create XControl for child class. Set the XControl as the default for the child class. Change nothing else about the child class." It now has the exact same behavior as the parent but with a new display. No, this is not related. The new plots all have LV built-in data types -- numerics, waveforms, arrays, etc. This is for creating displays for the class data types that users create. The new plots do use classes as part of their implementation, but their data type (the type of the FP terminal itself) is not a class type.A couple more notes: 1. There probably needs to be an option for "should this XControl be used when probing this class or should the generic probe continue to be used" 2. See VI Properties dialog, Editor Options page. This page allows you to set which type of control to create on the FP when doing Create Control or Create Indicator. This feature would probably need to allow users to set different XControls for modern, classic and system displays.

The new icon editor in LV2009 is written entirely in G and the VIs are shipped without password protection. There are many amendments and additions that the community might want to add. NI would like to collect that feedback and fold any innovations into the next version of the icon editor. The author and maintainer of the icon editor has created a new community on NI.com specifically for the icon editor. Any feedback you have about the editor should be posted there. http://decibel.ni.com/content/groups/enhanced-icon-editor-2009

The new icon editor in LV2009 is written entirely in G and the VIs are shipped without password protection. There are many amendments and additions that the community might want to add. NI would like to collect that feedback and fold any innovations into the next version of the icon editor. The author and maintainer of the icon editor has created a new community on NI.com specifically for the icon editor. Any feedback you have about the editor should be posted there. http://decibel.ni.com/content/groups/enhanced-icon-editor-2009

All of what Yair said is true, and one additional point: Within dataflow, LV's compiler knows that it can make certain optimizations. For example, if you do something inside a loop, LV can examine the operation and decide, "Hey! I only need to do this once... I'll just move that calculation outside the loop." But with a reference, that optimization cannot be done because the source of the data, the reference, *might* have been changed in some other diagram somewhere. So the data gets recalculated every time even though the result is actually going to be the same each time, but LV can't know that because the data is by reference. There are other compiler optimizations that LV can do for dataflow that it cannot do for references, and these will become substantially more common in the next two LV versions, and probably into the indefinite future.

The "Show Buffer Allocations" tool works for objects just as it does for any other LV data type. LV objects are a scalar data type, so enable the check box for "Scalar" and you'll be able to see where buffer allocations are created for your class wires.

In LV 2009... If you want to add customizations to the new VIs that are created by New>>VI For Override and New>>VI For Data Member Access, you can open and edit these three VIs. These VIs are called at the end of their respective scripting processes and you are free to include any scripting code you wish to further customize the VI in question. Some common customizations you might want include changing the VI name (use "get" and "set" instead of "read" and "write"), modifying the icon, adding additional diagram logic, etc. You cannot edit the callers of these three VIs, but these three provide the hook you need to customize your new VIs as you want them. Customizations for Override VIs: <labview>\resource\Framework\Providers\LVClassLibrary\NewAccessors\OverrideRetooler\Custom User Scripting For New Override VI.vi Customizations for basic accessor VIs: <labview>:\resource\Framework\Providers\LVClassLibrary\NewAccessors\BaseAccessorScripter\Custom User Scripting For New Simple Accessor VI.vi Customizations for 1D Array element accessor VIs: <labview>resource\Framework\Providers\LVClassLibrary\NewAccessors\ArrayElementScripter\Custom User Scripting For New Array Element Accessor VI.vi Customizations for multi-dim array element accessor VIs: <labview>\resource\Framework\Providers\LVClassLibrary\NewAccessors\MultiDimArrElemScripter\Custom User Scripting For New MultiDim Array Element Accessor VI.vi This is for the various LAVA folks who asked these scripting hooks be added.

Take a look at the Delegate pattern in the design patterns document. It's relevant to what you're asking.

Talk to Darren N. He's the one who felt these went with Quick Drop.

Unlimited by-ref has come. And that's the problem. :-) His program was not a case of LV having a bug, but rather he just coded something where Diagram Alpha was using a reference and Diagram Beta tried to acquire that reference, and was waiting, and, meanwhile, Alpha was waiting on Beta before Alpha would release the reference. And his program sat and waited on itself.

This is my attempt to depress, suppress and restrain the excitement running through the community regarding Data Value References in LabVIEW 2009. Yes, they are cool. Yes, they are powerful. Yes, they solve problems real programming problems. Yes, you should occasionally use them. No, they are not a silver bullet. But please, for the love of LabVIEW, don't go overboard. They are references. They are not dataflow. You can kill an app's performance by needlessly using references of any kind -- queues, file i/o, GOOP, and, yes, DVRs. Think before you use the references. Ask yourself if you need the references. Even if you think you do, try to not use them first. I have seen more than one user app where a knee-jerk reaction to wrap *everything* in a single-element queue and passing references around kills performance. We have developed DVRs to be as parallel-safe as possible, but there are still hangs that can occur if you use them in some ways -- Jim Kring found one just last week, and thought he was looking at a bug in LabVIEW, but it wasn't. When you use references, you open up a whole new world of race conditions, recursive deadlock, and on and on. Let the LabVIEW community celebrate the new Data Value References. But, please, celebrate calmly.

I don't understand the math entirely either, but I'm confident it is correct if only because two math nerds explained it to me twice. I actually understood it for a brief moment after the second explanation, but then I forgot.

If the VI didn't know about the library: Scope enforcement would not exist. A VI is broken unless its library is loaded... this is because LV assumes that if the library is missing, you're trying to access a VI that is marked as private by the library. Loading a VI needs to load its library so that it is *always* namespaced. Otherwise loading a large VI hierarchy would suddenly fail unless you loaded all the necessary libraries first because you would have a bunch of VIs with all the same file name colliding with each other. Classes, XControls and StateCharts -- all of which are libraries -- would not work. Licensing restrictions from NI would not work That's it. ;-)