Aristos Queue

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?

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.

I concur! Good tip!

I've mostly been working for a research group that studies new types of scintillators for radiation detectors. My most recent finished project was adding the capability of measuring "Thermoluminescence" to an experimental setup previously used just for another type of measurement (pulsed X-ray luminescence). Part of that was adding Thermoluminescence-data display to a database viewing program that wrote earlier to allow the researchers to look at all the various measurements held in the database: View attachment: CsI.png -- James Click here to view the article

LAVA: Where heated debate produces violent eruption of new ideas. LAVA: Spewing new ideas, shaking up old ones

A lot of people seem to miss the fact that adding a default case WILL NOT make the VI behave the way Justin wanted it to work. A default case would mean an event fired, which would mean the timeout case would not fire. Making the timeout and the default case be the same case would mean that the timeout case would fire far more frequently than it should. The conversation about possible changes to this behavior appears to think that adding a default case would fix this issue. It wouldn't. Adding a default case just makes it clearer what is going on with the event structure... it does not give the behavior Justin tried for. With regard to the default case, Fabiola, you argue against changing the behavior because it would break older VIs. If you read my post again, you'll note that I included "mutate older VIs to add the default case", so they wouldn't change behavior at all.

I discussed this point further with JCase: The behavior of the Start Asynch Call By Ref node is identical to the Run VI method when you pass true for the "autodispose reference" parameter, with one minor exception. With Run VI, if you proactively call Close Reference, then the other VI will quit unless the VI has some other reason to stay in memory (another reference has been created or the panel is open). With SACBR, if you close the reference, it has no effect on the running VI.

Here's a list of ideas that just appeared on the Idea Exchange... they're all from a user "jcase", whose name is in blue, meaning he's an NI employee. JCase is the main developer of the new ACBR feature. As you might guess from the list of ideas, he sees a lot of ways that the ACBR could be extended in the future... Allow Remote Asynchronous Calls Allow Asynchronous Call By Reference with Strict, Static VI Reference Add Asynchronous Call By Reference to Call Setup Dialog Typeless Call By Reference and Asynchronous Call By Reference [/url] Add Timeout Input to Wait On Asynchronous Call Node Integrate Asynchronous Call By Reference with Event Structure Please kudos as you see fit...

I assume the caller should close the VI RefNum after calling Start so that the launched VI doesn't stay open. Yes?

Hm... In this case, I'm a user as much as you are, and I didn't see that note, so I just assumed the 0x108 would work... and it seems to do so. I will see if I can get one of the developers to chime in.

Both systems -- to wait for a specific clone or to wait for any arbitrary clone -- are possible. Here's how to do the "wait for a specific clone." Save both of these VIs to the same directory, then run Caller2.vi. That will launch three copies of the async VI. No matter which order you click stop on those three copies, you'll always get the result "0, 1, 2" in the final array because they're collected in order. Note that this example uses the 0x8 flag -- you were wondering why there was a new flag... it's to support the other use case where you don't care about the order. Caller2.vi stop on button.vi The case when you don't care which instance you get back is when the output of the instance tells you what position in the final output that instance has. Think of an autoindexing output tunnel on the parallel For Loop -- it runs a whole bunch of frames in order, and then puts the outputs into a single array. Each parallel instance knows where in the final array to end up, so it doesn't matter which one finishes first and copies its results into the final array. There are many use cases where that's useful with spawning multiple copies of the Asynch Call By Ref node and then catching them in whatever order they finish.

Functionally irrelevant to propagate or not since it is guaranteed to be "no error" in that case. But connecting it through will sometimes give LV the opportunity to use a single allocation of the error cluster all the way through the app, which cuts down on the size of the VI in memory (by a few bytes), so I usually do wire it.

Unless I'm missing something, these are pretty fundamentally different patterns. The Symbio one focuses on method calls to by-reference objects [aka synchronous messages] while the Active Object focuses on message passing and announcements [aka asynchronous messages]. Although the two can be mixed, there's a huge amount of distinction in how to build up an application from scratch depending upon which one you're relying upon. I would not call these the same thing at all.Am I correct in my analysis here?

Yet Another Messaging System... In my NI Week presentation on "Trends in LabVIEW Object Oriented Programming", one of the trends is the development of object-based communications schemes that modify the traditional queue-based-state-machine architecture. I'm mentioning Actor Framework, JAMA, and LapDog. Are there others that need mentioning?

Move Australia closer.

I agree with the first reply: Make it a strict typedef.

I will be there, and I've talked a few other members of LV R&D to come along, including a couple of new faces. These are folks who aren't loaded to the gills already with projects and features they already support, so they're a good target for your lobbying efforts.

You also need to configure the VI Properties >> Appearance page to be a floating window if you want the "don't take key focus when interacted with" behavior that the LV palettes have.

I theorized that it would be beneficial for backing out edits. I make an edit to the class that removes a field. I save the class. I realize, oops, I want that back. Add it back in. But to the mutation code, this looks like "delete the data and add a new field with default values." Editing the mutation history would let you address changes like that so that the middle step you record as having no real changes (assuming you don't actually have any flattened data saved at that middle step).