QControl Enthusiasts

cancel
Showing results for 
Search instead for 
Did you mean: 

QControl Usability Improvements


@TheQ wrote:

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?


Sure. My XNodes knowledge has become a bit rusty though.

 

Not sure what exactly the problem is. Shouldn't XNodes adapt to anything what's wired to them?

 

Or if you have a MWE demonstrating the problem, I could have a look at that.

0 Kudos
Message 31 of 34
(1,099 Views)

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.


I was wrong, which is a good thing in this case. 

 

It must be scripting it right because it is executable and works as expected.  It's when you try to use the XNode debug tools to show you what was scripted; it shows the background VI with the wrong DVR data type.  This VI is just for viewing and isn't the actual running code.

 

So, It Works!

 

I'll spend some time cleaning up the code and package it for you and anyone else to test.

Quentin "Q" Alldredge

Chief LabVIEW Architect, Testeract | Owner, Q Software Innovations, LLC (QSI)
Director, GCentral | Admin, LabVIEW Wiki | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner



Message 32 of 34
(1,091 Views)

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

https://forums.ni.com/t5/LabVIEW/How-to-get-a-LabVIEW-class-object-to-expose-an-invoke-node/td-p/499...


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.


This Xnode has some similarities to what you have been talking about.  I keep it on the :"Cluster, Class & Variant" palette.  Drop it onto a BD, wire a class or class DVR, select a method from the dropdown list, and it replaces itself with that method.  In the list, class ancestry levels are separated by a horizontal line; methods that take a class input on their upper left terminal have "(o)" prefix on their name, and  methods that take a class DVR input on their upper left terminal have "(r)" prefix on their name,

"If you weren't supposed to push it, it wouldn't be a button."
Message 33 of 34
(1,070 Views)

Just a heads up on progress.

 

I have completed and published the Class Method Node.  It is just a beta at this point and can be downloaded at VIPM.io at:

 

https://www.vipm.io/package/qsi_class_method_node/

 

I have also presented on the Class Method Node recently at the Dutch User Group and the Chicago User Group if you want to learn more.

 

https://forums.ni.com/t5/DutLUG/Meeting-18-03-2021/td-p/4119516

https://forums.ni.com/t5/Chicago-LabVIEW-User-Group/Q2-User-Group-Meeting-info/td-p/4147762

 

 

As for the auto-cleanup, turns out it is not possible. At the point the cleanup would occur, the owning application has already left memory. This causes the references that would have been cleaned to already be leaked and not closable. This is because the references are tied to the life of the owning application. Therefore, the only way to truly close them cleanly is to close them while the owning application is still alive but is closing itself. This can only be done by using the Destructor in the closing/cleanup code of the owning application.  I have closed the issue for now unless anyone has some advice on how to do it.

 

There still is code that keeps the Event Handler from being orphaned.  It detects if the Destructor is not used and the owning application shuts down. This will cause the Event Handler to end but doesn't properly close other references. This is a fail-safe to keep from locking your application and not the "safe" way to shut down.

 

 

The last improvement I haven't implemented yet.  It was to include a merge VI to make it easier to place the control, control reference, and the Constructor down at the same time. (See Issue #3.)

Quentin "Q" Alldredge

Chief LabVIEW Architect, Testeract | Owner, Q Software Innovations, LLC (QSI)
Director, GCentral | Admin, LabVIEW Wiki | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner



0 Kudos
Message 34 of 34
(997 Views)