Help get QControls added to LabVIEW Core

[Sparkette]

2 hours ago, The Q said:

As for making it a single terminal as XControls are, I have found no way to do that. It would have to be functionality NI would add.

Yes, that's what I meant. If it's being added as a native LabVIEW feature, then maybe NI will add this functionality. I'm asking whether or not they will, as it seems obvious that they would if they were developing the feature from the start, and it would be a shame if they didn't. I'd like to know what they have planned. Also, what about clusters and arrays?

[Aristos Queue]

On 3/28/2019 at 9:39 AM, shoneill said:

We were promised that NXG would get exactly this kind of extensibility, but having heard nothing more on it (and a few rumours to the contrary, I fear the worst).

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. :-) 

[Aristos Queue]

On 3/29/2019 at 10:31 AM, flarn2006 said:

Yes, that's what I meant. If it's being added as a native LabVIEW feature, then maybe NI will add this functionality. I'm asking whether or not they will, as it seems obvious that they would if they were developing the feature from the start, and it would be a shame if they didn't. I'd like to know what they have planned. Also, what about clusters and arrays?

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.)

[shoneill]

3 hours ago, Aristos Queue said:

I don't believe this was ever promised.

It was listed as part of the roadmap, with the added caveat, that such extension would be available only in C#. I certainly remember it being communicated as the way forward with regard to replacing XControls.  It was certainly used as a carrot, even if the word "promise" is not accurate.

Then at the CAB in Austin some years back, we were told that won't be happening, that the existing control classes won't be extendable.

I can't recall exactly who and when, but it was definitely communicated.

[shoneill]

3 hours ago, Aristos Queue said:

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.)

So your job is to make it as hard as possible for NXG to ever catch up with with LV 20xx? 😀

[Aristos Queue]

5 hours ago, shoneill said:

with the added caveat, that such extension would be available only in C#.

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

[Aristos Queue]

5 hours ago, shoneill said:

So your job is to make it as hard as possible for NXG to ever catch up with with LV 20xx? 😀

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. 

[ShaunR]

8 hours ago, Aristos Queue said:

There are no plans to extend LV 20xx capabilities of XControls or anything similar.

Are there plans to fix all the bugs?

I've just spent a month writing two xcontrols and all that was mainly finding workarounds to the bugs (and I still don't know why some of the work-arounds actually work)

[hooovahh]

1 hour ago, Aristos Queue said:

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. 

That's good to hear, I guess I don't need to use this meme.

[shoneill]

1 hour ago, Aristos Queue said:

There's no way my much smaller team will stay ahead of NXG for too long.

Hold the Door!

[Neil Pate]

39 minutes ago, ShaunR said:

I've just spent a month writing two xcontrols

Wow, that is keen!

[The Q]

As I stated before, I don’t know what the replacement for XControls will look like in NXG. However, the work you spend writing XControls now will likely have to be repeated when rehosting that functionality to NXG later. 

QControls are all regular, plain G under the hood and therefore there is a higher likelihood that they could be portable to NXG. I have attempted to port the whole toolkit to NXG a while ago but have not tried recently. I don’t know what it would take to make a NXG QControl Toolkit but I do think it will be possible. If it can be done, then time spent now on creating QControls might still be usable in NXG.

Edited April 17, 2019 by The Q

[ShaunR]

2 hours ago, Neil Pate said:

Wow, that is keen!

Not the words I would've used

2 hours ago, shoneill said:

Hold the Door!

There has to be a meme that can link GoT and NI inter-departmental politics.

[infinitenothing]

4 hours ago, ShaunR said:

Are there plans to fix all the bugs?

I've just spent a month writing two xcontrols and all that was mainly finding workarounds to the bugs (and I still don't know why some of the work-arounds actually work)

I doubt there are plans to fix any of the bugs. Some of them have been going pretty much since the start.

[Aristos Queue]

16 hours ago, ShaunR said:

Are there plans to fix all the bugs?

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).

[shoneill]

16 hours ago, ShaunR said:

There has to be a meme that can link GoT and NI inter-departmental politics.

👍

[ShaunR]

5 hours ago, Aristos Queue said:

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. 

Dissapointing. I've managed to work around most of them but the one that prevents me from publishing is that I can't get rid of the xControl making the host VI dirty and requiring saving (a nested xControl). Still. It's OK for my personal use as I can put up with that.

