Aristos Queue

Ask the others on this forum... they'll tell you I try never to promise future functionality. All sorts of things can conspire against a feature. I mean, everything from a malicious server virus wipes out all of last week's code changes across all backups to NI deciding to "change course" and go into knitting and not releasing any more software. But... taking all of that into account... you can have some faith that it'll be in the next full version of LabVIEW, sometime next year. If there is a next year... 🙂

If you have LV 2019, this will be faster if your array gets large enough* * "large enough" varies by CPU and memory of specific hardware.

I wouldn't trust a malleable VI inside an XNode at all without extensive testing. XNodes are unsupported tech when used for general purpose problem solving. Although I did do some light testing of the interaction between the two technologies a couple years ago, I did not vet their interaction fully. When NI writes an XNode, we don't assume that "XNode" is a safe tech to use... we vet the specific XNode that we are writing, checking its correctness and stability under its various scenarios. None of our shipping XNodes have used VIMs. You may have success using the two together, but I'd advise you to be careful. You have a tech (malleable VIs) that decides its internal types at caller's semantic analysis time (i.e. every mouse click) lodged inside a tech (XNodes) that decides its types only at caller's compile time (i.e. when you click the run button). The malleables may not be happy having their type computations deferred.

I suspect UTF uses "Set Scope", which is a separate method that doesn't do the propagation. The UTF authors may have written their own propagation loop. You could use the same workaround (I acknowledge how annoying that would be to write, but at least the option exists). BTW, looking at code, turns out that the "And Propagate" version was written to always prompt. That's how the Library Properties dialog works. On my machine as of this morning, there's a new Boolean parameter to "skip prompt" on that method.

pktl: Yuck. I don't know how long *that* has been broken. We shouldn't be prompting from the scripting method. I'll file a bug report for it. The gUnattended does repress the dialog box, but it also makes the scope change *not* propagate, which defeats the purpose.

DVRs can be upcast and downcast with To More Generic and To More Specific. So if you have a public type that is the ancestor of the private one, you can upcast to the public one in public and then downcast when you need to actually use it. That's all completely type safe. (Note: DVR of LabVIEW Object works without you having to create a new ancestor class.)

Even as a pointer, that wouldn't work in C++. Any use of the type in a public signature must be public, even by pointer, even by reference.

You people are so laid back and forgiving. I’m an editor on multiple wikis across cyberspace, and none of the others are anything less than draconian. Capitalization whatever?! Wow. I’m going to need to wear my oversized Hawaiian shirt and cargo shorts when I’m editing, just to get in the right state of mind! 🙂

If you want to run the VI in the IDE as a tool of some sort, save it into the "<LabVIEW>\project" subdirectory. Every VI in that directory gets automatically picked up and added to the Tools menu. The menu item gets its text from the display name of the VI, saved in VI Properties. When the menu item is chosen, your VI is run in an isolated application instance so it never interferes with running applications. App instance isolation is how all the G parts of the IDE execute, like the icon editor, the getting started window, or the right-click menus.

I noted a few uses of lowercase "boolean". Capitalizing that B is often confusing because it is the only non-class type that is typically capitalized. Text languages have solved this by using keyword "bool", and therefore that is the actual type name. LabVIEW doesn't typically type out data types. NI style guide says to capitalize Boolean. Does LV wiki agree? When I'm editing the wiki, I will generally follow NI documentation style guidelines (so "subVI" instead of "SubVI", for example). Are there any particular conventions that the community has established that differ from NI standard practices? When discussing language features (as opposed to editor features), LabVIEW 20xx uses "LabVIEW"... LabVIEW NXG has moved to using "G" and uses "LabVIEW" to discuss the IDE. We find that this provides clarity in many documents, and it provides less of a mouthful when speaking (The NXG root class is "G Object" instead of "LabVIEW Object", for example). Does the wiki prefer "LabVIEW" or "G" when discussing language features? When behaviors diverge, what is the preferred way to document distinctions between LabVIEW 20xx and LabVIEW NXG? Should they be separate pages (so the former can be easily deprecated in the future) or do we prefer same-page-different-sections for easier side-by-side comparison?

I tried to update this existing image with a new version of the PNG: https://labviewwiki.org/wiki/File:Screen_Shot_2019-06-27_at_1.50.14_AM.png#file I keep getting an error: [XSir2GJrsGEvUGpzBj7-DAAAAAQ] 2019-07-12 15:48:40: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" Anyone know what's wrong?

Are those 10 charts in the first image all screen shots from LabVIEW? If so, very nice! Professional work!

Ethan: can you confirm fixed in 2019?

MartinD: no, nothing wrong with that, but I usually only use that approach when the value is a computed value that needs different data storage. For example, “determinant” of a matrix... sparse matrix and dense matrix have different data storage, and determinant is computed differently for each type. But it works fine in your case, too. It’s nice if some classes have it as a variable (gets stored per object), but other classes it is constant for all objects of the class, so the method can just return a constant and not burden every object with that bit of data.

Honestly, I have no idea if that’s something that is even logically possible. Computing data flow from procedural instructions is one of the holy grails of compiler optimization. Sure, there’s short segments that are easy to translate back, but a general app? Maybe, but I have 19 years of LabVIEW R&D experience with the compiler, and I’d be hard pressed to do it by hand, much less derive a general algorithm for automatic decompilation.