Re: Write Access Error When Using CFileDialog

The error you report is a linker error caused by having a running instance of the program.
I've seen it far too many times in far too many contexts to mistake it for something that
adding a piece of code will induce.

If you are using threads, the most common failure is to have the app "exit" while there is
a thread blocked in the kernel. The process stays around even though the GUI is gone and
you have the illusion the program is not running. Check the Process tab of the Task
Manager, and you will almost certainly see an instance of the program running. Note that
you did not report a runtime error; you reported a *linker* error, and the linker error
clearly states that the executable file cannot be written, and unless you have some weird
set of permissions set up on a server, the cause is that you have a copy of the program
running, somewhere.
joe

On 11 Jul 2006 11:14:52 -0700, "Jon" <TheFakeJon@xxxxxxxxx> wrote:

Thanks Joe for the reply, but this is a dialog based application that
has no toolbar. It's a very simple application, and I do understand
that the code is irrelevant, but unfortunately, the access permission
error only occurs when I push my 'browse' button and execute the code
above, or at least that is what I am lead to assume. Maybe it is just
luck and each time i do execute the browse button, my app happens to
just not want to close?

Thanks


Joseph M. Newcomer wrote:
Code is irrelvant. You're trying to run a link while you have a copy of the program
running. It is reasonably important that you undestand what a compiler does, what a linker
does, and what execution does. Your code won't have any relevance until it executes,
unless it calls a function that you haven't supplied the object file for (in which case
the linker gives an undefined symbol error) or it calls a function you haven't supplied a
definition for, in which case the compiler gives you an undefined symbol error. You did
not get an undefined symbol error. Admittedly the error message explanation in the MSDN is
a bit cryptic, but the reason it doesn't have write permission is that the file is open
because the program is running.

Perhaps you would be effectively served if you deleted the [!] button from the toolbar.
This usually leads to erroneous testing procedures, and it should never be used during
development by beginners.
joe



On 10 Jul 2006 17:03:03 -0700, "Sleepster" <TheFakeJon@xxxxxxxxx> wrote:

void myClass::OnBnClickedBrowseOutput()
{
UpdateData(TRUE);

CFileDialog openDlg( TRUE, _T("*.*"), NULL, OFN_HIDEREADONLY, NULL);

if( openDlg.DoModal() == IDOK )
{
output = openDlg.GetPathName();
UpdateData(FALSE);
}
}


The code above is how I open a CFileDialog in order to grab the path
name. The problem I am having is that when execute my code and click
on the browse button, it seems to work fine. I close my application
and rebuild it, and when I rebuild it, it tells me this:

LINK : fatal error LNK1168: cannot open ../../../bin/myfile.exe for
writing

It does this everytime. In order for me to fix the problem, I have to
go to the project properties and change the output directory so that it
will allow me rebuild. The reason that it cannot open the file for
writing is because the file is still in use, even though the
application is not in use. I ran task manager to check to see if there
are instances of it, and there isn't.

So, I thikn that the problem is that I am using CFileDialog. I am
thinking that maybe the resources cannot be freed and thats why I can't
rebuild my application?

thanks
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.