The first step to opening or saving files is finding out the filename to use... of course you could always hard code the name of the file into your program, but honestly that doesn't make for very useful programs most of the time.

Since this is such a common task, there are predefined system dialogs that you can use to allow the user to select a file name. The most common open and save file dialogs are accessed through GetOpenFileName() and GetSaveFileName() respectively, both of which take an OPENFILENAME struct.

VAR
    ofn      : OPENFILENAME;
    FileName : ARRAY [0..MAX_PATH] OF CHAR;
    hEdit    : HWND;
BEGIN
    FileName := "";
    FillMemBYTE(ofn, SIZE(ofn), 0);

    ofn.lStructSize := SIZE(OPENFILENAME);
    ofn.hwndOwner   := hwnd;
    ofn.lpstrFilter := ADR("Text Files (*.txt)"+CHR(0)+"*.txt"+CHR(0)+
                           "All Files (*.*)"+CHR(0)+"*.*"+CHR(0)+CHR(0));
    ofn.lpstrFile   := ADR(FileName);
    ofn.nMaxFile    := MAX_PATH;
    ofn.Flags       := OFN_EXPLORER BOR OFN_FILEMUSTEXIST BOR OFN_HIDEREADONLY;
    ofn.lpstrDefExt := ADR("txt");

    IF GetOpenFileName(ofn) THEN
       (* Do something usefull with the filename stored in FileName *)

Note that we call the procedure FillMemBYTE, imported from the StonyBrook module MemUtils, on the struct in order to initialise it to 0. This is generally a wise practice, as some APIs are very picky about members that you don't use being set to NULL. This way you don't need to explicitely set each member that you don't use.

You can easily find out the meanings of the various members by looking them up in your documentation. The lpstrFilter value points to a double-NULL terminated string, and you can see from the example that there are several CHR(0) throughout it, including two at the end. The CHR(0) (NULL) codes in this string break it up into filters, each one is two parts. The first filter has the description "Text Files (*.txt)", the wildcard isn't required here I just put it in because I felt like it. The next part is the actual wildcard for the first filter, "*.txt". We do the same thing with the second filter except that this is a generic filter for all files. You can add as many different filters as you'd like.

The lpstrFile points to the buffer we have allocated to store the name of the file, since filenames can't be larger than MAX_PATH this is the value that I've chosen for the buffer size.

The flags indicate that the dialog should only allow the user to enter filenames that already exist (since we want to open them, not create them) and to hide the option to open the file in readonly mode, which we aren't going to support. Finally we provide a default extention, so if the user types in "foo" and the file is not found, it will try to open "foo.txt" before finally giving up.

To select a file for saving instead of opening, the code is nearly the same, except for calling GetSaveFileName() we need only change the flags member to options more suitable for saving.

    ofn.Flags := OFN_EXPLORER BOR OFN_FILEMUSTEXIST BOR OFN_HIDEREADONLY;;

In this case we no longer want to require the file exist, but we do want the directory to exist since we aren't going to try and create it first. We'll also prompt the user if they select an existing file to make sure they want to overwrite it.

NOTE: MSDN states the following for the lStructSize member:

lStructSize

Specifies the length, in bytes, of the structure.

Windows NT 4.0: In an application that is compiled with WINVER and _WIN32_WINNT >= 0500H, use OPENFILENAME_SIZE_VERSION_400 for this member.

Windows 2000/XP: Use SIZE(OPENFILENAME) for this parameter.

Basically what this means is that as of Windows 2000 they added some members to this struct, and so it's size changed. If the code above doesn't work for you it's possibly because the size that your compiler used and the size that your operating system (ie. Windows 98, Windows NT4) expected were different and so the call failed. If this happens, try using OPENFILENAME_SIZE_VERSION_400 instead of SIZE(ofn). Thanks to people that pointed this out to me.

Reading and Writing Files

In windows you have a few options as to how you want to access files. You can use the procedures from the ISO modules RndFile, or you can use the procedures available in Windows itself. The latter method is recommended when programming for Windows.

To open files, you can use OpenFile() or CreateFile(). MS recommends using only CreateFile() as OpenFile() is now "obsolete". CreateFile() is a much more versatile function and provides a great deal of control over the way you open files.

Reading

Say for example you have allowed the user to select a file using GetOpenFileName()...

