Save vs Save As.... OPENFILENAME flags

Sometimes you don't need to Save As perhaps just wanna save to default/existing file..
My DoFileSave() function which saves data to a file looks as follows

Code:

---

// File save dialog
void DoFileSave(HWND hwnd)
{
        OPENFILENAME ofn;
        char szFileName[MAX_PATH] = "";

        ZeroMemory(&ofn, sizeof(ofn));

        ofn.lStructSize = sizeof(OPENFILENAME);
        ofn.hwndOwner = hwnd;
        ofn.lpstrFilter = "Binary Files (*.dat)\0*.dat\0All Files (*.*)\0*.*\0";
        ofn.lpstrFile = szFileName;
        ofn.nMaxFile = MAX_PATH;
        ofn.lpstrDefExt = "dat";
        ofn.Flags = OFN_EXPLORER | OFN_PATHMUSTEXIST | OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT;

        if(GetSaveFileName(&ofn))
        {
                WriteToFile(hwnd);
        }
}

---

What do i change in Flag (or this function) to prevent Save Save dialog box.. I'm adding both Save As & Save on the menu but do not know how to handle Save...

The File Open/Save Dialog is for asking for a filename to save to.
If you already have it (eg Save instead of Save As), then you don't need to open the dialog in the first place.

Quote:

---

Originally Posted by Elysia

The File Open/Save Dialog is for asking for a filename to save to.
If you already have it (eg Save instead of Save As), then you don't need to open the dialog in the first place.

---

I have Save As, but need to change it to Save...

Well, as I said, in "Save", you already have the filename to save to, so there's no point in bringing up the open/save file dialog at all.

You (csonx_p) didn't understand.
When you select File -> Save from a program, it only runs code to call GetSaveFileName if the file has never been saved and hence has no file name yet. Somewhat like this:

Code:

---

void DoFileSave()
{
    if (filename != "")
        WriteToDisk(filename);
    else
        DoFileSaveAs();
}

void DoFileSaveAs()
{
    filename = MyGetSaveFileName();
    WriteToDisk(filename);
}

---

Quote:

---

Originally Posted by iMalc

You (csonx_p) didn't understand.
When you select File -> Save from a program, it only runs code to call GetSaveFileName if the file has never been saved and hence has no file name yet. Somewhat like this:

Code:

---

void

DoFileSave()
{
    if (filename != "")
        WriteToDisk(filename);
    else
        DoFileSaveAs();
}

---

---

coOL! That if statement will help! thnx

Quote:

---

Originally Posted by iMalc

You (csonx_p) didn't understand.
When you select File -> Save from a program, it only runs code to call GetSaveFileName if the file has never been saved and hence has no file name yet. Somewhat like this:

Code:

---

void DoFileSave()
{
    if (filename != "")
        WriteToDisk(filename);
    else
        DoFileSaveAs();
}

void DoFileSaveAs()
{
    filename = MyGetSaveFileName();
    WriteToDisk(filename);
}

---

---

Oh! flip, hang-on... filename is pointed by lpstrFile member of OPENFILENAME... So, by calling DoFileSaveAs() at least once, then lpstrFile is initialized... But now this means OPENFILENAME must be global to keep pointing on filename until i quit the program... So from my function ..

Code:

---

// File save dialog
void DoFileSaveAs(HWND hwnd)
{
        OPENFILENAME ofn;
        char szFileName[MAX_PATH] = "";

        ZeroMemory(&ofn, sizeof(ofn));

        ofn.lStructSize = sizeof(OPENFILENAME);
        ofn.hwndOwner = hwnd;
        ofn.lpstrFilter = "Binary Files (*.dat)\0*.dat\0All Files (*.*)\0*.*\0";
        ofn.lpstrFile = szFileName;
        ofn.nMaxFile = MAX_PATH;
        ofn.lpstrDefExt = "dat";
        ofn.Flags = OFN_EXPLORER | OFN_PATHMUSTEXIST | OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT;

        if(GetSaveFileName(&ofn))
        {
                WriteToFile(hwnd, szFileName);
        }
}

