Not A Refnum - Behaving poorly since ?

[mje]

This came by and bit me in the behind again:

Basically, that the Not A Refnum primitive returns true for non "native" types of refnums even if they are valid refnums. Why does this primitive even allow refnums to be used when the behavior is at best inconsistent? I swear it should either behave properly or be removed from the palette.

Sorry, venting. I know this is a well documented bug feature, has been so for some time, and the "proper" way of dealing with these refnums is using the Not A X Refnum.vi methods, but seriously? This primitive ends up more often being a source of bugs for me than not. I guess the C-style programmer in me just can't stop thinking of code such as:

if (pRefnum){    // Operate}else{    // Panic!}

Sigh...

-m

[jdunham]

Couldn't agree more. I goofed that up last week for the 400th time. If NI can detect the error cluster and allow special functionality for that, how hard could it be to fix the Not-a-refnum primitive?

[bmoyer]

Or they could expand the Help details to include not working with Config refnums. I never looked at the detailed help for this function and was surprised at its limitations. Maybe it would be more helpful to describe what functions it does work with instead of what it does not.

Bruce

Not A Number/Path/Refnum? Details

This function works only on references generated by LabVIEW functions. Do not use this function to determine the validity of a rendezvous refnum, semaphore refnum, or any refnum created by the GOOP wizard, LabVIEW Database Connectivity Toolkit, or LabVIEW Internet Toolkit. For rendezvous refnums, use the Not A Rendezvous VI. For semaphore refnums, use the Not A Semaphore VI. For all other GOOP refnums or toolkit refnums, use the VIs defined by the refnum creator.

[Aristos Queue]

Not A Number/Path/Refnum? Details

This function works only on references generated by LabVIEW functions. Do not use this function to determine the validity of a rendezvous refnum, semaphore refnum, or any refnum created by the GOOP wizard, LabVIEW Database Connectivity Toolkit, or LabVIEW Internet Toolkit. For rendezvous refnums, use the Not A Rendezvous VI. For semaphore refnums, use the Not A Semaphore VI. For all other GOOP refnums or toolkit refnums, use the VIs defined by the refnum creator.

The reason that it cannot ever be fixed for these types is that these types are hacks. They use the Type Cast primitive to cast over to be datalog file refnums, but they are not actually datalog file refnums. The "Not A Refnum" primitive does work for datalog file refnums, and it is correctly returning FALSE that these refnums are not valid datalog file refnums. Take a look at the circled part of the Context Help for a Semaphore wire...

[Rolf Kalbermatter]

The reason that it cannot ever be fixed for these types is that these types are hacks. They use the Type Cast primitive to cast over to be datalog file refnums, but they are not actually datalog file refnums. The "Not A Refnum" primitive does work for datalog file refnums, and it is correctly returning FALSE that these refnums are not valid datalog file refnums. Take a look at the circled part of the Context Help for a Semaphore wire...

The logical and real "fix" would have been to use user refnums, which are available since at least LabVIEW 7 or so. And allow us mere mortals to use them too, without having to revert to reverse engineering them!