Data Log File Refnum Type Def Bug??

[Jaegen]

Hello,

I just found some quirky behaviour (LV 7.1.1):

1. In the attached LLB, open "RefnumVI.vi"

2. Select the Data Log File Refnum control and open it for editing (Edit - Customize Control ... from the menu)

3. Close "RefnumVI.vi" but leave "Refnum.ctl" open

4. Select the enum inside the refnum container, and open it

5. Select File - Save As ... and save the enum as "RefnumEnum2.ctl"

6. Close the enum

7. Save "Refnum.ctl", and close it

8. Reopen "RefnumVI.vi" and display its hierarchy (Browse - Show VI Hierarchy from the menu)

Notice that "RefnumVI.vi" still has a link to "RefnumEnum.ctl", even though we saved this as "RefnumEnum2.ctl" earlier.

If you go back to the VI, right click on the refnum, and replace it with itself (i.e. select "Refnum.ctl"), the link disappears.

This behaviour does not happen if I use a Cluster instead of a Data Log File Refnum.  I imagine the difference is that the calling VI needs to know about the structure of the data log file in ways it doesn't need to know about the structure of a cluster, but this still is very counter-intuitive behaviour.  Is this really expected?  Or is it a bug?  Is there any other way to remove the link?

Cheers,

Jaegen

[NathanT]

Jaegen,
      I replicated the issue that you found in LV 7.1 and when I tried the same thing in LabVIEW 8.2, the behavior was not there, so it must have been fixed.

The way that I found that you can avoid the link in LabVIEW 7.1 is to select the enum directly from the VI Hierarchy, instead of from the Refnum.ctl and rename it there.  It will update the name on the VI Hierarchy and not have links to both copies of the Refnumenum.  Feel free to download an evaluation copy of LabVIEW 8.2 and try it out for yourself.

Thanks,

Nathan

[Jaegen]

Nathan,

Thanks for your response - I have 8.2 and am in the process of evaluating how/when to upgrade.

Does this mean that the compiler/linker is behaving differently depending on where you open a type def from?  The reason I'm asking is that I've seen similar behavior when editing a hierarchy of type defs; depending on how I open the low-level type def I'm actually editing, changes will or won't get propagated to other instances properly.

Regarding this actual problem, the issue I had is that the data log file refnum type def exists on many VIs, and thus the incorrect link now exists on many VIs, and I don't see any way of correcting the problem without manually replacing the type def with itself in every location (given there's no "Replace All" feature in LV 7.1.1 ).  However, the hierarchy I'm dealing with was only created for testing, so I don't actually need to fix it .  I'll just know to avoid causing this problem in the first place in the future.

Jaegen

[NathanT]

Jaegen,
      It does look like that is what is happening in LabVIEW 7.1.1 and that it was fixed in later versions.

-Nathan

[pashupathi]

Hi Good Morning,

First of all thanks for sharing pictures in the twetters,

one thing i want to know is that you are using datalog file refnum , with Enum inside it , and taking that reference , 

in my project also we are doing the same but we are giving that to the queue via type casting .

my questing is what is the use of this datalog type ref num , could you please explain me ,

waiting for your reply 

[pashupathi]

pleaase find the attachment

[Andy-K]

Hi pashupathi,

The datalog ref num type points to a datalog file.  The type def of a ref num would be used to convert from some custom reference to a file reference.  The following knowledge base article explains the datalog reference number a little more.  I hope this helps!

http://digital.ni.com/public.nsf/allkb/9E5FEB9618CEEA2486256F33005A7784?OpenDocument