Aristos Queue

Call change to constant afterward if it matters to you (nearly zero effect on generated code since Open VI Ref cannot be constant folded). But (I’m not at machine right now) it would surprise me if that same property weren’t on the constant. You should check To get the conpane of a VI: https://zone.ni.com/reference/en-XX/help/371361R-01/lvscript/vi_connector_pane058datatype/ Or use this method on App refnum if the VI is not in memory (it reads the conpane without loading the VI): https://zone.ni.com/reference/en-XX/help/371361R-01/lvscript/app_getviconpane_datatype/

The method I think you’re looking for is this one: https://zone.ni.com/reference/en-XX/help/371361R-01/lvscript/virefnum_set_conpane/

With our built-in controls, the problem is solved at the moment of selection. If the main part is selected (e.g. the LED part of a Boolean control) then all of the related parts are also selected. If a secondary part is selected (e.g. the label of the Boolean control) then only that part is selected. Thereafter, the rules of the selection list work as normal -- when you drag one item in a selection, all selected items move with it. This is what allows you to select the label of several different controls at once.

LV 2019 augments the right-click menus for class wires/terminals to provide a method list you can drop, which should alleviate this issue. I found a way to make the right-click menu plug-in able to add the graphical palette menus and then built a right-click plug-in that builds the method palette on the fly if the class doesn't already have its own default palette.

That is really weird. I haven't tried to replicate... not sure I'll have time for a while... but there's one odd thing to try... after the "Remove VI" call, try adding a "Wait MS" of about 100 milliseconds. I'm trying to come up with hypotheses that would cause this problem, and the only one I can think of is that the subpanel is opening its own reference to hold the panel in memory and that is (for some unknown reason) flagged to show the Save Changes dialog. I'm torn between hoping this works you around the bug and hoping that it has nothing to do with it.

I got a PSE to work on this for a while this week. We couldn’t replicate the issue. It’s a pretty bad bug — wiping out the whole directory. If you have more explicit steps to reproduce, please consider filing a bug report with NI.

If you open it with Open VI Ref and then close it before calling Close Reference, there shouldn't be a Save Changes dialog. The only way I replicate is if I leave the panel open after the VI finishes running and then the user closes that panel (which is correct behavior). Is that what you're doing?

PS: Did I mention that the design of these things was arcane and bad? Yes? Ok. 'Cause it's true. I have a long list of lessons I hope NXG learns.

XControls work just fine... if you dance with them the way they were intended. *head bang* If you don't want data to be saved, one way is to not put it in the State data. If you only need the data in the facade, add a shift register. But if you need it lots of places, put a global unique ID (GUID) in the XControl's state data, something that never changes after creation, and create an LV-2 style global with a lookup table from the unique ID to the data. You can create GUIDs on any LV OS using: LabVIEW 2017\resource\Framework\Providers\API\mxLvGenerateGuid.vi Changing the state shouldn't cause the VI to need to be saved unless it needs to be saved. So, yes, sure, in the IDE in a directly called VI, yes, changing state dirties the VI. But obviously that doesn't happen in a built app. AND, importantly, it doesn't happen in the IDE for any dynamically loaded VI (unless you are adding the 0x1 flag to track changes, in which case you get what you requested). If you're loading the hosted VI into a subpanel, that means you're working with it by VI Reference. So load it using Open VI Reference (without the flag) and the problem of being prompted to save should go away.

@Yassamina BERKANE The answer is the same as it was in 2006: dequeue and concatenate. A ragged 2D array is not (and never will be) meaningful in LabVIEW. Because the compiler cannot guarantee that you're going to add arrays of all the same size to the queue (you might be doing that, but it cannot be proven from code because refnums can be shared all over the place), any attempt to ask for all the queue elements in one array will have them each wrapped in a cluster. If you dequeue and concatenate, you can build a 2D array yourself.

Likewise -- I never heard of it; seems useful.

I don't know of any hooks. That's not the same as saying they don't exist.

