I have an MFC C++ program that occasionally crashes on an error exit for no apparent reason. My specific query is in the following:
In my overload of InitInstance() there are various checks, as well as setting up resources like events and semaphores. When a normal exit is requested by the user, there is an OnDestroy() message handler that closes everything out, including freeing resources, etc. That bit works fine.
The problem occurs when one of the checks in InitInstance() fails, and the function returns value 0 (causing a program exit). My question is this: In that event, is OnDestroy() automatically called to clean things up, or do I need to run it myself before exiting InitInstance?
If a main window window already exists you should destroy it before, using DestroyWindow. And no, it is not automatically destroyed when InitInstance is exited with FALSE. ExitInstance is executed, but existing windows will closed when the application exits.
Anyhow normales resources like files and memory are freed when the application exists.
Related
So my question is targeted currently at Windows, but knowing the information for OSX would still be useful just to know later incase you have the answer for that.
How my program(s) function:
An initial EXE will run and create a window, this EXE will check and perform updates for the main program and take some user input. After the user input this EXE will start a new EXE (the main program), passing the details from the window so that this new EXE can claim the window and use it. The first program will terminate and the window should not close.
What I need help with:
I know how to create the window, and passing the required arguments through the exe is not something I know, but I dont think I will struggle to find and use that information. My main question is how do I stop the Window from closing when the first EXE terminates because likely the OS will automatically start cleaning things up.
Sidenotes:
Its not a super big deal, I can always start a new program and recreate a window, but I think it would just be a nice aesthetic touch to not have to close the window at all, staying alive and being handled by different programs(potentially at the same time).
I am under the impression that an EXE cannot update itself while running even if the needed files/information/compiled code are not being used so if this is wrong please let me know.
What you're trying to do cannot be done. You cannot transfer ownership of a window to a different thread. This can be inferred from the documentation of DestroyWindows:
A thread cannot use DestroyWindow to destroy a window created by a different thread.
Raymond Chen expands on this as he explains in his blog entry titled Thread affinity of user interface objects, part 1: Window handles:
The thread that creates a window is the one with which the window has an inseparable relationship. Informally, one says that the thread “owns” the window. Messages are dispatched to a window procedure only on the thread that owns it, and generally speaking, modifications to a window should be made only from the thread that owns it.
As far as the OS is concerned, nothing survives the end of a process. This is literally the end. If you need to keep a window around, you cannot terminate the process that owns its owning thread.
I have a dialog-based MFC application which needs to stop Windows Wifi service in order to run correctly, but I want to enable it again when my application exits.
So I thought I'd put the code that restarts the service in the destructor of the main dialog class.
Now it has come to my attention that others put their code which should be run during program termination into a WM_CLOSE message handler.
Both ways seem to work, but I would like to know if there are downsides to either way.
For MFC dialog based application you can place finalization code to application class InitInstance method, immediately after main dialog DoModal call. For other MFC application types (MDI, SDI) finalization code is usually placed to ExitInstance method.
The difference between dialog based application and SDI/MDI applications, is that InitInstance in dialog based applications returns FALSE, and application exits - all action is done in the main dialog DoModal call.
You can prefer to use ExitInstance for all application types, it should work as well.
Edit. If you want to make cleanup code inside of the dialog class, WM_DESTROY (already mentioned by Roger Rowland) is better place than WM_CLOSE. Sometimes we can handle WM_CLOSE message and prevent a dialog to be closed, for example, by asking "Exit the program? Yes - No". In the case you want to use some child windows, they exist in WM_CLOSE and WM_DESTROY message handlers, and don't exist in a dialog destructor. Also, message queue doesn't exist when main dialog destructor is called, so you should not use Windows messaging in this case.
Aim to maintain symmetry: if you are stopping the wifi service in a constructor, then restart it in the same class's destructor. If instead you stop the service in InitInstance, you would restart it in ExitInstance; if as a response to WM_CREATE or some other message, then restart it in WM_CLOSE, etc.
Constructors and destructors have no way of returning an error status, so normally they are better suited for simple tasks such as initialization and memory allocation/deallocation.
InitInstance and ExitInstance, as well as windows messages such as WM_CLOSE, happen at a good spot in the application's lifetime to display error messages if necessary, or to abort in response to error conditions.
The subject says it all. After i closed my app, it stays in the list of processes with some memory. I tried google perf tools and hours of debugging to find the leak.
Are there other tools to test it and find the problem?
Thank you.
My guess is that you have closed the top level window, and thus all its child windows, but you have not closed the app itself.
This does not happen if your program is arranged in a 'normal' way, but if you have, deliberately or by accident, used an unusual arrangement this can happen.
Fixing it, of course, depends on how exactly you have arranged your code. However, here is a suggestion to begin.
The usual way to close the app is to call wxApp::OnExit() which normally occurs when the top level window closes.
Do you have your own class, derived from wxApp? Do you have an override of OnExit()? If not, then make it so and use the debugger to check whether or not it is being called. If it is not being called, work out how to ensure that it is called.
Another idea: use the following to check that your top level window will close the app
bool wxApp::GetExitOnFrameDelete() const
Returns true if the application will exit when the top-level window is
deleted, false otherwise.
If this return false, use the corresponding set to make it so.
A 3rd idea: The application will not exit while there are any top level windows open. So perhaps you have another top level window that is minimized or invisible but has not been closed? Any wxDialog or WxFrame or window derived from these is a top level window and will prevent the application from closing.
A 4th idea: Do you have any globals or attributes of the application object, whose destructors could enter an endless loop? These destructors are called after the windows are destroyed and if one of them does not return you would see the behaviour you describe.
You may try to look at wxWidget's sample folder. You'll find lots of small but complete applications that contain the full init/exit application cycle.
Inspect some samples and compare with your app's workflow.
Yes...problem solved. A TopLevelWindow that was not destroyed. A Memory Leak....stupid mistake.
I have a C++ Win32 application written using Win32 API and I wish to force it to exit in one of functions. Is there something like Exit() or Destroy() or Abort() something similar that would just terminate it?
Aiiieeeeeeeeeeee. Don't do ANY of these things!
exit() and ExitProcess are the equivalent of taking a gun and shooting the process in the face. I hope I don't have to explain why that isn't nice, especially for processes that are holding shared objects like database handles that might be system-wide. I know that's the norm in Android, but this is Windows and we don't do that 'round here.
Calling PostQuitMessage() directly can cause memory leaks. PostQuitMessage() is intended to be called from WM_DESTROY. It is NOT NOT NOT a message intended to be used to ask a window to close. It's a callback mechanism for applications to post their exit code back to the shell. It is intended to populate WM_QUIT with the application exit code. If you call PostQuitMessage() directly, you will bypass WM_DESTROY entirely. This is problematic because many windows--and child widgets--very correctly perform their clean-up in WM_DESTROY. If you skip this message by lying to the window, you will deny components the chance to clean up.
And since we're on the topic, don't call WM_DESTROY directly either. Raymond Chen of Microsoft has a wonderful article where he explains "Sending a window a WM_DESTROY message is like prank calling somebody pretending to be the police". It's sort of the evil-twin of PostQuitMessage. Instead of exiting without cleaning up, you're asking the window to clean up without exiting. The window manager never knows to remove the components, and you're left with a dead orphan window in memory. Sigh.
The correct answer is to post WM_CLOSE. Anything using the default window procedure will correctly notify the window manager to destroy the window which will cascade on to WM_DESTROY then to WM_QUIT as intended.
If you need different behavior than the standard close, the other alternative is to create a WM_USER or WM_APP message. If your window has a "fancy" WM_CLOSE--say, for example, you give the user a prompt "Are you sure you want to exit?"--and you want to skip that, you may define a custom message with WM_USER or WM_APP and call that in its place. Your app-defined message would implement the default close behavior, and the WM_CLOSE that's tied to the system gadgets performs your fancy behavior.
I hope that helps!
PostQuitMessage() is the standard, graceful way of quitting a windowed application.
It will not immediately quit but rather post a quit message that will get parsed by your main loop (if done correctly) and then quit the application.
If you're using a Win32 application with a proper window procedure, you can use the function PostQuitMessage.
If you're working with visual C++, then use:
PostQuitMessage()
ExitProcess is the function to use, else you can use exit, note that neither insure the integrity of the shutdown (ie: you many leak handles etc and threaded operations will be terminated, even if they are halfway through an operation, like a db commit)
Yes, it's exit()
http://www.cplusplus.com/reference/clibrary/cstdlib/exit/
Just return from the WinMain function. If you have a message loop, use PostQuitMessage to break out. Don't try to exit the process in the middle of execution; it's sloppy.
Is there a way to guarantee that your system tray icon is removed?
To add the system tray icon you do:
Shell_NotifyIcon(NIM_ADD, &m_tnd);
To remove the system tray icon you do:
Shell_NotifyIcon(NIM_DELETE, &m_tnd);
What I want to know: what if you application crashes? The icon stays in your system tray until you mouse over. Is there a way to guarantee that the icon will be removed, even when the application crashes? I would prefer not to use structured exception handling for various reasons.
Another case that I want to handle is when the process is killed, but doesn't necessarily crash.
Another thing most programmers forget to check for is if the explorer restarts/crashes. Its nice if the application handle this and recreate its own icon.
Just check for Message WM_TASKBARCREATED and recreate the icon.
You could have a separate, simpler (and thus presumably more robust) program which monitors your application. This program could actually launch your program and then monitor the process. Yeah, this is a very ugly solution.
Personally I would use a Vectored Exception Handler. Yes, it's based on SEH, but you don't have to deal with all the different stack that you might need to unwind.
TerminateProcess() is must more destructive. You really can't guard yourself against that; when it happens your process is dead. No ore instructions are processed, so it does not matter what code there is in your application.
An external application wouldn't really help, would it? It too could crash, or be killed.
Hmm, you can always have an external monitor process call SendMessage with the WM_PAINT message to the system tray window (which you would have to do based on the class of the window). That should remove the icon which is no longer valid.
There are many ways to ensure the call to Shell_NotifyIcon(NIM_DELETE, &m_tnd); in C++ for the case of the application crhashing; using a RAII wrapper over the NOTIFYICONDATA you're using will do the work, for example:
struct NID
{
NID() : icon_data() { icon_data.cbSize = sizeof(icon_data); }
~NID() { Shell_NotifyIcon(NIM_DELETE, &icon_data); }
void Show(HWND w) { icon_data.hWnd = w; Shell_NotifyIcon(NIM_ADD, &icon_data); }
NOTIFYICONDATA icon_data;
};
This is a simplified version of the wrapper but it will illustrate the main idea: if you create an instance of NID in static storage it will be initialized before the WinMain or main call and its destructor will be called on the program cleanup, even if this cleanup is due an abnormal termination.
So, we can use this NOTIFYICONDATA resource wrapped in struct NID this way:
NID nid; // <--- automatic storage duration, cleared after WinMain return
// even if it returns normal or abnormally
int CALLBACK WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
try
{
// GetMessage(&message, NULL, 0, 0) loop ...
// ...
// use nid.icon_data as you please
}
catch (...)
{
// something bad happened...
}
return 0;
}
The example above calls the ~NID() when the program terminates (after an exception or after closing the program), the destructor will call Shell_NotifyIcon(NIM_DELETE, &icon_data); and the icon is deleted from the notification area; this code covers the normal termination and the exception termination, you can read more about this topic in this good answer from NPE:
As for the kill the process case there's no simple way to do this.
I've already tested that std::atexit and std::at_quick_exit functions aren't called after killing the program through the task manager so I guess that you must hook the termination call... it seems a pretty complex task but is explained in this answer from BSH:
When a process is terminated (not closed) nothing realy can be done unless you start do some hooking, either by hooking TerminateProcess or NtTerminateProcess in the Task Manger process
Hope it helps (though is an answer 6 years later lol)
You have to handle the applications exit when crashing some way or another or the icon will not disapear.
Check this out if it can be any help: http://www.codeproject.com/KB/shell/ashsystray.aspx
You can use SetUnhandledExceptionFilter to catch the crash. I normally use it to create a crash dump file so that the crash can be debugged, but there's no reason you can't so some simple cleanup like removing tray icons.
Does not directly address your problem, but this was a very helpful work around for me:
I wanted to avoid confusing system-tray states. So for me, it was sufficient to 'refresh' the notification tray on startup. This was trickier than I first thought, but the following demonstrates a SendMessage solution that simulates a user-mouse-over cleanup that doesn't involve needing to actually move the user's cursor around.
Note that on Windows 7 machines the name Notification Area should be replaced with User Promoted Notification Area.