Aristos Queue

You are about to scowl at me just as much as Paul did (I forget his username on LAVA -- he's the Paul who works on all the astronomy stuff) when I gave him the following answer when he was talking about customizing the XML flattened format...The answer is that as soon as you cross the line where the contents of the string are not enough to know which class should unflatten it, you have to write your own UnflattenFromString function from scratch. You might use our UnflattenFromString internally, but there's no way for LV to magically choose which class should unflatten the data if you want a class other than the one named to do the work of unflattening. Even if LV gave you the ability to add class specific code to the unflatten sequence, the class that would be invoked would be the class named in the flattened data, and that's exactly the class that no longer exists in your scenario. The only way this might work is if the class of the old name were still loaded into memory and had in its mutation history instructions that said, "When I am asked to unflatten, I actually unflatten data of this entirely other class over there..." Then you get into some really messy cross link scenarios where the mutation history has to have a path to the other class even though nothing in the class' current version references that other class at all, you have to keep old classes around long after they should be gone, etc. I've delved into allowing classes to have custom hooks to flatten and unflatten data, but none of the variations that I've played with would solve the rename problem. For that, you have to write your own. The easiest is a subVI that takes in a string, does a find-and-replace to substitute the old name for the new name and then calls the unflatten primitive with the modified string. That's a fairly expensive operation, and it's pretty heavy when you don't know if it is needed or not (i.e., you're reading a string that was written out after the name change, but you still have to do the find and replace just in case). It is error prone if there happens to be an actual string value embedded in the flat data that is the name of the old class but means something else entirely. Magical mutation is a major time savings. But once you break the spell, you're back to writing the full parse-and-mutate-if-needed code that programmers must write in other languages.

COTS for SOUP... I guess that makes sense... food can frequently be substituted for sleep.

Chris: What is "COTS"?

Ah, a non-believer. A real Greek knows his liver is still being eaten. :-)

