I have an SDI in which there is a:
AfxGetMainWnd()->PostMessageW(WM_CLOSE);
in the OnInitialUpdate() in the *View class.
The application closes and a few seconds later a
"MFC Application has stopped working"
window appears with the option to
(a) Check online for a solution and close the program
(b) Close the program
(c) Debug the program
Can someone please tell me what I can do to get rid of this problem?
Get rid of the AfxGetMainWnd()->PostMessageW(WM_CLOSE). It's retarded.
Basically, it's closing the windows application immediately. It makes no sense to spin up an SDI MFC application that is going to do that. You might as well write a console application.
And yes, you need to learn how to use the debugger. I'm sure it is telling you exactly what is wrong.
Related
I have created a windows application in C++ and I want to make so whenever I run it, it doesn't steal focus from whichever window is currently focused(or maybe steal the focus and give it back right away). I'm not creating any window so i'm not sure how to change the window style, my program runs in the background.
I couldn't find any answer that worked for C++, is there any way I can do this?
When you start your application by clicking on the EXE or shortcut, Windows Explorer takes focus, not your app. The only way to start your app and not let Windows Explorer take focus is to start your program when Windows starts, via registry key.
Make sure you use the extended style WS_EX_NOACTIVATE when using CreateWindowEx().
See the Microsoft Docs for CreateWindowEx.
I have a C++ software based on MFC (CDialog). When it starts it is always requesting for focus, mean it is blinking in the windows task bar.
The issue is that task bar is suppose to be set in out hide mode (because I have some other UI that are supposed to cover the full screen). But since this software always request focus, windows task bar never hide until I show and hide this piece of software...
I have other MFC softwares that do not have this behaviour but so far I cannot find out what could be the difference !
If someone had a idea that would be nice !
Thanks in advance.
Looks like I am doing some progress...
If I had ShowWindow(SW_SHOWNORMAL); just before the return of the OnInitDialog() function, then I don't get this behaviour anymore.
That is of course not perferct because I would like this application to be minimized and silent at startup, but when I try ShowWindow with other agrument I always get this flashing issue back...
Any other ideas are welcome ! Thanks.
Using mixed managed/unmanaged C++ (Visual Studio 2008) I'm opening a windows form child window from a DirectX application. Weird stuff indeed, but it works, mostly. If I use showDialog() the child window works perfectly, but obviously the main app stops running (until the child is closed). If I use show() life is good, but the child has subtle issues. A textbox works and accepts input for example, but you can no longer use the Tab key to move to different controls. Mnemonics (Alt+hotkey) have stopped working as well.
I'm a huge keyboard shortcut fan, so this is very annoying. To make it worse, I'm not even sure how to Google this issue. Any help would be greatly appreciated.
To resolve the tabbing problem either use a separate thread to create the dialog and call showDialog(), or call IsDialogMessage in your main message loop.
I want to a create dialog box like window before displaying the console window. I haven't actually tried anything yet but was just wondering if it can be displayed as a start-up window.
If you compile your win32 application as a console app, the console window will appear before you get a chance to do anything else.
To get around this, you need to use a windows application - this won't display a console window at all by default. Some time after startup you can then call AllocConsole to create a console window.
I'm not sure, but if it's a windowed application already, it might be worth making your own console window to redirect standard IO. It'll certainly look nicer. If you want the exact behavior of the regular console, such as the same copy/paste, you'd have to reimplement it.
I am instantiating a local COM server using CoCreateInstance. Sometimes the application providing the server takes a long time to start. When this happens, Windows pops a dialog box like this:
Server Busy
The action cannot be completed because the other program is busy. Choose 'Switch To' to activate the busy program and correct the problem.
[Switch To...] [Retry] [Cancel]
I have found mention of a Visual Basic property on the Application object, OleRequestPendingTimeout, that can be used to control the time before this dialog comes up. I can't find any good documentation on this or an equivalent that is useful from C++. Can anyone point me in the right direction?
If you're using MFC, we used to do stuff like this:
// prevent the damned "Server Busy" dialog.
AfxOleGetMessageFilter()->EnableBusyDialog(0);
AfxOleGetMessageFilter()->EnableNotRespondingDialog(0);
Have a look at IMessageFilter and CoRegisterMessageFilter.
To increase timeout call:
AfxOleGetMessageFilter()->SetMessagePendingDelay(nTimeout);
See details here How to prevent the OLE Server Busy dialog box from appearing during a lengthy COM operation