PROCEDURE LoadTextFileToEdit(hEdit : HWND; FileName : ARRAY OF CHAR) : BOOL;
VAR
    hFile       : HANDLE;
    bSuccess    : BOOL;
    dwFileSize  : CARDINAL;
    dwRead      : CARDINAL;
    pszFileText : POINTER TO ARRAY OF CHAR;
BEGIN
    bSuccess:=FALSE;

    hFile := CreateFile(FileName, GENERIC_READ, FILE_SHARE_READ,
                        NIL_SECURITY_ATTRIBUTES,OPEN_EXISTING, 0, NIL);

    IF hFile # INVALID_HANDLE_VALUE THEN
      dwFileSize := GetFileSize(hFile, NIL_DWORD);
      IF dwFileSize # 0FFFFFFFFH THEN
        NEW(pszFileText,dwFileSize + 1);
        IF pszFileText # NIL THEN
          IF ReadFile(hFile, CAST(LPVOID,pszFileText),
                      dwFileSize, dwRead, NIL) THEN
            pszFileText^[dwFileSize] := 00C; (* Add null terminator *)
            IF SetWindowText(hEdit, pszFileText^) THEN
              bSuccess := TRUE; (* It worked! *)
              DISPOSE(pszFileText);
            END;
          END;
        END;
      END;
      CloseHandle(hFile);
    END;
    RETURN bSuccess;
END LoadTextFileToEdit;

There is a complete function to read a text file into an edit control. It takes as parameters the handle to the edit control and the name of the file to read. This particular function has a fair bit of error checking, file IO is one place where a lot of things can go wrong, and so you need to be on the lookout for errors.

Note the variable dwRead. We don't use it except as a parameter in ReadFile(). This parameter MUST be provided, the call will fail without it.

In the call to CreateFile() GENERIC_READ means we only want read access. FILE_SHARE_READ means it's OK if other programs open the file at the same time we do, but ONLY if they want to read as well, we don't want them writing to the file while we are reading it. And OPEN_EXISTING means only open the file if it already exists, don't create it, and don't overwrite it.

Once we've opened the file and chacked to see that CreateFile() succeeded, we check the size of the file so we'll know how much memory we need to allocate in order to read the entire thing. We then allocate the memory, check to make sure the allocation succeeded, and then call ReadFile() to load the contents from disk into our memory buffer. The API file functions have no concept of Text Files so they won't do things like read a single line of text, or add NULL terminators to the end of our strings. This is why we've allocated an extra byte and after we read in the file we add the NULL (00C) ourselves so that we can then pass the memory buffer as a string to SetWindowText().

Once all that has succeeded we set out success variable to TRUE, and clean up as we reach the end of the function, freeing the memory buffer and closing the file handle before finally returning to the caller.

Writing

PROCEDURE SaveTextFileFromEdit(hEdit : HWND; FileName : ARRAY OF CHAR) : BOOL;
VAR
    hFile        : HANDLE;
    bSuccess     : BOOL;
    dwTextLength : CARDINAL;
    dwBufferSize : CARDINAL;
    dwRead       : CARDINAL;
    dwWritten    : CARDINAL;
    pszText      : POINTER TO ARRAY OF CHAR;
BEGIN
    bSuccess:=FALSE;

    hFile := CreateFile(FileName, GENERIC_WRITE, 0, NIL_SECURITY_ATTRIBUTES,
                        CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NIL);

    IF hFile # INVALID_HANDLE_VALUE THEN
      dwTextLength := GetWindowTextLength(hEdit);
      (* No need to bother if there's no text. *)
      IF dwTextLength > 0 THEN
        dwBufferSize := dwTextLength + 1;
        NEW(pszText,dwBufferSize);
        IF pszText # NIL THEN
          IF GetWindowText(hEdit, pszText^, dwBufferSize)>0 THEN
            bSuccess := WriteFile(hFile, CAST(LPVOID,pszText),
                                  dwTextLength, dwWritten, NIL)
          END;
          DISPOSE(pszText);
        END;
      END;
      CloseHandle(hFile);
    END;
    RETURN bSuccess;
END SaveTextFileFromEdit;

Very similar to reading files, the function to write files has a few changes. First of all when we call CreateFile() we specify that we want Read access, that the file should always be created new (and if it exists it will be erased as it's opened) and that if it doesn't exist, it will be created with the normal file attributes.

Next we get the length of the memory buffer needed from the edit control, since this is the source of the data. Once we've allocated the memory, we request the string from the edit control using GetWindowText() and then write it to the file with WriteFile(). Again, like with ReadFile() the parameter that returns how much was actually written is required, even though we don't use it.