No. Not all, and not any. There are some major bugs -- like the circular dependency bug with LV classes* -- but most of the issues people have with XControls are features, intended parts of the design. It's a bad design. Seemed like a good design when it was put together, and it does some things very well, but it's inflexible. When coupled with some of its loading idiosyncracies, it means that a lot of ultra complex XControls just don't work or require arcane code. But the issues are fundamental to how XControls are structured. Fixing them would not be backwardly compatible -- it essentially means rolling a new YControl (or whatever we name it) feature, and that's not on the docket for LV 20xx at this time. If XControls work for you, then they work. If they do not, they don't. I do not expect any shift in this in LV 20xx. * If loading your class loads an XControl into memory then you should take care that loading the XControl does not load the class into memory. Conversely, if loading an XControl causes a class to load into memory then you should take care that loading the class does not load the XControl. If you ever have an XControl that is circularly linked with any class, various forms of doom will come upon you, from random crashes to infinite hangs. It's a known issue with no way to resolve given the design of the XControls (the classes are just fine).

There's no way my much smaller team will stay ahead of NXG for too long. My job is to make LV 20xx a product that you all want to keep buying and using until the day when you go, "You know, I'd rather use the new shiny." That's started to happen in some customer segments. It'll happen more and more over time. Since buying LV gets you both platforms for the same price, it's simply a question of when does the new platform have enough functionality for your particular work. NI has abandoned the goal of trying to get everyone swapped over as fast as possible and is instead focused on getting each piece of functionality right and moving customers over as they become viable. It's a much MUCH saner strategy.

Ah. Ok. In that case, I believe you. I think it is possible through C#, but not easily.

Nice work.

So, I've gotten word that some of y'all are concerned about me because in the last year, I basically vanished from both the LAVA forums and the NI forums other than the Idea Exchange. One person at the CLA Summit in Europe last week wondered if I'd died. Honestly, I had no idea that I'd dropped my post frequency down so low. What happened was that in May the forums that I monitor exploded with content. This is generally a good thing -- says the community is vibrant. But it meant that I went from having tens of posts in each forum to hundreds of posts, and the deluge overwhelmed me, and I started ignoring the backlog. That's just turned into a natural attrition. I'm going to try to get back to reading (and posting) the forums. I doubt I get back to the high rate of read that I had before -- I've got a lot more internal-to-NI stuff that I deal with on a daily basis these days -- but I intend to get back to posting at least every couple days instead of every couple months. And, just to be clear: no, I'm not dead. :-)

As far as I also know, it is impossible. Having said that, I'm with Powell: if you provide more details about your use case, maybe we can work something out. You explained your work, but you didn't say why you need the call to remain in the call chain.

If QControls come into LV 20xx, they'll be as they are today -- no additional bells and whistles. That's a big "if", by the way. Several of us continue to make the argument, but since they're available as a toolkit, it's hard to make the case that they need to ship with LV. Being owned/maintained by NI only makes them more generally available and means no one has to worry about third-party IP licensing. We will see how this plays out. The kudos on the Idea Exchange has been useful. There are no plans to extend LV 20xx capabilities of XControls or anything similar. All work into improving G-based UI components is being done by NXG teams. I and others continue to push requirements to them (such as "let them be included in arrays"). (In case y'all are wondering, my role with NXG is largely "lead user kibitzer". I have worked on various parts of the code base over the years, but at this time, I am 100% tasked with adding features to LabVIEW 20xx, especially language extensions (there are others on my team working on editor improvements). The channel wires and the malleable VIs have been my work; there's a couple new data types in LV 2019 that fill some serious long-standing language holes. And LV 2020 should... well... let's say I'm kind of eager for it.)

