Help get QControls added to LabVIEW Core

[The Q]

All,

Darren and I have been working to get QControls on the priority to become part of LabVIEW Core. If you feel this would be a beneficial to you, please go vote on the Ideas Exchange:

 https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-QControls-to-LabVIEW-Core/idi-p/3908067

Please kudo! Thanks in advance!

[Sparkette]

Wow, I love that idea, and it's great to see there's already an NI employee on board with it. I posted a comment on it; I'll quote it here:

What would be REAL nice would be if we could use them just like regular controls. That is, you just place it from the controls palette, just a regular terminal on the block diagram that you use like any other, and (most importantly) they behave as expected inside clusters and arrays. Just like with regular controls, you don't need a reference to the control for basic read/write functionality; if you want to do something more advanced that requires a reference, you can use the VI Server Reference node. Maybe even have the reference wires automatically (or through To More Generic Class) coerce to the refnum type of the control it's based on without anything extra.

Basically, if this is implemented the way I hope it is, using a QControl would be no different from using any other control. And of course, the current way of using them would still work, for backward compatibility.

Think this is a possibility to any extent?

[smithd]

isn't that...an xcontrol?

 

anywho, voted up

Edited March 28, 2019 by smithd

[ShaunR]

 

Wow, I love that idea, and it's great to see there's already an NI employee on board with it. I posted a comment on it; I'll quote it here:

We've been asking for that since about LabVIEW 6. Instead, we got xcontrols (xcontrols do a lot of what you are asking for, by the way. They are just buggy and unpredictable).

NI can also have some DLL controls using a completely undocumented API. Sounds like that might be right up your street 

Edited March 28, 2019 by ShaunR

[hooovahh]

I just started down the rabbit hole of making a new XControl recently.  Oh man such a pain.  Here is a little graph I made complaining about the XControl creation process, and the time needed to make something useful.  Any alternative is appreciated.

[shoneill]

In end effect what we need is the ability to actually inherit from existing controls in order to extend their functionality. Just being able to extend a String control to allow for a dictionary should be possible without it being distinguishable from a "normal" String control on the FP or BD (Perhaps for some identification on the BD of it being an extended control).

XControls never really offered this. Correct me if I'm wrong, but I don't think QControls do either.

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 have the feeling NI might use this as an excuse to see their promise of extendible FP controls as being fulfilled. For this reason and this reason alone I am skeptical and pessimistic.

TL;DR. Technically yes. Politically and strategically no.

[hooovahh]

39 minutes ago, shoneill said:

XControls never really offered this. Correct me if I'm wrong, but I don't think QControls do either.

You are incorrect they do and it is amazing.  Here is a slider that I made into a QControl and I have all the normal slider stuff, but then have the extra stuff I added.  It isn't perfect, like you can see the "Scale" normally opens up another submenu but in this case it just returns a reference, but with this you can then do the same stuff.  Or you can just reference the original control instead of this class and do things exactly like you always have but you won't have the new items.

[ShaunR]

1 hour ago, shoneill said:

In end effect what we need is the ability to actually inherit from existing controls in order to extend their functionality. Just being able to extend a String control to allow for a dictionary should be possible without it being distinguishable from a "normal" String control on the FP or BD (Perhaps for some identification on the BD of it being an extended control).

XControls never really offered this. Correct me if I'm wrong, but I don't think QControls do either.

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 have the feeling NI might use this as an excuse to see their promise of extendible FP controls as being fulfilled. For this reason and this reason alone I am skeptical and pessimistic.

TL;DR. Technically yes. Politically and strategically no.

A hooovahh said. They do but it's really only a wizard that takes the grunt work out of creating the properties and methods yourself (something xControls could have done and probably still could do).

I think rather than thinking as it being an alternative. Think of it as a run-time only package. There are no edit time capabilities and it isn't encapsulated like an xcontrol. It would have been useful for my Markup String xControl if a little unweildy for the end user (they would have had to have init and deinit Vis and an event structure instead of just placing a control). But It wouldn't have been much use for my Tab Control as that needs edit time capabilities and doesn't inherit from any existing control.

