Aristos Queue

The best way I can suggest is to contact NI tech support and arrange for us to look at your code under secure conditions (possibly even rising to the level of signing an NDA).

The sorts of problems you're describing are the deepest dread of compiler writers -- they might be user error, they might be our fault, neither you nor we can tell at the moment, and the longer it goes on, the more it will undercut your confidence in our language. That's bad for both of us -- you eventually will rewrite using some other tool and we lose a customer. Please take the effort to contact NI (though this being Labor Day Weekend, I'm honestly not sure what our staffing is like at the moment).

If you're using Source Code Control, commit your changes regularly so we can see the different evolutions of the code. If you're not using SCC, zip your VIs up regularly and name the files with timestamps.

I can't think of a time since school that I've had to do something like that. There's some lookup optimizations for hash tables, but that's it. Usually, if I'm worried about string length its with respect to graphics space or string parsing, not comparison.

The following is NOT my area of expertise. I am raising something that is possibly FUD -- it's something I've heard about that you should research further before deciding the "move to vi.lib" question.

I would be concerned about future versions of Windows. Vista and Winy both ratcheted up security for applications, and they encourage app authors to go well beyond the requirements. You can find Microsoft's current recommendations here: http://msdn.microsoft.com/en-us/library/aa368769%28v=vs.85%29.aspx

But they keep moving up, and finding that these are requirements one day soon isn't unreasonable. I can easily imagine Windows requiring that any app that modifies a directory created by an installer must itself be signed by the same original authority. That would mean OpenG's installer wouldn't be able to write to vi.lib unless NI signed the installer. Probably not desirable.

Now, on the flip side, NI might decide to move vi.lib out of Program Files under such a scenario. There's lots of possibilities here. So, it's not necessarily a showstopper, but I'd suggest you investigate MS' Windows 8 plans before deciding this issue.

You could use the "Get VI Dependencies" method on a VI Refnum for your top-level VI and set the Recursive parameter to true... it returns an array of paths... just take all the ones that are under vi.lib.

That's the same size as previous versions. Hasn't changed since 7.1, I believe.

If you contact NI tech support, we often have to investigate bugs in proprietary code. The Application Engineers (AEs) have various ways of handling this, from simple verbal agreement that we'll delete your code after we're done investigating and guarantee that the bare number of people actually look at it all the way up to full NDA agreements and AEs coming out to look at your code on site. If you can't figure out which function on your diagram is causing the "quick exit", that approach may help you.

It is?

What I have is an "Observer Registry" (mentioned in my "Parallel Process" topic) that deals with "Message" objects published by one process, to which other processes can register for. I would like the other processes to be able to specify what specific types of messages they would like to be notified of. For example, Process A may be interested in all "CommandMessages", a child class of Message, and any children of CommandMessage. This could be done by Process A passing a default CommandMessage object to the Observer Register, and then having the Register check every Message published to see if it is a child of CommandMessage. The Register would then be dealing with two children of Message (on Message-type wires) and needs to see if one is the child of the other.

Ok, when you put it that way, it sounds perfectly reasonable, but I have never needed that functionality in any other programming language, despite having written several systems of similar nature. I haven't needed it in LabVIEW either, but I haven't tried in LabVIEW to write the kind of dynamic registration system that you are attempting. I couldn't come up with a quick reason why I haven't needed it. I thought, "Well, maybe *I* haven't needed it, but it'll turn up in code by others," but in a brief search this morning I can't find any examples of typical programs that do this in other languages.

Curiouser and curiouser, thought Alice.

In any case, the Preserve Run-Time Class would (if you had a later LV version) do what you're looking for, and the only disadvantage I can see is that the other process has to register for a subtree of message types (as opposed to some more arbitrary filter mechanism). It will be faster than anything you can do involving Library refnums (most things are faster if you can do them without Library refnums).

I can't really come up with a way to do this in LV 8.6 short of you adding a new method to your class hierarchy for "Is X a child of me?" and a second method for "get class name", which each class overrides correctly.

Imagine I have a class tree with parent, children, grandchildren, etc. How do I take two objects in on parent wires and tell if one object is a child of the other?

This is actually something that you should pretty much never have to do. Although the Preserve Run-Time Class function will do what you're asking, the PRTC was put in so you could reasonably make *assertions* that two objects are the exact same class, not for runtime testing. What code are you writing where you need this type of functionality? It's a highly unusual request.

I'd put an icon in there that said "This space intentionally left blank", except the text won't fit in the space and the Localization group would yell at me for text in an icon. Any suggestions for something better than the "?" ?

Hey, asbo, since you reported that TestStand crashes, would you mind reposting this onto ni.com/forums so that an AE can investigate and CAR the crash? (unless upgrading to 4.2.1 fixes the crash, of course)

You're not going to like my solution... it's icky, and I wish there was a better solution, but I've used this and it works:

In your class, store a NON-strict VI reference. When you want to use the reference, use a property node to get the VI Name property and wire that to an Open VI Reference node, then take the output of that and use it for your Asynch Call By Ref and your subpanel. You can make this a bit more performant by storing a string alongside the VI reference that is the fully qualified name of the referenced VI so you don't have to use the property node every time.

Nope... almost never in fact. I'm not constructing a parent object, I'm constructing a child object, so calling a parent constructor seems out of place to me and makes the code more confusing (IMO.) The child constructor may or may not (often not) have the same creation requirements on the parent class data fields.

Daklu: Your opinion is probably shared by most LV users who haven't worked in other languages because LV doesn't have constructors with parameters. If it did, you would probably find yourself wanting to reuse your parent's constructors about as often as you want to use the Call Parent Node in any other method.

Glad I could help. :-)