I don't believe this was ever promised. I was arguing strongly for it but got shot down, and I was on the controls team at the time. I don't know who said what to you about this kind of extensibility, but it would surprise me greatly if anyone said this was planned. The statement that was usually used was, "Most customers tell us they would never use this, and so it seems like a waste to spend time on something so few will use." I argued that those few customers were the library authors who support the rest of the community, but that argument didn't carry the day... the managers at the time didn't want to wait for large parts of G to be developed in NXG before the first controls could be written. But don't despair. There is a way forward! (If I couldn't see a way out, I'd've protested a lot more back then!) Today, as per your fears, I can confirm that there is no such extensibility of built-in controls in NXG. In theory, you can extend them using C# code and XAML, but it's not straightforward to do so. But, when NXG does get around to creating it's replacement for XControls, if it builds extensibility into them (I expect this to happen), then there's no reason that NI couldn't build a library of such controls that exactly mimic the built-in controls and make those available for extension. A bit of backend magic could make the scripting API agnostic about whether it was talking to an original built-in control or one of the mimics, as long as the mimics really did duplicate original functionality exactly. If the scripting API is agnostic, then we will have the extension hooks that we have been asking for. That's all years away -- NXG has a long road to go before it gets to any of that. There's some fantastic features in NXG that LV has needed for a long time, and someday, it'll catch up to LabVIEW 20xx. It just takes a lot longer than NI was collectively willing to admit in the early years of NXG. :-)

The open by name was never intended to work. The problems crop up when you open a VI ref to a clone and then that ref outlives the clone itself. I personally rely upon this technique for several of my debugging tools, so I tried to stabilize the situation, but I couldn't really close the holes. As long as you make sure that you are closing the VI refs that you open before the clone VI has a reason to leave memory, LV seems to be fine; if you have the ref open and you close out the clone, then you try to do something with the ref, that's when problems occur. @drjdpowell wrote: > I don't believe a this-VI ref has any problem; it is only a ref openned by name. Correct.

In the last three years, I've been a reviewer for the CLAD and five of the new badges, and I've found the questions to be generally very good (and the ones that weren't, I sent back for rewrite). The CLD questions I've seen are all rock solid -- many of them become public as sample questions after they rotate out of circulation. I haven't looked at the CLD recert or the CLA recert exam questions lately, but they get vetted by CLAs outside of NI and have passed muster or they wouldn't be on the exam. If you have specific examples of bad questions, the cust ed team is definitely interested in hearing that feedback. I'll pass it along if you post here.

I encourage Ben not to worry too much about the interoperability with G and focus on getting the new language stabilized within itself -- a graphical notation for a safe reference system has value even if it only talks to itself... it can become an ecosystem just as G did. Now, obviously it has *more* value if it can talk to other languages, just as G has gained that ability over time. But that doesn't have to be up-front. Once the Rebar memory management is well-defined, creating the rules for interop should be relatively straightforward. I'd be far more concerned about Rebar cutting a corner to accommodate G than about making the interface seamless. The whole point of building an absolutely provable system is that it is provable -- any shortcuts and the whole attempt loses its value. Interop between Rebar and G will come in time.

I agree. Ben works on making a language safe for references. I work on making a language without references. Our goals are the same: a world where data can be trusted.

Ethan: Your CAR has been received, and I believe I have it fixed for LabVIEW 2019. Testing is ongoing to verify, but I’m confident. The in-place optimizations for class field access should I hope be addressed in LabVIEW 2019 if you have simple, inlined, static dispatch accessors that do not include error in and error out. We found a way to make the magic pattern that works for clusters apply to classes. Fingers crossed. Relaxing the block on access to class private data has even more gotchas than I expected, and not just at the technical level... since we do method substitution within the VIMs, if we allow access to class private data then it seems like we should allow substitution of the fields. But that is a pretty ill-defined interface that crosses the line to admit some of the hardest-to-debug C++ code. I’m opposed to admitting that to G language, even as I acknowledge its powerful notation. Even if I bought into it, I still don’t have a good solution to the technical barriers, at least not in LabVIEW 20xx. In LabVIEW NXG, it seems like it may be more viable.