VPM is so good that NI is looking into using it for a couple of its own toolkits (we may already be doing so, I'm not sure, but I know it was being investigated).

If you do this, you end up with not allowing a class to load into memory because it has the same GUID as another class because having two classes in memory with the same GUID means you cannot unflatten any data because it is ambiguous which class the data represents. The name saved with the data -- what I'll call the data name of the class -- has to be constant from the time the data is flattened to the time it is unflattened. Either that data name is tied to the file name (so that there is an easy and obvious way to control what that name is and to explain why two classes conflict with each other when the data names match) or it is its own independent entity (so that you can change it without changing the name of the class).

Yeah, and as soon as we implemented that, even more people would be complaining that when you change the name of a class that the file *doesn't* get renamed. I say this based on the screams and complaints that the project originally generated when renaming a virtual folder did not rename the folder on disk and moving a VI from one folder to another didn't move the file on disk. But beyond my wild speculation about the preferences of LV users, there's a very big usability problem with the GUID solution... file copying. How do you resolve the problem of File >> Save As? When a user does Save As, are they making a backup copy (where you'd want to preserve the GUID exactly) or are they forking a copy (where they'd want a new GUID)? When they have to recreate a missing class, how does a user fill in the GUID? Ok, you upgrade this to be a user defined name instead of a GUID. Great... now you have the same problem with misspelling the name that you had before making you want to change it. So that solves nothing. And further, now when you create a class you are prompted for the name of the class and the file name for the class. I'd actually recommend making them *not* match, otherwise you're going to get burned in the rare cases when they don't match -- I know this because it is exactly what happens to me right now in MS Visual Studio where the name of the class and the name of the file start off the same but someone may change the internal class name without renaming the file (generally because they don't want to mess up the source code control change tracking). LabVIEW made the opposite choice, and what we gain in clarity of file contents and findability, we lose in data preservation and source code control. Which is better? The debate about name handling in computer environments is endless. I have joked before that management of names is the primary job of a computer scientist. We, as code poets, must give to airy nothing a local memory address and a name. And my studies of mythology and history have taught me that renaming a thing is not done lightly nor without consequence. In the end, we picked a paradigm that seemed like it would work for most situations. It has its pros and its cons. If you *really* want a solution, do this: Save every individual .lvclass file inside its own .llb. That gives you the ability to rename the file on disk without changing the class name. It won't help the data unflatten case because that's the data name and any layer of indirection there leads to the GUID problems, but it will help with the source code control name change problem. But I promise you, you'll be ticked off by it, just like I am in MSVS, just as soon as the file name stops matching the contained class name. Trust me. The presentation is now available. http://zone.ni.com/wv/app/doc/p/id/wv-2003

Alternatively, you could leave AutoGrow on and stop hiding stuff under the edges of your loops. (Joking, of course. Although I love the feature, I'm aware that not everyone does.)

I thought Get Tag was polymorphic and if you didn't wire the Name input it would return all the tags on an object. I may be wrong about that, but I remember seeing something like that somewhere a couple years ago.

Yes, this is exactly what you would have to do. That's the only mechanism that exists.

Yes, it sounds like you have the right of it. 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. This also has ramifications for people who use the Application Builder options to add a prefix to their files as part of the build. You should stop using that option if you want data versioning of class data to work from one version of your distribution to the next. Otherwise every distribution you produce is version zero because the class is just brand new renamed. The presentation isn't posted yet. When it is, it'll be linked from here: http://decibel.ni.com/content/docs/DOC-8462

It matters what the "Open" function looks like. Again, with DVRs and classes, the Open function is also a subVI, and, in line with what mje writes, I would expect that Open.VI and Close.VI would both be called in the same scope. Thus I wouldn't see it as an exception to "close what you open in the same scope" so much as "parallel operations should have equal depth" --- if your close is in a subVI, your open should be as well, and all the work done in that open should be undone in that close.

I've seen it in cases where the subVI itself was named "Close", but there was some other work to be done along the way. It should actually be common when using DVRs with classes since the only way you *can* close the reference is in a subVI if the class options are set to restrict it (which they are by default).

You'll have more replies if you post who you are, where in the world you are located, how to contact you privately and how much the job pays.

It's been that way for 25+ years. I doubt that anything substantially altering that situation is likely anytime soon. I actually find the experience fairly straightforward when I compare it to 4000 lines in a .cpp file that I'm scrolling up and down through. Even in C# where files tend to be on the order of 100 lines, the windowing situation gets pretty bad. At least with LV you can observe from the probes behavior at deep levels of the program instead of having to actually be watching those levels real time to see watch window results. That, by the way, is the number one reason to not use data value references. Yes, they're bright and shiny and new in LV 2009 and a bijillion users have thanked us for adding them to the language, but I continue to argue that the vast majority of the time the same work can be achieved with dataflow and doing so would avoid the deadlocks and race conditions that too often crop up. Yes, there are rare situations where you really do need a DVR, but its way less common than most people seem to believe. Perhaps having spent two days searching for the deadlock, you'll now spend a couple days thinking about whether it is possible to architect your code without any DVRs to avoid this in the future. I'm not saying it is necessarily possible in your case, but I believe it is worth thinking about.

Only the DVR needs it. All the other IPE border nodes are accessing data on the local wire -- there's nothing shared with other processes that needs locking.

*phew*

It's hard to answer such a general question. The folks on this forum are pretty good with more specific questions. Post any VIs you've already got written and maybe we can help debug a particular issue.

I'm not sure I understand the goal. Given that you (like myself) use the project as a palette, what would you put in this project-specific palette? If it is anything autogenerated, wouldn't it just be the project, and thus would get as large as the project window already is?

Ok... so based on your very light description of the bug, I asked another developer to inspect a particular table for a particular set of bits... and, lo, a bug was seen and will be fixed. Please confirm that the attached VI replicates your bug. get_variant_attribute_unwired_default_test.vi

We have a sizable number of customers for whom the Event Structure is a non-entity. If your primary use of LabVIEW is a single For Loop with a set of nodes to continuously pull data from some hardware source and then display that data on a Graph or Chart, you just don't need the full force of a programming language. That's a pretty common LV user, and Base is for them.

Those of you making August plans for NI Week may be interested to know that the light rail commuter line actually opened this week in Austin, and one of the train stops is next to the Convention Center where NI Week is held. That may open up possibilities for visiting sections of Austin that you haven't explored in previous years without renting a car. Unfortunately, the line doesn't run out to the airport, so you'll still need a shuttle to get downtown in the first place.

I do not know much about SciWare's GOOP, but any refnum or resource (like a task) that is created in LabVIEW is automatically disposed when the *top-level* VI that created it goes idle. Is it possible that you are creating the DAQ task in some VI that is being called using the Run VI method of VI Server, and that VI is going idle and thus throwing out the newly created task?

No. A terminal whose type is a typedef does not get the typedef's default value as its default value. So if you have a typedef of an Int32 whose default value is 5 and you put that inside a For Loop and tell it to execute zero times, the value you'll get out is 0, not 5. Typedefs define a type, but they do not define all the behaviors of that type. The default value set on the FP of the control editor is just the default value of any controls of the typedef. If you need a type where the default value is actually defined as part of the type, you need a LabVIEW class. Yes. And that one pointer would point back to the master copy of the class' default value.

WOO HOO! Dear chcastro: You have no idea how happy it makes some of us on this board to hear a student who actually *wants* to do his/her own homework. We get a lot of requests asking for someone to write assignments for students.