custom refnum - what is the underlying numeric type of refnums and how do I comply with the subtype

[Steve_Mowbray]

Specific refnum I am planning using is based on the byte stream file refnum - and will be passed in and out of a DLL via code interface nodes - would it be U32 or I32 underlying type or something else?

I am basing the sub-type concept on the following online reference:

http://labviewwiki.org/Refnum

Is the above correct and how are the 8 bit values encoded into the refnum numeric type (MSB's or other?)

[rolfk · Accepted solution]

The subtype is not coming into play here nor can you do anything in external code to change it. The refnum itself is a MagicCookie (definition in extcode.h) and is an opaque value that together with the type of refnum, that is implicit, determines the resource for LabVIEW.

So include extcode.h from your <LabVIEW>/cintools directory, declare it as a MagicCookie or LVRefNum, which is an alias for a MagicCookie. There are no C interface functions to directly work with a LVRefNum for a datalog file nor a bytestream file but for the bytestream file you can use the FRefNumToFD() function to get the underlaying file descriptor and then use the FM*() functions that take a File datatype to read and write from that file.

[Steve_Mowbray]

Thanks for prompt and clear response

Exploring extcode.h I gather the following:

- underlying type for refnums is U32

- I can use the file manager API to create a new refnum eg FNewRefNum(ConstPath, File, LVRefNum*);

- refnums can be converted to its file descriptor using FRefNumToFD(LVRefNum, File*);

- labview file manager functions can be used to access the file OR the file descriptor can be passed to my own custom code functions (I hope)

Many Thanks

Steve

[rolfk]

---

@Steve_Mowbray wrote:

Thanks for prompt and clear response

- labview file manager functions can be used to access the file OR the file descriptor can be passed to my own custom code functions (I hope)

---

That last one is undocumented and may not work on all LabVIEW platforms. It is true for older 32 bit versions of LabVIEW but may change at any time at NIs discretion since they never documented that nor guaranteed that it might work that way.

Also on Windows there are several different file descriptors possible. First you have the WinAPI HANDLE, then the C runtime "int fd" and FILE datatypes. All of them are not the same, but the LabVIEW File did in the past map to the HANDLE. 

[Steve_Mowbray]

okay in that case I will avoid mixing and matching read/write through the refnum

Thanks for that follow up

Cheers

Steve

[rolfk]

I didn't mean to indicate that you can't read and write to the same refnum, although you definitely should know what you do there, as one byte at the wrong position in the file stream might corrupt your data.

What I meant is that you should only use the FM*() functions to work on the underlaying file descriptor, not trying to use any WinAPI functions or C runtime functions directly.