I see it has a place, but it doesn't seem to be a replacement for xControls.

[shoneill]

22 minutes ago, ShaunR said:

I see it has a place, but it doesn't seem to be a replacement for xControls

I agree completely, but will NI spin it differently?

[ShaunR]

4 minutes ago, shoneill said:

I agree completely, but will NI spin it differently?

I don't think it matters. If it's a package that comes with LabVIEW, you can choose to use it or not. 

[shoneill]

1 hour ago, hooovahh said:

You are incorrect they do and it is amazing

I don't think I am incorrect. It mimics the existing VI Server tree, but it does not extend it per se. I agree it's a great toolkit and has a LOT of potential, but it's just not the same.

I've done something very similar, I'm aware of the benefits and the limitations of this type of implementation. Code changing properties of the control in parallel to the LVOOP approach can be very hard to manage.

[ShaunR]

3 hours ago, hooovahh said:

I just started down the rabbit hole of making a new XControl recently.  Oh man such a pain.  Here is a little graph I made complaining about the XControl creation process, and the time needed to make something useful.  Any alternative is appreciated.

Oh. On this point. I'm currently struggling with the "dirty vi" propblem. If I set the state to changed, the VI it's used in wants to be saved (even though nothing has changed). If I don't set the state, the control won't update the facade.I can live withthe dirty VI but "Level where general public would find it useful" is just out of reach.

[shoneill]

7 minutes ago, ShaunR said:

I don't think it matters. If it's a package that comes with LabVIEW, you can choose to use it or not. 

My usage of it or not is completely irrelevant to the point I was trying to make.

