QControl Enthusiasts
QControl Usability Improvements
@TheQ wrote:
@ChrisStrykesAgain wrote:
Even I struggle with what type of control reference is required for a given Q control, so I think you do need some kind of helper. I played with some different ideas, but I think the only viable option I could come up with is a merge VI, as you said. This would allow a user to easily enough switch out the control for a different style, but still show us which type of control is required.
Having a Facade.ctl and putting it into a merge VI would probably be the simplest way to make this easier. The developer would have to add the control they wanted to the Facade.ctl. However, the wizard would script the basic control into it based on the inheritance selected.
Oh, but this could add some complications. The Facade.ctl would have to be Strict Type Def which would lock-up some properties. I guess it doesn't have to be Strict Type Def; but then where do you make changes, in the Facade.ctl or in the using VI?
I don't think there needs to be a mechanism to easily switch between "types" of Q Controls. They are generally pretty specific in their purpose and I don't think I would generally want to casually convert from one to another. It might be a nice to have, but I think development efforts would be better spent elsewhere.
This is only helpful if you plan to have your QControl control only a single control (lots of "controls" there hopefully that makes sense). Then you could switch between Silver, Modern, System, etc. easily. If it is multiple controls, or multiple controls in a cluster (i.e. my Calendar QControl) then you almost have to have a Facade.ctl.
A single terminal isn't desirable in my mind, because it doesn't make it clear enough that "hey, this is something special, you can't treat it just like any other control." I think that behavior is unavoidable, so we shouldn't try to imply anything otherwise.
I'm not sure how to make this happen in a non-hacky way that would still be stable.
I do really want invoke nodes. When I used Q Controls in a project earlier this year, it was a little awkward not having them.
I think all of us would love to be able to do this for all our LV-OOP classes. Unless NI makes them, which for some reason I can't remember, they were reluctant to do, it would probably need to be an XNode; which are also hacky and possible unstable. I would be willing to try, I might need help from the expert, @hooovah.
When you say "merge vi" I hear "place VI contents" option when creating a palette item. Is that what you mean? If so, why do we need any kind of facade.ctl or typedef? I would assume that you could do this for each q control, choosing the appropriate type of LabVIEW control and then let the user swap it out for a different style if they want using the "replace with" functionality (or just pasting over the one that was placed by default).
Re: Invoke nodes, typically I've found NI is more receptive if we can demonstrate a definitive real-world use case instead of just saying "I could do cool stuff with this." Well, here's the use case, so maybe there's a glimmer of hope they would consider it?
When you say "merge vi" I hear "place VI contents" option when creating a palette item. Is that what you mean? If so, why do we need any kind of facade.ctl or typedef? I would assume that you could do this for each q control, choosing the appropriate type of LabVIEW control and then let the user swap it out for a different style if they want using the "replace with" functionality (or just pasting over the one that was placed by default).
Yes, I mean "place VI contents". I think I will try adding this and probably call it the "Facade.vi" (unless you have an idea that is better). It won't mess up current users. It will just be another VI created by the wizard and, you're right, the developer can edit the control in it for the style or look they want.
After it is dropped and the contents are in the using VI, the developer will have to choose whether to edit the control in the using VI, the "Facade.vi", or both as the control won't remain linked (Strictly Typed).
Re: Invoke nodes, typically I've found NI is more receptive if we can demonstrate a definitive real-world use case instead of just saying "I could do cool stuff with this." Well, here's the use case, so maybe there's a glimmer of hope they would consider it?
Maybe we can put some pressure on NI for this. It would be very helpful.
I think calling it a "facade.vi" would muddy the waters and cause a mental linkage to xcontrols. I'm not exactly sure what I'd call it, but maybe "drop control.vi" or "place control.vi" would make sense?
@hunkel wrote:Regarding the auto-cleanup I'm not sure I'm in favour for that. When dealing with classes it's a natural thing to have a constructor and destructor.
It's not natural to me at all!
Things by reference should be avoided, and if they can't be avoided (like in this case) they should at least behave like everything that is by reference.
That means that if I abort my main (to debug), all references allocated should be closed automatically. I don't want dangling clones, just because I use one of the best features of LabVIEW!
Search LabVIEW like a graph! I added an issue to the QControl Tookit for creating a Place QControl VI. I'm thinking that it will be called "Place QControl.vi" and it will be visible in the root of the QControl class after the QControl is created. If you would like to follow this issue it is being tracked on GitLab at:
https://gitlab.com/QSI_Shared_Code/SharedQControls/QControlToolkit/-/issues/3
It's not natural to me at all!
Things by reference should be avoided, and if they can't be avoided (like in this case) they should at least behave like everything that is by reference.
I'm looking into how I can add this without messing up existing QControls out there. As I said before, the Event Handler already closes if orphaned, so I can call cleanup code there, right after the Event Hander closes. I will have to see if I can keep any destructor from throwing an error because the references are already closed.
That means that if I abort my main (to debug), all references allocated should be closed automatically. I don't want dangling clones, just because I use one of the best features of LabVIEW!
I am not sure who said it in the forums but someone said, "The abort button is like stopping your car with a tree. It works but you might not like the consequences."
That being said, sometimes using the abort is the only thing you can do.
@hunkel wrote:
Here's a thread where the invoke node for LabView classes is briefly discussed. According to AristosQueue this is never going happen.
Yes, that is what I thought I remembered. Might be something technical that makes the feature very difficult or impossible to implement. So, we shouldn't hold our breath.
Meanwhile, in LabVIEW 2019 and newer, when right-clicking on the a class wire (QControls included), there is a sub-menu item that shows a palette with all properties and methods of that class in it, even properties and methods available from parent classes. For LabVIEW 2018 and earlier, you can use the Class Method Browser by MGI. It is executed via a Quick Drop Keyboard Shortcut (QDKS). You can find it here:
https://mooregoodideas.com/mgi-library/class-method-browser/class-method-browser/
@TheQ wrote
I am not sure who said it in the forums but someone said, "The abort button is like stopping your car with a tree. It works but you might not like the consequences."
Sure. Once the car leaves the factory...
I'm talking during development. Which is 99.9% of the time I spend with LabVIEW.
