Community Nugget, 05/27/2007

[Ray.R]

---

@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!)

[Darren]

---

JoeLabView wrote:

Really??  It also works on variants? 

---

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

-D

[DavidBoyd]

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

[Darren]

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

[Michael_Munroe]

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.

[DavidBoyd]

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

[Darren]

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

[falkpl]

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

[gnag]

can any one of you plz help me

[tst]

---

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