---

... i must declare OPENFILENAME ofn; globally rather so that i may use/test for it's members in other functions... correct????

I think iMalc's code was not meant to be take literally, but rather as pseudo code. You may find that it's better to pass a filename as an argument.

--
Mats

Quote:

---

Originally Posted by csonx_p

Oh! flip, hang-on... filename is pointed by lpstrFile member of OPENFILENAME... So, by calling DoFileSaveAs() at least once, then lpstrFile is initialized... But now this means OPENFILENAME must be global to keep pointing on filename until i quit the program... So from my function ..

... i must declare OPENFILENAME ofn; globally rather so that i may use/test for it's members in other functions... correct????

---

No, no, no. The filename is imalc's example has nothing to do with the OPENFILENAME struct.
It's LOGIC. Pseudo code says "if not filename has been saved, then open save as dialog, else just save."
Can't you implement something like that? It's not exactly difficult.

Quote:

---

Originally Posted by matsp

I think iMalc's code was not meant to be take literally, but rather as pseudo code. You may find that it's better to pass a filename as an argument.

--
Mats

---

Yes but to have the previous state of szFileName (filename which was saved), i either have to return it from DoFileSaveAs() or declare't globally ... Anywayz, think am getting both of u's clearly... @Mats, looked at the Double Buffering issue?

Quote:

---

Originally Posted by csonx_p

Yes but to have the previous state of szFileName (filename which was saved), i either have to return it from DoFileSaveAs() or declare't globally ...

---

No, you don't.
There are several ways around the issue.
First way is return the ofn struct.
Second way is define ofn as global.
Third way is to use a boolean flag to indicate whether or not the user has indeed saved with save as first.
Fourth way is to use a global filename buffer.

There are more, of course.
I'll leave you to figure out which solution might be best.
And having figured that out, you should be able to understand how to implement save.

Quote:

---

Originally Posted by Elysia

Remember that you should keep everything as much C++ as you can (avoid char).

---

I always thought the cson_x code was standard C rather than C++.

And no, I haven't looked at the double buffering, since I'm not quite familiar with how do to that - I've only ever dabbled with Windows API functions, and never had to work on re-drawing something via a double-buffering mechanism. Someone who has done this before will have to help here.

--
Mats

Quote:

---

Originally Posted by matsp

I always thought the cson_x code was standard C rather than C++.

---

Ehm, you might be right. I think I mixed it up with something else - since I have only seen Windows programming and C, but no confirmation of C++...

Quote:

---

Originally Posted by Elysia

Ehm, you might be right. I think I mixed it up with something else - since I have only seen Windows programming and C, but no confirmation of C++...

---

On that note... Is C++ = MFC and C = Win API? ... @Elysia, i code in pure C... I get your point on char's... i have in number of cases used _TCHAR instead which i think is c compatible cause it compiled....

Quote:

---

Originally Posted by csonx_p

On that note... Is C++ = MFC and C = Win API? ... @Elysia, i code in pure C... I get your point on char's... i have in number of cases used _TCHAR instead which i think is c compatible cause it compiled....

---

You can use C++ without using MFC, but the other way around is not possible, as the MFC itself uses C++.

_TCHAR is useful to cope with international characters (e.g. you want your application to cope with Japanese, Chinese or Arabic languages).

--
Mats

MFC is a C++ Framework for creating GUIs. One of many frameworks, in fact. They are lots and lots of frameworks for GUI programming. A lot are written in C++, some in C.
TCHAR is a define that allows your program to be compiled as both char or wchar_t without problems.
Basically, all you do is use TCHAR instead of char or wchar_t and append _T or TEXT around every string literal:
_T("My text")

Then you can compile it either with char or wchar_t without modifications.

Glad to see some of you picked up that it was C++ish pseudocode.
In the case where C is being used, I think passing in the buffer is a good way to go.