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.
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.
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.
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.
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.
C is a rather stable language, every standard doesn't add so many features like happens, for instance, with C++, so you may find (of the tons available) a good tutorial on a previous version (e.g. C99 or C11) and start learning. Then, in order to complete your knowledge, you may access the freely available 'final draft of the standard' (external link in the very wikipedia page: C17 (C standard revision) - Wikipedia[^].
"In testa che avete, Signor di Ceprano?"
I didn't say it has not changed. It changed, but just a little. You haven't to go back to K&R. While probably there aren't yet many tutorials on the latest standard, there are many many available good ones for recent versions of it. That could be your fishing pond.
"In testa che avete, Signor di Ceprano?"