Not really sure what it is but you could take a look at my implementation for reference (or just use it )

It handles open and save and you can use it like this:


CeFileDlg dlg;
dlg.addFilter("XML-Document", "xml");
std::string fname;
dlg.showOpen(fname);


.h

#pragma once

#define MAXFILENAMESIZE 1024

class CeFileDlg
{

public:

CeFileDlg(void);
~CeFileDlg(void);

bool showOpen(std::string& fname);
bool showSave(std::string& fname);
void addFilter(std::string title, std::string extension);
void clearFilter();

private:

bool show(std::string& fname, bool open);

OPENFILENAME ofn;
std::string filter;
std::string defExt;
};


.cpp

#include "PCH.h"
#include "CeFileDlg.h"
#include "Ce.h"

CeFileDlg::CeFileDlg(void)
{
ZeroMemory(&ofn, sizeof(OPENFILENAME));

ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = NULL;
ofn.nMaxFile = MAXFILENAMESIZE;
ofn.lpstrFileTitle = NULL;
ofn.nFilterIndex = 1;
ofn.lpstrInitialDir = NULL;
ofn.nMaxFileTitle = 0;
ofn.lpstrFilter = "\0";
}

CeFileDlg::~CeFileDlg(void)
{
}

void CeFileDlg::addFilter(std::string title, std::string extension)
{
filter.append(title);
filter.push_back('\0');
filter.append("*.");
filter.append(extension);
filter.push_back('\0');

defExt.clear();
defExt.append(extension);

ofn.lpstrDefExt = &extension[0];
ofn.lpstrFilter = &filter[0];
}

void CeFileDlg::clearFilter()
{
filter = "";
ofn.lpstrFilter = "\0";
}

bool CeFileDlg::showOpen(std::string& fname)
{
return show(fname, true);
}

bool CeFileDlg::showSave(std::string& fname)
{
return show(fname, false);
}

bool CeFileDlg::show(std::string& fname, bool open)
{
char szFile[MAXFILENAMESIZE];

ofn.lpstrFile = szFile;
ofn.lpstrFile[0] = '\0';

if(open)
{
ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST | OFN_NOCHANGEDIR | OFN_NONETWORKBUTTON;
GetOpenFileNameA(&ofn);
}
else
{
ofn.Flags = OFN_PATHMUSTEXIST | OFN_NOCHANGEDIR | OFN_NONETWORKBUTTON;
GetSaveFileNameA(&ofn);
}

fname = ofn.lpstrFile;

return !fname.empty();
}


What does "it's not working" mean?

Do you get compiler errors? Linker errors? Runtime errors? Unexpected behavior?


We can't help you if we don't know whats wrong.

My guess without more information is a unicide problem, as all modern (say within the last 10 years) visual studio projects default to unicode, so UTF-16 version of GetOpenFileName are going to be used by default. The non-unicode versions of the functions exist for backwards compatibility with Win9x apps for the most part and shouldn't be used.

You can explicitly call the ascii version GetOpenFileNameA, but you are almost always better off using GetOpenFileNameW and using wchar_t instead of char. The unicode settings of the project dictate which function the macro GetOpenFileName really points to.

When using the unicode versions of the APis, this also means you need to convert strings made of char[] or std::string to utf-16 with something like MultiByteToWideChar before sending it to GetOpenFileName.

Personally I perfer using UTF-8 globally in applications if possible, and only convert to UTF-16 when dealing with the windows API directly.