AVI File Reference

[Yuri33]

The IMAQ AVI file reference has a lot of strange properties that make it rather inflexible and hard to use. Chief among these is the fact that the "Not a Reference" primitive in LV always returns false no matter if the AVI file reference is valid or not. Does anyone have a way to reproduce the proper functionality? I've tried a number of things, including typecasting to another reference type (including the a datalog reference, since it seems related to that) and trying to use AVI File Info and trap the error. Nonething works. Is there any test to see if an AVI file reference points to an open file (whether it's a write session or a read session?). I'd settle for a write session only version if that's the only thing possible.

[Rolf Kalbermatter]

QUOTE(Yuri33 @ Jul 5 2007, 10:52 PM)

The IMAQ AVI file reference has a lot of strange properties that make it rather inflexible and hard to use. Chief among these is the fact that the "Not a Reference" primitive in LV always returns false no matter if the AVI file reference is valid or not. Does anyone have a way to reproduce the proper functionality? I've tried a number of things, including typecasting to another reference type (including the a datalog reference, since it seems related to that) and trying to use AVI File Info and trap the error. Nonething works. Is there any test to see if an AVI file reference points to an open file (whether it's a write session or a read session?). I'd settle for a write session only version if that's the only thing possible.

IMAQ AVI file reference is not a proper LabVIEW refnum, but a private implementation to the IMAQ AVI library. So the Not A Refnum prmitive can't work there as it is strictly always not a valid LabVIEW refnum.

What you can do is either try to typecast the refnum into an int32 and if it is not 0 then assume it is valid or probably even more safe use the IMAQ AVI Get Info function. If it returns no error then it is definitely a valid refnum. Of course the issue about why you would need to find out after the fact if it is a valid refnum does hint that you probably do not do proper error handling of the Create or Open function.

Rolf Kalbermatter

[crelf]

QUOTE(rolfk @ Jul 6 2007, 03:02 PM)

IMAQ AVI file reference is not a proper LabVIEW refnum, but a private implementation to the IMAQ AVI library.

Rolf's right - in fact, all the IMAQ refnums are private implemenations. The only way to get "in" to them is to use non-bound property nodes on the wire, although that won't work on the IMAQ-AVI refnum. I think your only option is to either keep a memory space alive that contains the path of the AVI and check it (as a normal file) when you need to, or maybe have a dig around in the DLL that the IMAQ AVI VIs call - there might be something in there that you can use (if you can work out the DLL prototypes ) - Good luck!

[LAVA 1.0 Content]

:arrow: I suspect it is the same for database connections refnums when using the "open DB connection" of the DataBase toolkit.

[Yuri33]

1) I've tried typcasting to check for a non-zero number, but the same number remains even after a read or write session is closed.

2) IMAQ AVI Get Info only works on read sessions. It will always return the same error for write sessions, whether the reference is valid or not.

3) I do proper error checking, but I like to protect all the relavent functions with reference validity checks first. In fact, I'm pretty sure that's one of the first things done in the dll calls themselves. If an error is produced on the Open or Create function, then I output a null reference. But the question is how to check if that reference is really null down the line. I have a multithreaded application that captures a video stream and dynamically writes the data to disk. The capture and the write\display sections are contained in seperate loops, with frames of data transfered via queues (of flattened images). I only want to write data when I've opened a file for doing so (which itself is in a seperate UI loop), and discard the data otherwise. So that is why I want to check the AVI File reference.

4) The problem with checking for the presence of the file using normal "file exists" functions is that the AVI Create function doesn't actually write anything until the first frame is written. If you open a write session and then close it without writing any data, no file is created.

5) I'll see if any glaring reference check calls exist in the Vision dlls, but all in all it's bad form not to include a reference check function. If the primative can't be used, then usually LV provides that function (e.g., semiphores). It's also rather strange that other Vision references, such as an IMAQ session reference, do work with the Not a Ref primative while the AVI file reference does not.

I suppose I could simply try to write a frame and trap the error if the reference is bad, but that's rather inelegant. Additionally, I would probably have to carry extra information as well, such as the frame size (IMAQ AVI Write thows an error if you change the size of the image midstream, though I don't know if that error overrules an invalid reference error). It might even be quite inefficient, if the dll call does other things before checking the reference itself (allocating memory, etc.). In my application, where many data streams are being captured and recorded in parallel (video, digital and analog data, serial port data, etc), efficiency is important.

[crelf]

QUOTE(Yuri33 @ Jul 7 2007, 12:37 AM)

I suppose I could simply try to write a frame and trap the error if the reference is bad, but that's rather inelegant.

It's ineligant, but I think it's your best bet...