Close any open files before displaying the message box. In the Windows environment, multitasking imposes some special restrictions on file access that you do not encounter in the standard C environment. Since there may be several applications working with files at the same time, you need to follow some simple rules to avoid conflicts and potential overwriting of files.
The rest of this section lists and explains these rules.
You should close the file before calling the GetMessage function or any other function that may yield execution control. Closing the file prevents it from being affected by changes in the disk environment that may be caused by other applications. For example, suppose your application is writing to a floppy disk and temporarily relinquishes control to another application, and the other application tells the user to remove the floppy disk and replace it with another. When your application gets control back and tries to write to the disk as before, without having closed and reopened the file, it could destroy data on the new disk.
Another reason to keep files closed is the DOS open-file limit. DOS sets a limit on the number of open files that can exist at one time. If many applications attempt to open and use files, they can quickly exhaust the available files.
Summary: Use the OpenFile function to close and reopen files.
To prevent open-file problems, the OpenFile function provides an OF_REOPEN option that lets you easily close and reopen files. Whenever you open or create a file, OpenFile automatically copies the relevant facts about the file, including the full pathname and the current position of the file pointer, in an OFSTRUCT structure. This means you can close the file, then reopen it by supplying nothing more than the structure.
If the user changes disks while working in another application, when your application calls the OpenFile function, the function will fail to reopen your file. If your application specifies the OF_PROMPT option when reopening a file, OpenFile automatically displays a message box asking the user to insert the correct disk.
Ultimately, Windows depends on the DOS file-handling functions to carry out all file input and output. This means that you must follow DOS conventions when carrying out file operations. For example, with DOS, a filename can have from one to eight characters and a filename extension can have from zero to three characters. The name must not contain spaces or special-purpose characters. Furthermore, filenames must be specified in the OEM character set, not the Windows default character set, ANSI.
It is up to you to make sure that your application uses filenames that are the appropriate length and contain the appropriate characters. However, if you use the OpenFile function, you do not have to worry about translating character sets; OpenFile automatically translates filenames from the ANSI character set to the OEM set. It does so using the AnsiToOem function.
NOTE:
All edit controls and list boxes use the ANSI character set by default, so if you plan to display DOS filenames or let users enter filenames, they may see unexpected characters wherever an OEM character is not identical to an ANSI character.
If your application processes international filenames, it must be prepared to handle filenames that do not contain conventional single-byte character values. For such filenames, use the AnsiNext and AnsiPrev functions to move forward and backward in a string. These functions correctly handle strings that contain characters that are not one byte in length, such as strings in machines that are using Japanese characters.
Since more than one instance of an application can run at a time, one instance can end up overwriting the temporary file of another instance. You can prevent this by using unique filenames for each instance of your application.
To create unique filenames, use the GetTempFilename function. This function creates a unique name by combining a unique integer with a prefix and filename extension that you supply. GetTempFilename creates names that follow the DOS filename requirements.
NOTE:
The GetTempFileName function uses the TEMP environment variable to create the full pathname of the temporary file. If the user has not set the variable, the temporary file will be placed in the root directory of the current drive. If the variable does not specify a valid directory, you will not be able to create the temporary file.
As mentioned earlier, your application should not relinquish control while it has open files on floppy disks. If your application uses a message box that's not system-modal, the user can move to another application while the message box is on display. If your application still has open files, switching applications like this can cause file I/O problems.
To avoid such problems, whenever your application displays an alert or error message by using the MessageBox function, it should do at least one of the following:
Close any open files before displaying the message box.
If closing files is not feasible, make the message box system-modal.