I maintain an application written using visual studio 2010 and wxWidgets version 2.8.10. It has been reported to me that, under windows vista, the application will crash when displaying a wxFileDialog that is viewing a network drive and being resized. The dialogue is invoked with the following code:
wxFileDialog file_chooser(
this,
make_wxString(my_strings[strid_file_choose_caption]),
make_wxString(frame->get_config()->get_last_os_dir()),
wxT(""), // default file
make_wxString(loader->get_file_extension()),
wxOPEN);
int rcd = file_chooser.ShowModal();
Has anybody seen anything similar?
Crashes inside the standard file dialog are almost invariably due to the presence of some buggy shell extension on the system. To say anything more you'd need to get the minidump (or at least a stack trace) at the moment of crash and debug it.
Related
I am upgrading from Windows 7 to Windows 10. I tried to use activex (ocx) in Windows 10, but the program did not start and ended. I got the source and checked it, but compiling is not a problem, but when I make ocx and load it in another program and use it, "Warning: Creating dialog from within a COleControlModule application is not a supported scenario." is a debug message. Even if it is compiled and used in Release version, it does not run. The activeX program structure in question is used by creating CDialog inside.
Can this situation be solved simply?
//code
m_CamDlg.Create( IDD_CAMDIALOG, this); // <= There is a problem here
TRACE("CLiveViewCtrl OnCreate 3\n");
m_CamDlg.ShowWindow(1);
I am coding a C++ project using MFC in Visual Studio (v16.5.4). The dialog editor seems badly broken on my HiDPI monitor (Lenovo ThinkVision 2880x1800 at 175%). It works fine on two other computers with standard monitors.
The dialogs get resized apparently randomly, and controls do not move correctly when I try to edit them. When I try to align controls the dotted selection rectangle may move, but the control often does not (in the editor). Sometimes, re-opening the editor shows that the control has in fact moved. When I build the project, the final display layout cannot be predicted from what appears in the resource editor.
I reported this to Microsoft using Visual Studio feedback, but they closed the report, saying it was "By design"!!!! They posted a link describing a feature which disables HiDPI awareness, but the link was for the Windows Forms Designer, not the MFC resource editor - there is no equivalent feature in the latter that I could find.
Does anyone else have this problem, or know of a decent work-around? At the moment I am transferring to my other computer with the standard display whenever I need to edit a dialog, which is monumentally inefficient for quite a large project.
I know this is an older post, but I thought what I found might help someone. I experienced the same issue today. It just happens that I have one monitor setup for 125% and one setup for 100%. The MFC dialog editor alignment operations do not work correctly on the 125% monitor but work fine on the 100% monitor. It would appear Microsoft isn't properly handling DPI in the dialog editor.
I am seeing a strange crash in a Qt app that I am working on, and I am wondering if anyone has seen something similar or knows what the reason could be.
The crash is due to an access violation and occurs in around 30% of the cases when a call to QMessageBox::question() is made. The app only crashes in Release mode (never in Debug).
The code that causes the crash looks completely innocuous:
QMessageBox::question(
this,
QString("Deleting configuration"),
QString("Are you sure you want to delete this configuration?"));
It does not matter if the dialog is created with a static function call (like above) or explicitly. Other standard dialogs that have an icon (QMessageBox::critical(), QMessageBox::information(), etc.) also cause this crash, but interestingly a default QMessageBox dialog without any icons never crashes. However, the crash appears again after adding a standard icon through setIcon():
QMessageBox dialog;
dialog.setText("Blah blah blah");
dialog.setIcon(QMessageBox::Question);
dialog.exec();
Could it have something to do with the standard icons in these dialogs? The crash only occurs on the first dialog display; once a single dialog has displayed without a crash, all subsequent ones will work fine.
The Qt version is 5.12.2 and the app is compiled with the Visual Studio 2017 x64 C++ compiler.
When I start the program, I get the dialog and everything. But it closes by itself after some 10 seconds. How do I disable that?
EDIT: This happens when I run "Debug -> Start Without Debugging". This is the only way I know how to run the program.
EDIT2: My dialog is inheriting from CDialogEx.
If your dialog is not modal, i.e. you are not firing it up using the DoModal() member function, it is possible that it is being created with the constructor, and deleted with the destructor as it goes out of scope. You see this type of behaviour with some implementations of splash screens. To figure out what is happening, put a breakpoint on your dialogs destructor, and look at the call stack that is leading to it. It is also worth turning on all exceptions in the debugger, as you could be getting hit with an uncaught exception that is terminating your app.
As others have already said, this is not normal behaviour for an MFC app.
Usually dialogs do not behave that way.
But in default, they close on OnOk (CDialog::OnOk) which is "Enter Key Pressed"
and OnCancel (CDialog::OnCancel()) which is "Esc Key Pressed"
Try overloading those two in your Dialog, to see if those get called and to handle
the behaviour there as you like it.
Perhaps the Close event should also be handled or watched.
here are lots of examples of what can be done with a Dialog (especially OnOk, OnCancel and Close) CDialog Examples
I was facing the same issue with Visual Studio 2013:
I was creating the most basic MFC application with the Visual Studio wizard (either dialog-based, Single/Multiple document based), and just recompiling the generated code. No modification to the code at all.
I just found out that the "restart" does not occur when I turn off my Anti-virus. :-)
This is not a bug in Visual Studio, it is an environment problem.
My anti-virus is Avast.
The solution for Avast is to turn-off the Deepscreen feature.
There, go to Settings / Active Protection / Deepscreen - and disable that.
More details could be found about this approach to the solution on Avast's forums, from this discussion:
https://forum.avast.com/index.php?topic=139935.0
Confirmed, this happens with Visual Studio 2010, and doesn't happen with Visual Studio 2008. That means all the negative votes were completely unnecessary. It's a default of Visual Studio 2010, I didn't change anything. Nor did I make any bug, because I explicitly said that I created a new application without changing anything.
Thanks for all the negative votes.
Just for the record, I tried this using Visual Studio 2010. I picked Dialog-based application and left all the other options at their default settings. Compiled both Debug and Release configurations, for x86 and x64. When launched using Start without Debugging none of the four executables terminated by themselves.
If this is happening for you I would assume you have some application running (in the background) that interferes with the expected behavior. Try setting up a virtual machine, install a clean Visual Studio and perform the same procedure again.
I just started working on a project that was developed in Visual C++ 2005 using MFC, by someone else. To do so, I installed Visual C++ 2010 - I have no experience using either version (or visual studio at all, for that matter).
The application has a menu bar that is implemented using the CMenu class, and is initialized from a resource (ie, is created using the menu editor).
If I run the application in debug mode, the following debug assertion fails as soon as I open any menu in the menu bar:
Filename: afxwin1.inl
Assertion (with appropriate context):
_AFXWIN_INLINE HMENU CMenu::GetSafeHmenu() const
{ ASSERT(this == NULL || m_hMenu == NULL || ::IsMenu(m_hMenu));
return this == NULL ? NULL : m_hMenu; }
According to the debugger, this is set to a pointer to my menu, and this->m_hMenu is set to a pointer as well - however, the debugger seems to be confused about the type, the value is 0xdeadbeef {unused=??? } (for a more boring value of 0xdeadbeef, of course).
It would seem that something is broken, and most likely in the project code - I am aware of this. However, if I create a release build, it runs without errors, and the menu is displayed correctly. Moreover, I edited the menu using the menu editor in Visual C++ 2010, and saved it - there was no change. I'm therefore ruling out menu compatibility issues from the resource being in the wrong format.
I am running Windows XP SP3 on a ThinkPad T61p.
The code that creates the menu is
CMenu menu;
menu.LoadMenu(RESOURCE_NAME);
SetMenu(&menu);
And runs in the context of a subclass of CFrameWnd.
I have searched google a lot and am fairly certain that nobody had this problem before; Also, I'm a newbie to all of C++, MFC and Visual Studio. Help would be immensely appreciated; If I can provide more problem metadata, please tell me and I will do so.
Thanks in advance!
According to MSDN (http://msdn.microsoft.com/en-us/library/177ay1x0.aspx)
CMenu::LoadMenu() requires a parameter to be passed in, which is missing in your sample code.
Do check on that and make sure you are passing a valid menu resource id.
Edit:
Your menu object is constructed on the stack and will be destroyed once it went out of scope.
Where are you calling your CWnd::SetMenu from ? You need to make sure the object lifespan can last until the next CWnd::SetMenu else you will be holding/referring a dangling pointer.