4

I'm working on making slight changes to a legacy VS 2008 & MFC project, including changes to the WinAPI/MFC *.rc resource file. I have made those changes, e.g., changing a menu string (for IDR_MAINFRAME, if it matters) from "New Scan" to "New Organism" on one computer, commited to VCS, and tried rebuilding the project on another, practically identical configuration (not sure if relevant), which is when I ran into problems.

Currently, I have

  1. changes to the menu from within the VS resource editor that do not propagate into the application (old values remain)
  2. changes to the about dialog that do propagate into the application
  3. an RC file that contains no mention of "New Scan"
  4. no file, including binaries, containing "New Scan" (though, as mentioned, this might be due to encoding)

I have

  1. cleaned and rebuilt
  2. manually cleaned and rebuilt
  3. deleted the *.res file and compiled just the *.rc file into a *.res just to make sure the paths there are alright
  4. modified the configuration so that (Project -> Properties -> Resources -> Command Line) has an absolute path to the *.res file.
    1. verified that the current module is indeed the exe being executed via GetModuleHandle
  5. verified that all calls to FindResource and LoadResource pass NULL as the current module, meaning the resource should be loaded from the exe
  6. verified using ResEdit that the resource within the exe contains "New Organism", even though it shows "New Scan" when run. I verified the #define for the resource is the same number as the number reported by ResEdit. Verified there's no other similar resources in the exe.
  7. verified that I'm running the same exe I'm inspecting and tried running it from both the IDE and from Windows Explorer.
  8. inspected all (two) non-system DLLs that get loaded (as reported by the output window and dependency walker) using ResEdit and both of them belong to a 3rd paty library and none of them contain any menu resources (they only contain manifests).
  9. tried changing/removing the command that loads the menu (CFrameWndEx::LoadFrame) and verified it forces the application to fail.
    1. verified that having an IDR_AppnameTYPE MENU with a second copy of the menu doesn't help (see thomiel's answer below)
  10. Using google

To no avail. I am especially unsure where the original string, "New Scan", is coming from and how come changes to my about dialog propagate and changes to the menu don't. How do I make the changes to the menu propagate to the *.exe itself?

Jan Benes
  • 532
  • 1
  • 5
  • 16
  • Are you sure the binaries don't contain the string? It will be encoded in utf-16 so many grep-like tools won't find it. Have you opened them in a resource editor? Do you use any resource DLLs? The EXE might be picking up DLLs from somewhere unexpected. Have you run the application in a debugger and checked the paths of the DLLs getting loaded? – arx Jul 06 '14 at 11:09
  • Good idea! I'll check it out and report later. – Jan Benes Jul 06 '14 at 12:30
  • Used ResEdit. The menu resource is in the `exe` itself and has the correct string. Console only contains two non-system DLLs, both belong to a 3rd part lib and the have manifests in them. I also tried DependencyWalker, which doesn't list any further DLLs. Finally, I noticed the following in the console: `"Warning: CMDIFrameWnd without a default menu.".`, generated by `pMainFrame->LoadFrame(IDR_MAINFRAME)`, where `IDR_MAINFRAME` is the offending frame/menu, and the menu is defined under `IDR_MAINFRAME MENU`. Still unsure where the old string comes from and why it gets displayed. – Jan Benes Jul 07 '14 at 20:17
  • I also checked all `FindResource` and `LoadResource` calls, all of them pass `NULL` (current module) as the module to look in and none of them work with the menu/frame. – Jan Benes Jul 07 '14 at 20:21
  • So ResEdit shows "New Organism" but the application displays "New Scan"? Are you are certain you are running the right exe? – arx Jul 07 '14 at 22:05
  • Yes. I double checked that it's the same `exe`, and also checked the timestamps to make sure it's been built right before me checking. (I will triple check tonight, but am positive I'm analyzing and running the same file). Also note that at least one change I made to an "About" box propagated okay, it's just the menu that doesn't work. – Jan Benes Jul 08 '14 at 08:01
  • @arx I triple checked and I have a freshly compiled `*.exe` with an up-to-date timestamp. When I run it from both within and outside VS 2008, the string in the menu is `New Scan`. For that very same file, ResEdit reports `New Organism`. I also checked that the values for `IDR_MAINFRAME` and the number ResEdit show are identical. There's no menu resource listed for the `exe` with even a remotely similar structure. – Jan Benes Jul 08 '14 at 20:36
  • Did you ever find a solution to this? I have the same problem with VS 2013. – Christian Ammer Sep 17 '15 at 14:46
  • @ChristianAmmer Sadly, I have not. As this was just an old app I was patching up for someone, I ran out of time and had to leave it at that. – Jan Benes Sep 17 '15 at 18:29
  • I'm having similar problems with Visual Studio 2013, still looking for solutions. Some changes get picked up, some do not. What I see in the resource editor does not match gets built. – JulieC Oct 05 '15 at 16:02
  • I'm having the same problem. Changes outside of the menu stick. Changes in the menu, don't stick. FYI. – Dan G Feb 24 '17 at 18:40

3 Answers3

1

In case of a SDI or MDI: Not only change IDR_MAINFRAME but also IDR_??????TYPE, which is the menu displayed when you have an open document.

thomiel
  • 2,467
  • 22
  • 37
  • Thanks for the hint. I remembered manually deleting a `IDR_AppnameTYPE MENU`. I tried reverting to the original `*.rc` file that still had the `IDR_AppnameTYPE MENU` and editing it, but it still won't propagate. Which further supports that I might be getting the resource from some unknown place. – Jan Benes Jul 08 '14 at 20:27
1

I have had the exact same problem. This is going to sound crazy, but if you create a SUB menu in the menu item, and then delete the APS AND RES files, and then SAVE ALL and to a REBUILD of the ENTIRE SOLUTION, you should be OK. Please contact me if you have any other questions. I'm happy to help.

Dan G
  • 165
  • 1
  • 13
0

It seems that MFC will cache the menu items in registry when you quit your application. To prove it you can copy your program to a new machine and runs it. If it displays the modified menu items normally, it means MFC uses cached menu items on your own machine.

You can clean the registry key to make your modifications take effects. The registry entry may locate at

HKEY_CURRENT_USER\Software\Local AppWizard-GeneratedApplications\MyMFCApplication1

-or-

HKEY_CURRENT_USER\Software\{your company}\{your project name}\Workspace

based on the MFC version.

Simas Joneliunas
  • 2,890
  • 20
  • 28
  • 35
jerry ch
  • 1
  • 1