Questions about file I/O


brian.zuelke

Recommended Posts

I had a few questions about direct file access.

(1) Is there any way to use relative directories instead of absolute directories? For example, when I call MakeDirectory(".\Folder\"), the File object always creates "Folder" in "C:\". Is there a way to have MakeDirectory create the new directory in whatever directory the current .CTL file is located?

(2) Say I use Handle = File.Open(FileName, 0, 1, 0, 0) to open a file having 200 bytes of data, and then call File.Write(Handle, StringOfLength100) to overwrite it with a string comprised of 100 bytes of data. Will the 200 bytes present in the file be erased, or will only the first 100 bytes be overwritten, leaving 200 bytes of data in the file

Regards,

Brian

Link to comment
Share on other sites

1) yes, you can use relative directories, but knowing what directory is the current directory is tricky, and in fact, starting DAQFactory in a way that allows another directory to be the current directory is actually a security issue (true with many programs). I just started DF normally (using c:\DAQFactory as the current directory) and did File.MakeDirectory(".\folder") and it made a subfolder under c:\DAQFactory. In general, if you don't want it under DAQFactory you are better off querying the user for a directory (using File.FileOpenDialog()) or just using a variable and prepending it to your folder.

2) I don't know. You should just try and find out. We simply call the OS functions for low level file I/O so its up to the OS.

Link to comment
Share on other sites

I should probably provide some context for #2: http://www.azeotech.com/board/index.php?/topic/4686-saving-user-settings-in-global-variables-over-a-restart/.

Let's say I change the settings class instance to have fewer variables than previously defined. At that point, the settings file on disk now has more bytes than the settings file that will be saved to disk. So I .Open(FileName,0,1,0,0) and save my new settings instance to file. Unless there is some sort of EOF marker in the file, the bytes related to the old settings class definition could still be read in when the settings file is read again. Have you seen any evidence of this when you've used your method of settings management?

Regards,

Brian

Link to comment
Share on other sites

But I just checked and it appears that the file is truncated if you don't have the append flag set.

Also, if you are going to write a string (even a json string), you should open the file with the Text flag (the last flag) set to 1. This will cause a CRLF to be added to the end, which makes it easier to read the string back.

Link to comment
Share on other sites

  • 1 year later...

Going back to Brian's #1, being able to fetch the directory of the CTL file being used would be extremely valuable. I'd like my project to be fairly portable without needing to have the user select the directory that my DLLs reside in (they are packaged with the CTL).

Admittedly I can save this location to the registry so it's a one-time deal, but then I can't have multiple copies of the project in different locations on the user's drive without loading DLLs from the wrong place. Edge cases, maybe, but it seems harmless to be able to get the project file's directory at runtime. I was surprised to find out on this thread that you can't do it.

Side note: Since I'm running a handful of DLLs anyway, is there anything I can do in a DLL call to get this information? If not I may have to use a batch file or similar to start DAQFactory instead of the CTL, and save off the directory that way.

Link to comment
Share on other sites

Its actually easy to set the default directory by creating a shortcut and specifying the startup path there. The problem is that so many people click on the .ctl document to start the app. This is actually bad practice if you need a predictable start-in folder, because then its largely up to Windows.

Link to comment
Share on other sites

  • 3 weeks later...

In general? Go through the guided tour. That will cover the basics.

If you know the basics and are asking the best way to approach a new project, I usually recommend figuring out the communications first: get it so DAQFactory acquires data. Once you have this, doing everything else is usually much easier because you actually have data to work with. Also, communicating with devices is often the most challenging part, largely due to lack of total standards and poor documentation on the hardware manufacturers part.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.