|
I have an old MFC Dialog Based app that was designed in the WinXP and Win7 era. This project is for internal use and no longer in development. In Win10, we have scaling issues with high DPI screens (some controls are small or positions compressed), which is to be expected. However, on standard DPI screens, there have not been any issues until now.
One user reports that the dialog window is correctly sized (fixed sized), but all the controls within the window are scaled up beyond the boundaries of the dialog window and so half the controls are hidden. Display scaling settings in windows is normal (100%). What could be causing this?
|
|
|
|
|
How hard could it be for Visual Studio (new or recent or even old versions for that matter) to convert this old MFC Dialog-based application?
If it could convert this old MFC Dialog-based application it will. If it can't then attempting to open it's project files will result in a telling error message which, of course, will be useful to the learned helpers here on CP.
Try posting that message.
|
|
|
|
|
Can you clarify convert to what?
I can open the project in Visual Studio 2019 without issues after installing the older toolsets. I do need to maintain compatibility with WinXP. There are some computers that are still running WinXP due to old software/hardware compatibility.
I'm not sure if the UI issue is related to MFC. Converting to .NET forms would not be a simple task.
|
|
|
|
|
If you have a business process that is still running on Windows XP, you have MUCH BIGGER problems than this MFC code.
The hardware does not last forever, and when (not if!) it fails, then what? What are you going to replace a bad motherboard with? Or this "old hardware"? What happens when that fails? Hardware that old isn't made any more and good luck trying to find someone to fix it.
Modern day machines will not run Windows XP. Hell, nowadays, Windows 10, or a modern equivalent is required!
Your process is teetering on the brink of failure.
|
|
|
|
|
I completely agree with you. However, that's a business decision that is out of my hands. We use this to support older equipment. Our customers don't want to pay the significant upgrade to our latest equipment, and our bosses don't want to lose the repair/maintenance business. A lot of industrial equipment (not just ours) that don't connect to the web still run on XP. A surprise for me when I first started, but true nonetheless.
|
|
|
|
|
I hear that.
Customers are prone to screwing themselves.
|
|
|
|
|
So if you're talking about WinXP 32-bit (there was actually a time when one who licensed this had an opportunity to acquire the 64-bit installation disks believe it or not) or if you were indeed one of those paying attention to the offer to get that 64-bit version and had machines that could run 64-bit OS and successfully got it up and running (just before Windows Vista 32 & 64 bit made it evident that the future was going to be 64-bit and hyperthreaded as well) you are probably also aware that once Windows 2000 was supersceded, no 16-bit programs were allowed to run anymore.
And since you suggest VS2019 will open this application and you're not telling me about the previously mentioned flags during conversion I'd say you're good to go to set the project build targets to whatever is available and test a compilation.
Next moves:
1. Move some controls around and recompile.
2. Re-reference "missing" assemblies (or COM objects/whatever) and if not able to do that try what you suggest, substitute .NET interops (sometimes that works).
3. Sift through the compile/link errors (I'm finding it hard to believe that you've opened this thing without any conversio notices actually) ... use VERBOSE; note what crops up as documented error or warning.
And finally, since this is clearly a hardware issue for you (which I also doubt has anything to do with MFC of any flavor of MS Windows), try hooking up a less resolute monitor.
Graphics card you ask. Also doubtful. MFC is MFC is MFC (it's VS that fronts the eminence)
|
|
|
|
|
The winxp issue is out of my control unfortunately. A few PCs must run xp (due to software/hardware unrelated to this MFC app in question), the rest are win7 and 10. Therefore, this MFC app need to run on all if possible.
Sorry, I misunderstood when you asked for errors. Thought you meant compile errors, of which there were none after changing some flags. The flags were:
1>cl : Command line warning D9035: option 'Gm' has been deprecated and will be removed in a future release
1>cl : Command line error D8016: '/ZI' and '/Gy-' command-line options are incompatible
I fixed by changing /ZI to /Zi. Then it compiled without errors.
I also changed platform toolset to "Visual Studio 2017 - Windows XP (v141_xp)" from "Visual Studio 2010 (v100)".
I couldn't find the verbose option in Project Properties. Where can I find the verbose option? I did increase the Warning Level from 1 to 4. Is that what you mean? I'm getting lots of warnings now that seem to relate to converting from MSVC to ISO C++ 14. I will have to work through them all.
There are no COM objects used in this project.
Regarding hardware/graphics card issue, I thought MFC abstracts hardware layer away? As you said, MFC is MFC. I got to spend a few minutes on that laptop today. It's a dell with integrated graphics and 1080p screen. Other laptops with similar specs have been able to run this program normally, which is why I suspected some setting on this PC. If I set the system level scaling to 200%, the dialog app window is enlarged accordingly such that you can now see all controls. Almost as if the controls in the dialog window are fixed dimension, and the system scaling only applies to the box around it.
Thanks for the help and pointers.
|
|
|
|
|
OK!
Good signs then: the (project .. I was guessing) compiles. And it's important that you provide information like what the version you migrated from -> VS 2010 to VS 2017. That type of thing is always helpful for those trying to help. I haven't upgraded since 2010 and am sticking to my 64-bit guns still (not until MS, not until).
VERBOSE is a linker switch and what it does is make ALL linker messages present in the immediate window (yes, there's the overly warning/error widget which modernized the whole business) which I find easier to interpret mainly because it's time sequential and spits out mangled strings that can be used in a regular file search through your system; in the event that any one error says a library is missing, you can just type in the string that "can't be found" and window's search'll usually tell you which library to add to the reference (it contains the stubb of the string).
But since you've more or less passed over that hurdle and the thing's essentially a .dll or .exe or a set of each or both you can skip that.
I just have only one more thing to add and that's as I said ... MFC is more or less pushed by the VS version you've produced your executables with and as targetted OS .exe and .dll, managed or otherwise (I'm lumping .NET in this statment as well as long as you've properly dialed in the assembly in the properties (3.0, 3.5 ... what are we up to now? 4.5? etc) [as well I mean]) and as to why if you were building under x86 (for Win7 say or even WinXP) how anything out of even VS2017 would cause scale and panel metrics to be out of whack I can't fathom. As you say "abstracts in the hardware layer" ... bad stuff all wrastled out by informed folk at NVidia/etc.
I see in some of these posts that "Advanced Settings" has been a topic but I can say that unless this is an old video game you're trying to spruce up enough to display the same interface you had on 1080 (not even right?) 1200 x 1600 multimonitor set up while running @ 600 x 800 ... that'd be the only place to do the appropriate experimentation. Sometimes that battle can be won but I've lost it more times than I care to count.
Try everything? Sorry I can't be of more/better help.
|
|
|
|
|
Have you tried running the app in compatibility mode?
|
|
|
|
|
Yes. No change. Also tried "override high dpi scaling", with no change. Although at 1080p, there shouldn't be high dpi issues.
|
|
|
|
|
Are the controls being created at runtime?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
no. they were designed in dialog editor.
|
|
|
|
|
Which means they should not be changing size or position unless otherwise instructed to do so via code.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
You're right, it shouldn't but something is causing it. There is nothing in the code that resizes or moves any of the controls. The program was designed to be fixed position & size from the start.
|
|
|
|
|
Check the other Windows scaling controls (Advanced scaling settings).
|
|
|
|
|
I've tried various scaling settings, and it doesn't help. It appears the controls inside the dialog windows are being drawn as fixed pixel dimension. The scaling settings only change the dimension of the window. So actually, if I set scaling to 200%, the dialog window becomes large enough to show all the controls within. But that's not an ideal solution, since 200% is almost unusable for everything else.
What has me stumped is that other PCs of similar specs do not exhibit this issue.
|
|
|
|
|
Hi,
You should be able to fix this without modifying/recompiling the application. You would need to use the manifest tool to embed an application manifest. You would need to set the dpiAware/dpiAwareness mode.
Application Manifests - Win32 apps | Microsoft Docs[^]
Best Wishes,
-David Delaune
|
|
|
|
|
|
No, that's not how this site works. We'll help you with YOUR code, but the site is not a "code to order" site.
|
|
|
|
|
I have used this free tool on Windows 7 for years, https://www.codeproject.com/Articles/354/A-Utility-to-Clean-Up-Compiler-Temp-Files , it's useful.
I now want to use this utility to clean up compiler temp files on Windows 10, but after registered the DirClean.dll file, the two menu items do not show on the context menu. I check the source files, but I can't find what is wrong.
Thank you for help!
|
|
|
|
|
Please use the forum at the end of the article so the person who wrote the article can help you.
|
|
|
|
|
There is few reply in the article forum, so I start this thread here. Thanks!
|
|
|
|
|
If you knew the extensions that you wanted to routinely delete (e.g., obj, tmp, pdb), you could simply add them to a BAT file something like:
del /s *.obj
del /s *.tmp
...
Put the BAT file in the parent folder of your work area and run it when needed. You could even create a scheduled task to do it automatically.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Thank you for the alternative method. I will try the BAT file.
Can anyone find the reason why the free tool failed to work on Windows 10? Thanks!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
