I am facing a very consistent and persistent problem with Visual Studio 2022 Community Edition.
In an MFC project I open the Resource File and add a new Dialog. Then I place some standard controls and rename the dialog resource from its default name to a new ID.
Then I save and try to assign a Class to the dialog by right-clicking on the dialog and choosing 'Add Class'. Then the 'Add MFC Class' window appears, I enter the Class Name and click [OK].
It appears it creates the class on the File System and then VS2022 crashes completely!
I have disabled all addins in case an addin could be causing the problem but it happens every (almost) every time even without plugins. The only time I manage to get it to work is if I save, close all code editors, exit VS2022, restart it and immediately try to add the class. Another piece of information is that I have changed the MFC dialog template with a different one but it does not seem to bother it when I get it to work. Also intelliSense is completely disabled.
How can I debug this and identify the root cause of this crash?
There's a fair chance that you can't do anything in an effective fashion. VS2022 isn't an open source project, where you can easily pinpoint a crash to a specific line of code and fix it yourself.
But the good thing is that you don't need to. Just use the feedback channel VS2022 provides:
Usually a Microsoft employee will reply within a few days and maybe a fix will be included in the next preview version. Only now and then it can take some month to get a bug resolved.
Related
I have created a File Explorer context menu extension that uses the IExplorerCommand interface to add menu commands to the Windows 11 context menu.
This has been working fine, but after the last Windows update, it no longer works properly.
Although the menu commands still appear, nothing happens when I click on any of them. I've added logging and I can see that IExplorerCommand::Invoke() is no longer being called.
Strangely, if I select the "Show more options" menu to get the legacy Windows 10 context menu, the commands work fine from that menu, it is only in the new Windows 11 context menu that they don't work.
I have tried running File Explorer in a debugger while selecting my menu commands, and I get lines like this in the output window when I click on the command:
onecore\com\combase\dcomrem\stdid.cxx(726)\combase.dll!00007FF9EB9947F5: (caller: 00007FF9C22E1E38) ReturnHr(2627) tid(67bc) 8001010E The application called an interface that was marshalled for a different thread.
I'm guessing this is the reason why my commands are not being called. Does anyone have any suggestions for what is causing this? Could it be a bug in File Explorer?
I've tried both STA and MTA threading models, and changing this made no difference.
Well, after wasting hours on this I finally have a solution!
My code was based on the PhotoStoreContextMenu sample code here:
https://github.com/microsoft/AppModelSamples/tree/master/Samples/SparsePackages/PhotoStoreContextMenu
This uses the Windows Runtime C++ Template Library (WRL), and defines the base classes used by the class like this:
class TestExplorerCommandBase : public RuntimeClass<RuntimeClassFlags<ClassicCom>, IExplorerCommand, IObjectWithSite>
The change that fixed it for my code was to use WinRtClassicComMix instead of ClassicCom, i.e.
class TestExplorerCommandBase : public RuntimeClass<RuntimeClassFlags<WinRtClassicComMix>, IExplorerCommand, IObjectWithSite>
I'm pretty sure this problem started when I installed KB5019509, which is the Windows update that changes File Explorer so that it now has tabs.
Note: this problem only happens for IExplorerCommands created in the plug-in for submenus, the top level commands that are defined in the APPX file work fine.
Also note that although this change does fix the problem with Invoke() not being called, it does introduce a new problem which is that IOleWindow::GetWindow() no longer works so it is not possible to get the parent HWND. (See Calling IOleWindow::GetWindow() from IExplorerCommand::Invoke() is giving error 8001010d (RPC_E_CANTCALLOUT_ININPUTSYNCCALL)).
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'm trying to update my application to use RichEdit 2.0; it's been using 1.0 since forever. Per the Microsoft documentation, I've changed AfxInitRichEdit() to AfxInitRichEdit2(), and I changed the class in the resource file from RICHEDIT to RichEdit20A (which is correct for this application). There is only one richedit in the resource file.
The application fails when I try to do anything with the window that includes this richedit. The dialog creation fails somewhere inside of ::CreateDialogIndirect(), and although I put breakpoints in CRichEditCtrl::Create and also on the class I derive from it, those breakpoints do not trip.
Out of frustration I tried calling AfxInitRichEdit() again and also calling AfxInitRichEdit2(). The application works! The breakpoints I put in do trip--but only on controls I create dynamically, not the one from the resource file. And when I run Active Window Spy, I see that the richedit created from the resource file somehow has a class of RICHEDIT even though I explicitly said RichEdit20A, and yet the dynamic ones are RichEdit20A as intended.
_RICHEDIT_VER is 0x210, and I'm using Visual Studio 2013.
I just can't figure out why CreateDialogIndirect() is making a RICHEDIT control--or trying to make one and failing, if I don't call AfxInitRichEdit()--instead of a RichEdit20A in spite of explicit instructions to the contrary. Any ideas?
Well, I feel stupid. There's a script that runs as part of the build process to update some resources, and for some reason that script has sometimes gotten confused between the debug and release versions, and copied resources from the release build into the debug build. I don't know why that happens and it's an issue for another day, but the upshot is the .rc file I had changed was getting replaced with another one.
Building the release version with the changes, and then building the debug version again, solved the problem.
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'm trying to add a new entry into Internet Explorer's right-click context menu. I understand that this can be achieved by creating an HTML file containing JavaScript, and then linking to this from a location in the registry. I have also read that you can also add the HTML to a resource file and compile it into a DLL (see the Microsoft KB: Adding Entries to the Standard Context Menu). This is where I have started to hit problems.
Here is a bit of background about what I have done so far.
I have the following JavaScript in the file C:\test.htm:
<script type="text/javascript">
alert('Hello, world!');
</script>
I have added a new REG_SZ value 'c:\test.htm' in the registry at the following location:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\MenuExt
If I now restart IE, my new menu item appears in the context menu. If I select my new menu item, my message box alert appears as expected. So far so good. However, I can't seem to access the script if it's in a DLL. Here are the steps I have taken:
Created a new Visual C++ Class Library project in VS 2005 named 'IETest' in c:\IETest
Imported my C:\test.htm file into the default app.rc resource file. I have changed the ID to be TEST
Compiled the DLL in debug mode
Altered the registry entry to read
res://C:\IETest\debug\IETest.dll/TEST
If I now restart IE and try again, the message box does not appear when I right-click and select my new context menu entry. I have also tried a release build of the DLL without any luck, and also tried replacing the last forward slash with a comma and altering the path single-backslashes to double-slashes.
I can only presume that I've done something wrong when creating my DLL. Can anyone point me in the right direction? Is there any way I can examine the compiled DLL to examine the resources and associated IDs?
Thanks.
Have you tried having the ID be TEST.html? My guess is that IE doesn't know how to handle the file because it doesn't have an extension listed, but this is totally a guess based off the fact that's how certain MS .dlls identify them (i.e. res://c:\windows\system32\shdoclc.dll/navcancl.htm)
The only other thing I can think of is to make sure your resources are of type 23.
ResourceHacker can view the resource files like you want: http://angusj.com/resourcehacker/