File not open for writing

[caruga]

I'm working on a Win32 app in Visual C 2010. If I run the app through the debugger (F5), close it, make a change and then try to compile, it seems the executable file is still locked by the system and can't be overwritten. I'm wondering if this is because my code is failing to do proper clean-up when exiting and that's the reason for the file still being open. So my question is, are there any particular pitfalls I could be falling into here, essential cleanup code I may have missed implementing?

[freddie1]

Is it a GUI app? If so, what are you doing in your WM_CLOSE or WM_DESTROY handler? If you simply x out of a window and your WM_CLOSE and/or WM_DESTROY code doesn't call PostQuitMessage(), the window will indeed be destroyed, but WinMain() will still be waiting for messages in a message loop, but there will be no more living windows to send it messages.

[caruga]

Yes, WM_CLOSE calls DestroyWindow on the window, which sends the WM_DESTROY message which calls PostQuitMessage(0). WM_QUIT returns DefWindowProc. Perhaps worth mentioning that the executable also isn't listed in the Process list of task manager. It's just the SYSTEM maintains a handle to the file...

[freddie1]

Perhaps you should post the code if it will fit (or just applicable WM_CLOSE/WM_DESTROY stuff and how you have the switch constructed with DefWindowProc.

[andywestken]

<deleted not so useful comment...>

[caruga]

I've just tried inserting a message box outside the message loop and it does reach that point of execution. I'm beginning to think it isn't to do with my code but something else. I'll try find a suitable code excerpt but I'm not sure it will reveal much except that it should all work just fine. Right now it's just a nuisance waiting for the system to garbage-collect the handle it's maintaining to the executable so I can recompile. Takes a few minutes but it eventually 'forgets' it.

[freddie1]

That's pretty aggravating caruga. I've never seen that, but I don't have VS 2010 either. I have VS 2008 but don't use it much even though I paid $ 550 hard earned dollars for it. Did you try a release build? Maybe the debug build has something to do with it. I think I'd have a pretty hard time putting up with that.

[caruga]

I've been rather dense in presenting the problem the way I did. I should have started out by simply building the code (F7), making a tiny alteration and then attempting to build again. And what do you know, the file is locked on the rebuild attempt. So it's the fault of VS, probably...

The version i'm using is a release build: Visual Studio 2010 10.0.40219.1 SP1Rel.

[freddie1]

I'm not certain how experienced you are at Win32 coding, but I think most of us have had the problem you are describing one or more times during our learning processes. The Window Procedure or perhaps I should say Windows or the Windows Api is quite sensitive to the return values of messages and to the way the window procedure is set up with regard to break and return keywords, as well as how DefWindowProc() is called. That's why I encouraged you to post code.

What happens when you do a 'Clean' from the top level menu?

For myself, I prefer using simpler IDEs than VS.

[caruga]

It's not the executable; as I wrote in my last post, the error occurs even if I don't run it. I mistakenly ran to the conclusion that it was something the app itself was doing. Doing a bit of browsing suggests it's a known problem with visual studio, without an apparent solution! :(

EDIT: Hmm, seems actually the known problem fails with a different error, where they get "The process cannot access the file '<file>' because it is being used by another process." whereas i'm getting "cannot open <file> for writing".

EDIT: Seems the problem persists even if I close and reopen Visual studio!? It's locked by "SYSTEM" process. This is weird...

EDIT: Seems I can delete the file manually in explorer and then rebuild, so it isn't a file-system lock. Very odd...

[freddie1]

Possibly anti-virus software involved???