Problem With FileOpen() and file extensions

[Ron Weller]

I am using Visual Studio 2005 Standard Edition.
In my VB application I am using the FileOpen() function to read in some binary data from a file.
If I select a file like "MyFile.dat" and try to open it, the function ignores it and creates a new file without an extension, just "MyFile", and opens that one.
So when you run the program it looks like none of your files have any data. But actually it is ignoring your files and creating new empty ones without extensions.
As a test I copied one of my files and renamed it without the extension. When I try to open this file it works.

So What's up wih FileOpen()????

[Hack]

What parameters are you using with FileOpen?

Bear in mind that FileOpen is provided for backward compatibility only. Have you ever tried My.Computer.FileSystem.ReadAllBytes(filename)?

[Ron Weller]

FileOpen(1, "MyFile.dat", OpenMode.Binary, OpenAccess.Read, OpenShare.Default)

Actually I was going through a book, entering and using the code from there.
They were using FileOpen(). So far, in VB.Net, I have only used FileStreams. With the appropriate reader, in this case a BinaryReader. I did not realize that FileOpen() was a replacement for the VB6, OPEN. Which explaines why FileGet and FilePut work so much like the old GET #, and PUT #...

The data files I am using contain large blocks of integer values, Short's or Int16's. It uses FileGet() to read them into an array, and then processes the data.

Interesting side bar here: Is there any reason to use Int16 over Short or the reverse Short over Int16?

[Hack]

Scroll down a little on this link. The table describes the base types that the .NET framework supplies for Integers and Floating Points.

[Ron Weller]

I knew that internally they were both the same. I was just wondering if there was a preference. Based on the table. Most other languages (C#, JScript) use Short. Int16 seems more descriptive but if one does a lot of cross or mixed language developemnt, short might be better.