Click to See Complete Forum and Search --> : GetOpenFileName error


gecka
September 13th, 2006, 10:10 AM
I've used the search feature and didn't find a solution...

So, I'm using this code:

OPENFILENAME ofn;
char szFileName[MAX_PATH];

ZeroMemory(&ofn, sizeof(ofn));
szFileName[0] = 0;

ofn.lStructSize = sizeof(ofn);
ofn.lpstrFilter = "Text Files (*.txt)\0*.txt\0All Files (*.*)\0*.*\0\0";
ofn.lpstrFile = szFileName;
ofn.nMaxFile = MAX_PATH;
ofn.lpstrDefExt = "txt";

ofn.Flags = OFN_EXPLORER | OFN_PATHMUSTEXIST;

if(GetOpenFileName(&ofn))
SendMessage(hwnd,WM_SETTEXT,0,(LPARAM)(LPCTSTR)szFileName);

Now my app works just fine, but when I try to close it, if I have executed this piece of code before, I get an error "Memory could not be read".

I'm trying to fix this bug for three days now and I'm sure this error occurs only if I open that GetOpenFileName dialog box.
Any ideas?

golanshahar
September 13th, 2006, 10:28 AM
A shot in the dark: Are you using ::GetCurrentDirectory() in your code? Since you don’t use the OFN_NOCHANGEDIR flag your current directory might change, so maybe it is causing you problems?

Cheers

gecka
September 13th, 2006, 10:33 AM
Nope, even if I delete GetCurrentDirectory() function from my code (I use it only once), it still throws me that error when I close my app....
Funny enough this code works well in all my other apps...

golanshahar
September 13th, 2006, 10:40 AM
mmm, if you omit the ::SendMessage(), I mean calling the ::GetOpenFileName () but in the end simply don’t call ::SEndMessage() is it also crashing?

Cheers

gecka
September 13th, 2006, 10:41 AM
mmm, if you omit the ::SendMessage(), I mean calling the ::GetOpenFileName () but in the end simply don’t call ::SEndMessage() is it also crashing?

Cheers
Yes, it is... :cry:

golanshahar
September 13th, 2006, 10:49 AM
Yes, it is... :cry:

Weird, the code for ::GetOpenFileName() looks fine.

Maybe you can post the project?

Cheers

gecka
September 13th, 2006, 10:59 AM
I don't want to post it here (and now, because I will release the source in one forum when it will be ready).
One more question: could that error occur because of pointers? I get this error since I re-wrote my .ini file handling class (it worked fine with old ini class)... and it uses lots and lots of pointers..
If it's because of this class, why does this error occur when I call GetOpenFileName() ?? :ehh:
And thank you for your help, I really appreciate it. ;) :thumb:

Emile
September 13th, 2006, 12:46 PM
I don't want to post it here (and now, because I will release the source in one forum when it will be ready).
One more question: could that error occur because of pointers? I get this error since I re-wrote my .ini file handling class (it worked fine with old ini class)... and it uses lots and lots of pointers..
If it's because of this class, why does this error occur when I call GetOpenFileName() ?? :ehh:
And thank you for your help, I really appreciate it. ;) :thumb:
Hi,

That's the point, I think. When you get a such incomprehensible error, furthermore related to a forbidden memory access , then it's time to re-read all your code. The mistake doesn't lie where you believe.

An uninitialized pointer, a bogus pointer arithmetic or a dangerous casting can be the cause. This usually corrupts an area of memory - you get no trouble at this time - and crash the program several lines after when this memory is used.

gecka
September 13th, 2006, 12:50 PM
Thank you Emile, I've alredy started partial re-coding of the ini class. :)

golanshahar
September 13th, 2006, 02:09 PM
I don't want to post it here (and now, because I will release the source in one forum when it will be ready).
One more question: could that error occur because of pointers? I get this error since I re-wrote my .ini file handling class (it worked fine with old ini class)... and it uses lots and lots of pointers..
If it's because of this class, why does this error occur when I call GetOpenFileName() ?? :ehh:
And thank you for your help, I really appreciate it. ;) :thumb:

If you cant post the project its hard to see what is wrong, since the code looks fine to me I can only think that maybe its because the current directory is changed. Give it a shot with the OFN_NOCHANGEDIR and lets see, maybe there is some relative path somewhere in your code like:


::LoadLibray("..\\..\\mydll.dll");


or:

FILE *fp = fopen("myfile.txt","r");


The examples above would fail if current directory is changed, and if you don’t check return code crash will occur :).

Of course this was just an example there are allot of functions that accept files as parameters.


Cheers

gecka
September 14th, 2006, 08:05 AM
that makes a lot of sense, i'm writing a file almost immediately after getting the filenam... Thank you! :wave:

EDIT: I solved it, I used standart list class instead of my own :) Thank you all for help and attention! :)