NI should be working on a proper implementation of extendable controls (C# inheritance was touted, then it turned out that will be limited / useless). I fear they are looking for a way out of that corner. But still, if we're realistic, there'll probably be notnhing of that sort coming in the next X years, so this IS a boon. I just hope this doesn't stop NI working on a proper implementation.

I'm not casting any shade ont eh toolkit itself, it looks pretty amazing.  The reason I think it might sway people at NI is because it IS good. If it would be half-arsed, I wouldn't be afraid. So from that point of view, technically speaking, 🧡

[hooovahh]

9 minutes ago, shoneill said:

I don't think I am incorrect. It mimics the existing VI Server tree, but it does not extend it per se. I agree it's a great toolkit and has a LOT of potential, but it's just not the same.

Okay to be fair, QControls don't actually extend the VI Server tree, but from a developers perspective the outcome is the same, or close enough to not matter.  You drop a property node, and you get get access to all the same things you're used to, and the new things.  It looks like a duck, but might not be a duck.  I can see why code changes in one place effecting the other can be weird, and for that I can think of a few ideas that are probably terrible.  I haven't used them extensively yet, just working on a few ideas, but since it solves so many of my XControl problems, and adds just a couple problems of its self, I'm okay with it.

I too wouldn't be surprised if NI doesn't invest in XControls, or an alternative.  But then again for current LabVIEW I didn't expect that to get any better anyway.

[ShaunR]

8 minutes ago, shoneill said:

NI should be working on a proper implementation of extendable controls (C# inheritance was touted, then it turned out that will be limited / useless). I fear they are looking for a way out of that corner. But still, if we're realistic, there'll probably be notnhing of that sort coming in the next X years, so this IS a boon. I just hope this doesn't stop NI working on a proper implementation.

Well. NI have never really worried about finding a way out of a corner - I'm still waiting for unicode support  but I take your point. If NI see this as fullfilment of an issue, the 11 xControl bugs currently in the known bugs list will never be fixed.

Edited March 28, 2019 by ShaunR

[shoneill]

4 minutes ago, hooovahh said:

I too wouldn't be surprised if NI doesn't invest in XControls, or an alternative. 

I'm pretty sure XControls are dead in the water. But I sure hope they are working on an alternative, at least for NXG.

[shoneill]

10 minutes ago, ShaunR said:

11 xControl bugs currently in the known bugs list will never be fixed.

Is the existence of XControls one of those bugs?

[ShaunR]

4 minutes ago, shoneill said:

I'm pretty sure XControls are dead in the water. But I sure hope they are working on an alternative, at least for NXG.

I've no interest in NXG. When LabVIEW finally dies, I will use one of my other languages that supports x-platform.

[Sparkette]

17 hours ago, ShaunR said:

We've been asking for that since about LabVIEW 6. Instead, we got xcontrols (xcontrols do a lot of what you are asking for, by the way. They are just buggy and unpredictable).

NI can also have some DLL controls using a completely undocumented API. Sounds like that might be right up your street 

Yeah but I want the best of both worlds, extending existing controls while also being able to use it via just a block diagram terminal. Also I'd like something I can put in an array or cluster; XControls can't do that and I don't think QControls can either.

I've actually been meaning to see if I can figure that out, lol. I already know how you would load a control from a DLL: there's a hidden "Plug-In Control" object that, when placed via scripting or a modified palette, allows you to load a DLL from the context menu. You can place it via my Place by Style Quick Drop plugin. Incidentally an uninitialized plug-in control is the only way I know of to get a control with "void" as its type. (And I don't mean empty clusters or void arrays.)

Edited March 28, 2019 by flarn2006

[Sparkette]

How long do these things usually take to go through? Is this likely to be in LV 2019 if it's accepted? Or more likely not until 2020? (or later?)

[smithd]

2019 is almost certainly done already. Since its integrating an addon, it could come in SP1, but I'd bet 2020 if it happens.

[Sparkette]

21 minutes ago, smithd said:

2019 is almost certainly done already. Since its integrating an addon, it could come in SP1, but I'd bet 2020 if it happens.

In that case I'm hoping for 2020, because what you're saying makes it sound like SP1 would mean the stuff I'm asking for isn't there.

[The Q]

You are right QControls do not inherently have edit time behavior but I see the edit time behavior as one of the problems XControls had. It made them difficult to work with and took a lot of programming just to get the basics.

However, I have created a QControl with some edit time behavior by using the Right click menu stuff. See my DataGrid QControl linked here:

https://labviewwiki.org/wiki/DataGrid_QControl

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. Maybe this would be possible with an XNode but I’m not an expert with those. @hooovahh could probably take a stab at it. He’s better at those than me.

I don’t know what they have planned for NXG. I know XControls are not it though. QControls have a higher likelihood of being able to port over to NXG but I haven’t tried yet. 

[hooovahh]

I don't think XNodes would help with this.  XNodes are great for making a single thing on the block diagram do different things and encapsulate functionality in it.  But there is no front panel connection with an XNode.  The best you could do is maybe make an XNode, that internally links to a control reference on the FP.  You'd  still have the normal control terminal on the block diagram because I don't know of a way to make the control terminal itself invisible.  If I could then then that would be a solution, but likely full of hacks and who knows if it actually would work well.  And then you'd be dealing with a technology NI isn't interested in making more public.  If QControls did have an XNode component, and it could essentially replace the native terminals and references, then I'd suspect NI would be less interested in making it part of the LabVIEW core.  One nice thing about QControls today is how it is normal pure G, which as you mentioned might be why it has a hope for being ported to NXG.

[ShaunR]

1 hour ago, The Q said:

but I see the edit time behavior as one of the problems XControls had. It made them difficult to work with and took a lot of programming just to get the basics.

Really? I didn't find it difficult or onerous at all - just case statements for edit and run-time behaviour.

With xControls, everything takes a lot of programming to get the basics, hence why your toolkit has a place (which it excels at, by the way). But once you have the basics of updating/drawing/refreshing the display (the hardest part), creating edit-time functionality isn't difficult. - mainly menu manipulation. In fact. Because front panel menus are mainly used to configure a control at edit-time and you can add in-built menu options to a custom menu; inheriting functionality from the architypical control  (like enable/disabled/greyed out) isn't a problem and doesn't have to be re-implemented as it does with the diagram properties and methods.

Edited March 29, 2019 by ShaunR