[The Q]

The last straw that made me abandon XControls forever and create the QControl Toolkit was the trouble I was having using XControls with Actor Framework and PPLs.  At first I just encountered weird behavior problems, then sporadic crashes, and finally the inability to build the application.  With more work and headache I probably could have found workarounds and continued using XControls but it just wasn't worth it.

Edited April 19, 2019 by The Q

[gb119]

21 hours ago, ShaunR said:

Dissapointing. I've managed to work around most of them but the one that prevents me from publishing is that I can't get rid of the xControl making the host VI dirty and requiring saving (a nested xControl). Still. It's OK for my personal use as I can put up with that.

Is this the problem of handing 'volatile' state where you need to track state during the run-lifetime of the XControl but do not want to persist it to disk? Using the display state and setting the corresponding boolean in the action cluster then marks the host's dirty bit....? For my XControls I ended up storing a copy of the state in an LV-2 style global. To support multiple instances of the XControl, the LV-2 global is actually a variant and I store the state in attributes of the variant using the container refnum (cast as a string) to provide the attribute name. The first thing the facade does is to read the state and the last thing is write it back to the LV-2 global.

XControls are a bit of a pig, on that I guess everyone can agree....

[ShaunR]

13 hours ago, gb119 said:

Is this the problem of handing 'volatile' state where you need to track state during the run-lifetime of the XControl but do not want to persist it to disk? Using the display state and setting the corresponding boolean in the action cluster then marks the host's dirty bit....?

I think so. Well. I know so but I'm unsure of the mechanism since it is an xControl on a VI that is loaded in a sub-panel of another xControl (if that makes sense-it's nested). When exiting, the host VI (loaded in the sub-panel) wants to be saved. I can stop it by not updating the display state of the xControl on the loaded VI host, but then the facade doesn't update properly. Additionally, it doesn't seem to be every time; just sometimes which is proving to be a barrier to finding a work-around. If it's not loaded in the xControls sub-panel (even a normal subpanel), then it all works as intended. I have, since, thought of a couple of things to try, but it'll have to wait until I can get round to it again.

13 hours ago, gb119 said:

XControls are a bit of a pig, on that I guess everyone can agree.

Amen.

[Sparkette]

On 4/17/2019 at 12:22 AM, Aristos Queue said:

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.)

Aww, that's a shame. It would still be nice to get it added to LabVIEW though; then it will be possible to use this framework without adding a big dependency.

New data types sound exciting though; are you allowed to say what they are? (A hint at least?)

[Sparkette]

On 4/19/2019 at 5:26 AM, gb119 said:

Is this the problem of handing 'volatile' state where you need to track state during the run-lifetime of the XControl but do not want to persist it to disk? Using the display state and setting the corresponding boolean in the action cluster then marks the host's dirty bit....? For my XControls I ended up storing a copy of the state in an LV-2 style global. To support multiple instances of the XControl, the LV-2 global is actually a variant and I store the state in attributes of the variant using the container refnum (cast as a string) to provide the attribute name. The first thing the facade does is to read the state and the last thing is write it back to the LV-2 global.

XControls are a bit of a pig, on that I guess everyone can agree....

Isn't there an optional ability VI you can add to an XControl that will modify the state before saving? It says it's specifically for this purpose.

[gb119]

8 hours ago, flarn2006 said:

Isn't there an optional ability VI you can add to an XControl that will modify the state before saving? It says it's specifically for this purpose.

That solves part of the problem, but not all of it. Using the Convert State for Save ability lets you stop writing volatile state information to disk, but it doesn't stop LabVIEW from thinking that the host vi (i.e. the one you've put the XControl into) requires saving. That happens as soon as you toggle the state changed boolean in the action cluster. You need to have an entirely separate means of storing volatile, per instance, state and then not touch the state boolean in the action cluster unless you really do mean to record a change that would require saving. I've been using variant attributes on a variant stored in an LV-2 style global, but I guess one could use 1 element queues, or even, gods forbid, a global variable!

That said, I;ve just realised that I ought to have coded the Uninit Ability on my XControls to clean up the per instance variant attributes when the host vi goes out of memory....

Edited April 21, 2019 by gb119

[Aristos Queue]

XControls work just fine... if you dance with them the way they were intended. *head bang*

1. 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

2. 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. 

[Aristos Queue]

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.