LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Community Nugget, 05/27/2007



@Darren wrote:

P.S. - Someday, the on-line help for Empty String/Path? will indicate that it works on variants, pictures, etc.


Really??  It also works on variants?  (not that I doubt you... just surprised!) Smiley Surprised
0 Kudos
Message 11 of 24
(4,841 Views)


JoeLabView wrote:

Really??  It also works on variants? 


Looks like some of you guys need a nugget refresher... 🙂

-D

0 Kudos
Message 12 of 24
(4,836 Views)

Maybe yes, maybe no...

I hate to be picky, but perhaps a clarification is in order.  The 'Empty String/Path?' node works for LV variants which are void.  But the OLE variants as typically returned by ActiveX (encountered a lot when using the DB Connectivity toolkit, or some of the Excel/Word automation stuff) don't seem to ever test as 'empty', even when they're of value VT_EMPTY or VT_NULL.  (For the record, I think a good argument can be made in either direction, depending on whether you expect LabVIEW to know about the content of an OLE variant.)

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 13 of 24
(4,832 Views)

You're right.  The Empty String/Path trick works only for LabVIEW Variants.  The OLE Variants deal with "emptiness" in a strange way...it's the primary reason why the Database Connectivity Toolkit has its own function for converting variants...the Database Variant to Data function works *almost* identically to the Variant to Data function...the only different I know of is the manner in which empty variants are handled.

Good clarification, David.

-D

0 Kudos
Message 14 of 24
(4,823 Views)

Nice nugget tst.

I used this method last year to develop a driver for an Agilent cell phone tester.  Using this feature allowed support for over 3000 GPIB parameters into only about 600 VIs.  By providing invalid default values for all inputs of a VI that contained 5 or 6 "related" functions, the user could wire only the parameters that needed to be changed.  The driver would then strip the commands of the unwired inputs and send only the wired commands.  More inputs on fewer VIs also greatly reduced the number of sub-pallets for the driver compared to the similar Rhode & Schwarz driver.

Michael Munroe, CLD, CTD, MCP
Automate 1M+ VI Search, Sort and Edit operations with Property Inspector 5.0, now with a new Interactive Window Manager!
Now supports full project automation using one-click custom macros or CLI.
0 Kudos
Message 15 of 24
(4,820 Views)

Thanks, Darren, for confirming this.

Perhaps you could shed some more light on some of these dusty corners of LabVIEW related to OLE varmints variants.  Besides the Database Variant to Data primitive exposed on the DB tools palettes, there is also a primitive called To OLE Variant which doesn't appear in any of the shipping palettes.  I keep carrying it forward from LV version to LV version, since it's the only way (I know of) to generate an OLE variant wire with value VT_NULL (LV won't preserve an OLE variant BD constant of this value).  Is this node dangerous or something?  'Cos the help window description (for at least the last three LV releases) declares the node obsolete/unsupported.

My recollection on the Database Variant to Data primitive was that it fixed a problem with VT_NULLs not converting correctly with the more common Variant to Data node.  I was wondering if that behavior could've been 'fixed' and the two nodes 'merged'.

Sorry to hijack the thread...

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 16 of 24
(4,790 Views)

I had forgotten about To OLE Variant...I couldn't find any information regarding why it was deprecated.  And I'm surprised an OLE Variant BD constant won't persist a null value.  Depending on how strongly you feel about this deficiently, perhaps a Product Suggestion entry or a bug report is in order...

-D

0 Kudos
Message 17 of 24
(4,783 Views)

Why not (besides the extra work) make the VI polymorphic.  Have a version which has a required input such as defer FP updates and anouthe version which does not expose this option but makes it some default value like T.  I run into this exact problem with action engines where various modes of operation require diferent input signatures.  In OO programming you would have a polymorphic version where "unwired" inputs would change the function called.  I would like to see an automatic polymorphic function in labview to handle this exact problem.  I have run into situations where there is no good "default value" especially with booleans and shift registers.  Good topic, I have been stumpt for a good solution on this one for a while.

 

Paul

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
0 Kudos
Message 18 of 24
(4,783 Views)
can any one of you plz help me
0 Kudos
Message 19 of 24
(4,777 Views)


@falkpl wrote:

Why not (besides the extra work) make the VI polymorphic.  Have a version which has a required input such as defer FP updates and anouthe version which does not expose this option but makes it some default value like T.


I didn't exactly understand what you describe here (for example, how would the user select between the VIs), but in any case, you should note that in this example the key is not the boolean input, but the VI reference input.
As I explained, it was a quick example and the boolean should simply have been made a required input (as it was in the second post).


___________________
Try to take over the world!
0 Kudos
Message 20 of 24
(4,774 Views)