ā05-17-2009 01:59 PM
ā05-17-2009 11:52 PM
ā05-18-2009 07:47 AM
On the Mac OS it works as expected. With the Windows path constant it pops up an error dialog "File not found..." With a Mac file path constant pointing to a real file, it runs normally (generating an error 85 due to format mismatch) and with a Mac file path pointing to a non-existent file, it produces the same "file not found..." error dialog.
Lynn
ā05-18-2009 09:40 AM
johnsold wrote:On the Mac OS it works as expected.
What do you mean by "as expected"? The dialog is certainly unexpected IMO. It should never appear and certainly not abort the VI.
ā05-18-2009 10:08 AM
You are right. I did not read the original post carefully enough nor did I read the note on the front panel.
At first I was thinking automatic error handling, but I have that turned off.
Too early on Monday morning.
Lynn
ā05-18-2009 05:08 PM
Hello all,
Thanks for finding this, I have submitted a corrective action request for this. It's in 8.6.1 as well. We really appreciate your help in improving LabVIEW! Please let me know if you need assistance in working around this bug.
Regards,
Anna K.
ā05-19-2009 01:44 AM
Anna K. wrote:
Please let me know if you need assistance in working around this bug.
For anyone wondering, the workaround is simply to check if the file exists before trying to read it. You can do this by calling the File/Directory Info primitive and checking the error output. Or you can use the OpenG File Exists? VI.
I'm assuming this primitive is used rarely, if at all, which is why no one ever reported this. I had it in an old piece of temporary utility code which was moved elsewhere. It had a hardcoded path and when I ran it again a year or so after last using it, I ran into this. The only reason I used the primitive in the first place was because I wanted a quick way to save a number in a file and read it back. I never used it in any real code.
Anna, I don't personally care, but what's the CAR number? Some people do seem to want to know them.
ā05-19-2009 05:34 PM
Hello all,
The CAR number is 168144
Thanks,
Anna K.
ā08-19-2010 12:55 PM
This issue has been resolved in LabVIEW 2010. To look for other bug fixes please review the LabVIEW 2010 Readme.