I have embedded VLC player into an MFC MDI application. Whenever I close the child frame which contains the embedded VLC platyer, a messagebox with the following message pops up "Encountered an improper argument". If I close the application after this messagebox pops up. It doesn't close. The application goes to background and then I have to go to Task Manager and kill the application.
This happens only in the Release build. I never encountered this error in the Debug build.
Please let me know how to solve this problem.
"Encountered an improper argument” will pop up when you try to access a control which is defined but is not part of the current scope. For example if you have several forms / views and you try to access a control from another form / view.
I would look at:
BEGIN_MESSAGE_MAP
,
DoDataExchange
and so on, and check that each ID is within the scope of the current page / view / form / dialog.
Sorry, I solved this problem. I had written wrapper class around the libmysql in my application. The problem was due to some memory leak happening in my wrapper class.
Related
I have a multi-threaded application with several supporting DLLs and several popup dialogs. My Main App loads all DLLs on startup, which creates all popups, but they are kept hidden until needed.
When the user presses a button in the main app, a particular popup is shown (from the DLL) by calling ShowWindow( SW_SHOW ) (modeless)
Sometimes (1-in-10 times?) the popup simply fails to show and the Main App hangs. OnShowWindow of the Popup dialog is never called. I have tried calling ShowWindowASync instead, and it still fails to show the popup sometimes, but this call doesn't lock the Main App.
This problem only affects popups within a single DLL.
If the popup shows the first time ShowWindow is called, it can be closed and re-opened indefinitely throughout the lifetime of the Main App. If (using ShowWindowASync), the popup fails to show, it will never show during the lifetime of the Main App. I can re-run the application (without rebuilding anything) and there is a hit-or-miss chance that it will work or fail. I haven't been able to identify any predictive conditions or properties.
I have used tools to renumber all of my resource elements so that there are no conflicts throughout the solution.
UPDATE:
I used Winspector to get some information about the dialog when it does and does not work.
When the dialog works (shows properly), Winspector reports that my dialog has valid position (10,96, 1015, 514), style attributes that match the resource template, ID of 0 (not sure what ID means), and the "Owner EXE" is "MyApp.exe" - I can see many messages passing in and out of the dialog, including WM_SHOWWINDOW.
When the dialog fails (does not get a show window message), Winspector reports position (-1512, 190, -517, 634), style attributes that do not match the resource template, ID 509290824, and owner EXE is "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe" - I also do not see ANY messages in the message viewer within Winspector when the dialog fails to show.
Clearly, the dialog is not getting created correctly. CDialog::Create never fails for me. Additionally, I experience this problem in release (not using Visual Studio) so it's not a VS-specific problem.
The dialog was getting created from a thread that was not executing a message pump. This was the root problem. I had tried to initialize all dialogs (i.e. call "Create") from an "init" thread, and then use them later on in the winproc/GUI thread. Can't do this apparently.
A pointer to the dialog was then retrieved into the winproc/GUI (which has a message pump), but by that time, the dialog was already "corrupt" and no longer responding to winproc properly
I'm writing a plugin for a big x64 application in C++. I want the plugin to open a dialog and show a web view of my site.
I'm been able to use WKWebView in macOS and it works well. On Windows I'm evaluating CEF https://bitbucket.org/chromiumembedded/cef (please let me know of any alternative, ideally I would like it to be Webkit-based).
Let's say the application framework that is hosting my plugin has already created a window for my plugin and has it's own message loop, so I can only receive events in a sort of WindowProc. I can also get the HWND of the window.
My implementation is inspired by cefsimple example, because cefclient is way too complicated. I've implemented the subprocess architecture with the external executable and everything works fine until it's rendering the client area of the window. Then I have problems with closing the window (it crashes) and resizing the window interactively (the window frame is resized but the web view in the client area does not resize).
I've tried all possible combinations, but I've run out of ideas. Namely:
If I use CefRunMessageLoop() the web view is rendered correctly but the main application does not process the UI events like close window button. Resize does not work.
If I call CefDoMessageLoopWork() myself once in a while (from WindowProc) the web view is rendered correctly and it processes the close button, but it crashes. Resize does not work.
If I use settings.multi_threaded_message_loop = true the web view is rendered correctly and I can close the window without crash. The destructor of the window calls CefShutdown(). But if I try to reopen the window it crashes! Are CefInitialize and CefShutdown allowed to be called only once?
And resizing still does not work. I don't understand why in the cefsimple example resizing works and in my window it does not work.
Besides message processing issues, probably I'm not closing the browser correctly, any advice? Why is so complicated? WKWebView is so straighforward!
There is no error message, no stack trace, no source code, no OS/CEF version - I doubt this question can be answered.
I can only tell you how to close browser cleanly: call CefShutdown at the right time (see cefclient/cefsimple examples) and do not keep any references to CEF objects when calling shutdown.
I have a MFC application (Visual Studio 2010) which dynamically creates and destroys lots of editboxes, drop-down boxes, and buttons, based on the user's consequent input.
I used "Create" function to dynamically create controls, and when deleting controls the system first calls "DestoryWindow" function for each control, and then delete each control pointer.
After iterating certain amount of creating/deleting controls, if I try to "open" the dropdown menu, the system fails to open it and stops responding to my input - but I can add more controls, if I do not try to open the dropdown menu.
Could somebody please let me know how to workaround this strange issue? This one nearly drives me crazy...
Workaround is simple - don't try to "open" that menu :)
Now I assume that you want to FIX the issue. Then you need to figure out what is going on. The system may be non-responsive for multiple reasons, most likely one of these two:
You are in a busy loop in your main UI thread.
You are waiting for an event that never happens. Deadlock, for example.
When your application is frozen, try to attach debugger to it and do Debug -> Break All. Then see what code is executing. If the reason for this "freeze" will not be obvious, please post relevant code.
I am using VS2010 for my MFC SDI application.
In MainFrame Class in OnCreate(LPCREATESTRUCT lpCreateStruct) function I am opening one dialog box and on IDCANCLE replay from the Dialog box I want to close my application.
I am using following code for the same in onCreate Function.
CTermsConditionDlg objTNCDlg;
if(!objTNCDlg.DoModal() == IDCANCLE){
return -1;
}
Now my Question is after return Statement the application is Showing message box as shown in Image.
I want to disable this message box and close my application.
Can any one help how can I do That.
Thank You in Advance.
Why do you place this dialog so late into you initialization?
The problem is the SDI framework that relay on some initial things that are expected to run always. In this case it is always expected that the mainframe can be created. See code in CSingleDocTemplate::OpenDocumentFile
Just place this code into InitInistance before LoadFrame or ProcessShellCommand is called. In this case you can easily terminate without disturbing problems.
Another Idea is to allow the creation of the window, but simply using a PostMessage(WM_CLOSE); In this case the initialization is done, everything is created and the application terminates again.
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