OK... so at the end of all this... is the behavior now what everyone would call "correct"?

If yes, does it match the documentation?

If no, what still needs tweaking?

Does anyone know why it is not an option to prevent a class object from being dropped on a block diagram?

Because it wouldn't solve anything.

Instead of a constant, a user might drop a control. The data may come from an Unflatten From String instantiating the default value of the class. There's not really a good way to bottleneck and say "always call this constructor here". Worse, LV data is live from the moment a control is dropped to be copied/pasted around to controls and constants, which means any constructor function would need to be invoked as soon as the control drops on a panel. But the problem is that you might be editing the class right then... there's no guarantee that such a constructor is runnable at any given moment.

Originally, I had this idea that we could run the "default value constructor.vi" when the class gets reserved for running, since there's only one copy of the default value and we could update it once. That idea fell apart because RT needs an independent copy of the default value for every allocation. That left me with the idea of flagging every memory allocation that hasn't yet been properly constructed yet and run it on those memory locations whenever the class gets reserved. That option seems viable, although I am worried about the "I just edited the default value constructor VI, now LV needs to update all the memory locations to the new value" problem. Probably not an issue, but I haven't spent any time working on the default constructor issue in the last couple years... the times when someone has asked for this feature has been very rare compared to other requests. It's really not been a priority to find a solution.

Don't bother learning about "friends" yet. It's not hard to understand, but you shouldn't need it in most applications. Because it's a very rarely needed feature, while you're still learning, I'd push that topic off for a while.

Here... start with this 1 hour presentation that will get you all the basics:

http://zone.ni.com/wv/app/doc/p/id/wv-1766

Then you can look at the "Additional Resources" section of the LVOOP FAQ for more tutorials, white papers, Powerpoint walkthroughs and other learning materials to fit your learning style:

http://zone.ni.com/devzone/cda/tut/p/id/3573

By fixed, we mean the symbols showing up incorrectly. The X will still show up sometimes for correct reasons.

The X means that you do not have the license file so this VI will be broken.

I *think* it can also show up in right-click palettes when the VI you clicked on does not have access scope privileges to use the VI in the palettes. So if there's a private scope subVI in your palettes, you'll see the X when you pop up on a VI that is outside the library that owns that subVI. I say "think" because the feature was proposed that way, but I haven't kept up to know if it actually was implemented.

I can't explain why mje is still seeing a problem. Can someone post this on the ni.com forums so an AE can dig into it?

I guess someone found it easier at the time to just put them unnoticed into the Utility directory, and they've never migrated to a more useful place.

More often, those were put in to support some VI in the palettes or were put in to support LV functionality itself and they aren't intended to ever go into the palettes because they've not been tested for general use and, as noted in the long post, might be significantly refactored if we have other needs. There are very few that were put in by folks like Darren or myself as "backdoor LV functionality." Darren continues to add these. I've essentially stopped unless they're going in the palettes and put the VIs up someplace in the forums.

We definitely didn't want passing the CLA-R to require course work. We wanted the course work to be available for those who hadn't necessarily kept pushing their LV skills with each version so they could catch up. And we tried to have questions on newer LV features be few enough that you could still pass, with the intention of those becoming more dominant as time goes by, so that there's pressure but not requirement to keep updating LV skills over the years.

What I'm hearing from this thread is that we got very close to the exam we wanted but not quite right. But we got closer than might be expected... it is, as you said, very hard to write a multiple choice exam that actually tests advanced architecture concepts.

Mr_Jim, do keep us posted about your discussion with the certification engineers.

PS: I'm going to have to go through recert myself later this year, so I'm very keen on this being a good test. :-)

As a result of the great "Config VI Refactoring Debacle", I come down strongly on DISCOURAGING any use of VIs that are not in the palettes unless you copy them to a new location on disk and use them from there. I'm pushing to have the Variant Data Type library added to the palettes in LV 2012 so that it is no longer under this interdict.

IANAL.

My understanding, from a long ago college course, is that software authors in the USA have a huge amount of indemnity under the law automatically. You should investigate that before you invest in insurance. It's one of those weird areas where the usual "you can be sued for anything" attitude of the USA doesn't apply. I've been told that some software engineer long ago (40+ years) got Congress to believe that software writing was such a crap shoot that it really couldn't be expected to be bug free, so anyone using the computer should automatically assume that there may be problems and respond accordingly. You'll note there's never been a class action suit against Microsoft for a security hole in Windows, nor a loss of business suit against Oracle for a database corruption bug.

Now, if you start mucking about with hardware, that's when things get a bit different, but there's still some protection there.

Deprecated properties are still safe to use insofar as they still work as documented. They just won't be safe to use in future versions when we stop supporting them.

> Is there any reason we don't have the capacity to load a class via fully qualified name?

It's not an unreasonable request. Just one that hasn't -- to the best of my memory -- been made before.

My guess as to why? I suppose that if it is a fixed list plug-in system, users write code to select the object from some sort of list (either build an array or have a case structure with each in a different case). If it is a dynamic list, it needs to go to disk sometimes, so always working by path is reasonable.

I can think of one difference: When you open a VI in the dev environment, LV will automatically search for any missing subVIs. When you open using VI Server, by default, LV will not search for missing subVIs. You have to put a specific flag on the Open VI Reference to make it search. If LV started the search and found the missing VI almost instantaneously, you might not ever see that in the load progress dialog.

That's my contribution for today. Others have given you other good ideas to try.

You wrote a custom Quick Drop Keyboard Shortcut during the exam? That's the best!

I concur! Good tip!