QControl Enthusiasts
QControl Usability Improvements
@hunkel wrote:
Here's a thread where the invoke node for LabView classes is briefly discussed. According to AristosQueue this is never going happen.
So, over the Thanksgiving holiday, I tried writing one as an XNode. I have it mostly working. When I finish it, I'll post it in this tread for those that want to beta test it. It works really well in helping someone find available methods of a class and works just like calling the method directly. Also works with any classes not just QControls.
So for the auto-cleanup. I wish I had made it auto-cleanup from the beginning but now that there are a lot of users, I need to keep from breaking any of their code.
The State DVR will be easy to implement without breaking anyone. I can call the cleanup code right after the Event Handler is finished, (which as I said before, it will automatically stop if it has been orphaned), and I can suppress the error if it still called in the destructor (for those QControls that are already in use). This will probably cover 90% of the QControls out there.
For the other 10%, this is if the developer added their own references to the QControl private data. There is a dynamic dispatch VI that the developer is supposed to place their custom cleanup code. I can call this in the same place as above but because it is custom developer code, I cannot suppress an error if it is called again in a destructor.
Therefore, I could add a flag on the constructor asking if you want to automatically run the cleanup code without a destructor. The flag would have to default to FALSE to keep from breaking current users and would only automatically show in new QControls as I would have to add this to the wizard. Older QControls could still add it.
Do you think this is an acceptable solution? I would have to make sure I have it well documented what the flag does. Any other thoughts or ideas.
@TheQ wrote:
@hunkel wrote:
Here's a thread where the invoke node for LabView classes is briefly discussed. According to AristosQueue this is never going happen.
So, over the Thanksgiving holiday, I tried writing one as an XNode. I have it mostly working. When I finish it, I'll post it in this tread for those that want to beta test it. It works really well in helping someone find available methods of a class and works just like calling the method directly. Also works with any classes not just QControls.
Those property accessors also work a class in a DVR...
I think there are good reasons why this isn't implemented for methods, but I wouldn't mind having this ability.
I never use those property accessors though. I like my accessors to be named 'get' and 'set' (not 'read' and 'write'), but after renaming, I get all sort of problems. Find All Instances doesn't work properly and removing them from memory needs a restart of LabVIEW... Not a fan.
Search LabVIEW like a graph!
@TheQ wrote:
So for the auto-cleanup. I wish I had made it auto-cleanup from the beginning but now that there are a lot of users, I need to keep from breaking any of their code.
The State DVR will be easy to implement without breaking anyone. I can call the cleanup code right after the Event Handler is finished, (which as I said before, it will automatically stop if it has been orphaned), and I can suppress the error if it still called in the destructor (for those QControls that are already in use). This will probably cover 90% of the QControls out there.
For the other 10%, this is if the developer added their own references to the QControl private data. There is a dynamic dispatch VI that the developer is supposed to place their custom cleanup code. I can call this in the same place as above but because it is custom developer code, I cannot suppress an error if it is called again in a destructor.
Therefore, I could add a flag on the constructor asking if you want to automatically run the cleanup code without a destructor. The flag would have to default to FALSE to keep from breaking current users and would only automatically show in new QControls as I would have to add this to the wizard. Older QControls could still add it.
Do you think this is an acceptable solution? I would have to make sure I have it well documented what the flag does. Any other thoughts or ideas.
I think that is the next best solution to those that like this feature, and it should hardly bother those against it.
wiebe@CARYA wrote:
Those property accessors also work a class in a DVR...
I think there are good reasons why this isn't implemented for methods, but I wouldn't mind having this ability.
I wasn't planning on making it work with a DVR but that might be possible to make that feature in a version 2.0 or as another XNode. This is my first XNode, so one step at a time.
@TheQ wrote:
wiebe@CARYA wrote:
Those property accessors also work a class in a DVR...
I think there are good reasons why this isn't implemented for methods, but I wouldn't mind having this ability.
I wasn't planning on making it work with a DVR but that might be possible to make that feature in a version 2.0 or as another XNode. This is my first XNode, so one step at a time.
They're tough bastards.
It would be easier with an XNode license. Haven't heard about anyone actually getting one from NI, but if you have contacts you might have a change...
IIRC, FPGA methods used to be XNodes (back in LV8, not sure if\when it changed). I'm not sure if the code is build for reusability. It might be inspiring (to reuse or to avoid tricks).
The DVR trick would add value to me, as the method itself basically provides exactly the same functionality as the method. It's only the ease of selection that adds something. But with the DVR, you'd get new functionality, allowing instant conversion of a 'by value' class to a 'by reference' class. At the expense of increased risks of race conditions of course. I feel like it should be rather easy; simply a little boiler plating to get from the DVR to the embedded type. After that, everything should be the same. But by all means, finish V1 first or course.
wiebe@CARYA wrote:
It would be easier with an XNode license. Haven't heard about anyone actually getting one from NI, but if you have contacts you might have a change...
I'm using hooovahh's editor from LAVA for the XNode. It's a bit tricky for troubleshooting but there is an INI flag that turns on the XNodeWizardMenu that helps.
The DVR trick would add value to me, as the method itself basically provides exactly the same functionality as the method. It's only the ease of selection that adds something. But with the DVR, you'd get new functionality, allowing instant conversion of a 'by value' class to a 'by reference' class. At the expense of increased risks of race conditions of course. I feel like it should be rather easy; simply a little boiler plating to get from the DVR to the embedded type. After that, everything should be the same. But by all means, finish V1 first or course.
I worked for a week and can't get the XNode to recognized different DVR types (different classes in the DVR). It keeps defaulting the terminals to a DVR with a plain double in it no matter what DVR I wire to it. Everything but that worked. I left a branch with all of that code in it and now I'm back tracking to just allowing classes for now. Maybe I'll try again if I can figure out something else.
Are you interested in seeing it anyway?
I added "Add optional Auto-cleanup code" as an issue in GitLab if you are interested. Located here:
https://gitlab.com/QSI_Shared_Code/SharedQControls/QControlToolkit/-/issues/4
I had one more thought on this issue. Should I make the default on all new QControls be TRUE? The default has to be FALSE for current QControls but I could make the wizard set the default as TRUE on new ones.
@TheQ wrote:
I added "Add optional Auto-cleanup code" as an issue in GitLab if you are interested. Located here:
https://gitlab.com/QSI_Shared_Code/SharedQControls/QControlToolkit/-/issues/4
I had one more thought on this issue. Should I make the default on all new QControls be TRUE? The default has to be FALSE for current QControls but I could make the wizard set the default as TRUE on new ones.
I think consistency will be better?
