MoveAnchorcontrol in BCX bug

[iancasey]

Hi all.
In BCX we have been using some code to Anchor controls whilst resizing. Recently I updated to PellesC version 9 and now all the controls slide of the page when sizing. I rechecked and all is well with version 8. I checked with the BCX group and the results are
The attached code seems to work well in PellesC version 8, Ming 32 & 64, Borland BCC 32, LCC.
VCC failed to compile it.

I hope this can be of use to those here.
I have attached both the basic and C code.

Thanks,
Ian

[MrBcx]

Just to add my voice to Ian's,

I tested with clean installs of Pelles 8 (32 and 64 installs ) -- Ian's program ran correctly
I tested with a clean install of Pelles 9 ( compiled Ian's sample in 32 and 64 bit ) -- both were equally flawed.
I tested Ian's program with Mingw ( compiled in 32 and 64 ) - both ran correctly.
I tested with LccWin32 (final version) and the program ran correctly.

Links below show 2 short video grabs that illustrates the problem.

https://bcxbasiccoders.com/mrbcx_samples/Other/Flawed.Gif

https://bcxbasiccoders.com/mrbcx_samples/Other/Working.Gif
I hope this is helpful.
-MrBcx-

[Robert]

Hi all.
In BCX we have been using some code to Anchor controls whilst resizing. Recently I updated to PellesC version 9 and now all the controls slide of the page when sizing. I rechecked and all is well with version 8. I checked with the BCX group and the results are
The attached code seems to work well in PellesC version 8, Ming 32 & 64, Borland BCC 32, LCC.
VCC failed to compile it.

I hope this can be of use to those here.
I have attached both the basic and C code.

Thanks,
Ian

Hi Ian:

Visual Studio 2019 and Clang 9.0 both produce an .exe where the controls slide off the page when sizing.

[Robert]

Hi all.
In BCX we have been using some code to Anchor controls whilst resizing. Recently I updated to PellesC version 9 and now all the controls slide of the page when sizing. I rechecked and all is well with version 8. I checked with the BCX group and the results are
The attached code seems to work well in PellesC version 8, Ming 32 & 64, Borland BCC 32, LCC.
VCC failed to compile it.

I hope this can be of use to those here.
I have attached both the basic and C code.

Thanks,
Ian

Hi Ian:

Visual Studio 2019 and Clang 9.0 both produce an .exe where the controls slide off the page when sizing.

The latest mingw-w64-i686-8.1.0-posix-dwarf-rt_v6-rev0 compiles an .exe which works as expected.

[TimoVJL]

Not a Pelles C bug.
Problem is here

Code Select Expand

GetSystemMetrics( SM_CYCAPTION) - GetSystemMetrics( SM_CYSIZEFRAME)
Use linker subsystem version 5,1 or 5,2 to verify it.

EDIT: -subsystem:windows,5.1 for WindowsXP and -subsystem:windows,5.2 for WindowsXP x64

[MrBcx]

Not a Pelles C bug.
Problem is here

Code Select Expand

GetSystemMetrics( SM_CYCAPTION) - GetSystemMetrics( SM_CYSIZEFRAME)
Use linker subsystem version 5,1 or 5,2 to verify it.

Thank you for your help Timo.

I haven't yet found an explanation why "GetSystemMetrics( SM_CYCAPTION) - GetSystemMetrics( SM_CYSIZEFRAME)" causes the problem.  I'll keep looking.

I can confirm that including a linker "/subsystem:windows,5.01" or "/subsystem:windows,5.02" using Pellesc 9.0 corrects the problem in the OP.

What I can say, is that the subsystem version number has always been OPTIONAL with Polink and is still that way with Pelles 9.00

/STUB:filename
/SUBSYSTEM:{CONSOLE|NATIVE|WINDOWS}[,#[.##]]
/SWAPRUN:{CD|NET}

Omitting the subsystem version number in Pelles C 8.00 and earlier still allowed Ian's test program to execute correctly. 
Maybe that was just dumb luck.

Polink in Version 9 seems now to require a correct subsystem version number in order to guarantee a correctly linked program.

As you and others know, 5.01 refers to Windows XP and 5.02 refers to Windows Server 2003. 
Substituting either of those two WORKING subsystem versions numbers for anything newer (6.00 Vista) to (A00 Windows 10)
causes big problems.

I will update my batch files and resume using Pelles 9.00

Thanks again!

[iancasey]

Thank you Timo,
I added the version number to the linker options and it worked. I don't understand why would GetSystemMetrics change using different subsystems and what effect would that have on future projects?

Any ideas on how to change that code so I don't need the add the subsystem item or use 6.0 or Win 10.

Anyway, I can use version 9.00 again.

Thanks again to all,

Ian

[TimoVJL]

We can start to verify, what values different function give:

Code Select Expand

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#pragma comment(lib, "user32.lib")

int __cdecl main(void)
{
WINDOWINFO wndinfo;
wndinfo.cbSize = sizeof(WINDOWINFO);
GetWindowInfo(GetConsoleWindow(), &wndinfo);
printf("cx=%d, cy=%d, %d\n", wndinfo.cxWindowBorders, wndinfo.cyWindowBorders,
wndinfo.rcClient.top - wndinfo.rcWindow.top);
int iCYC = GetSystemMetrics( SM_CYCAPTION);
int iCYS = GetSystemMetrics( SM_CYSIZEFRAME);
int iCYF = GetSystemMetrics(SM_CYFRAME);
printf("%d, cy=%d\n ,cy=%d\n", iCYC, iCYS, iCYF);
return 0;
}
GetWindowInfo() give cy=8 and GetSystemMetrics() give cy=4

[Pelle]

Just a guess for now: could it have something to do with DPI awareness (or lack thereof)?

( "Setting the default DPI awareness for a process": https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/mt846517(v=vs.85) )

[Pelle]

No, not really, but including SM_CXPADDEDBORDER in both the SM_CXSIZEFRAME and SM_CYSIZEFRAME value works for me.

Vista added the SM_CXPADDEDBORDER system metric which needs to be included
in the border size. The previous code happened to work with 32-bit Chrome
because Windows added the padding into SM_CXSIZEFRAME (and set the padding to 0)
for backwards compatibility, but with 64-bit that changed.
GetSystemMetrics(SM_CXPADDEDBORDER) should always return 0 on XP.

[iancasey]

Thanks Pelles
That worked a charm.

Anyways all is well with the world again.

Thanks again,
Ian