ObjReader Community
Discussion => Post Your Questions & Comments Here => Topic started by: James Fuller on November 18, 2016, 03:07:59 pm
-
Patrice,
I have an issue:
This code produces the vc_hellosdk image with Visual Studio 2015 Community.
#include <windows.h>
#pragma comment(lib,"User32.lib")
#pragma comment(lib,"gdi32.lib")
#define cSizeOfDefaultString 2048
#define IDC_OK 1001
#define IDC_CANCEL 1002
#define IDC_TEXT 1003
static HWND hText;
static HWND hOk;
static HWND hCancel;
int WINAPI WinMain (HINSTANCE, HINSTANCE, LPSTR, int);
LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM);
int WINAPI WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR CmdLine, int CmdShow)
{
WNDCLASSEX wcx = {0};
MSG uMsg = {0};
HWND hWin = {0};
DWORD dwStyle = {0};
DWORD dwStyleEx = {0};
HFONT hFont = {0};
hFont = ( HFONT) GetStockObject( DEFAULT_GUI_FONT);
char szClassName[] = "MyClassName";
wcx.cbSize = sizeof( wcx);
wcx.style = CS_HREDRAW | CS_VREDRAW;
wcx.lpfnWndProc = WndProc;
wcx.cbClsExtra = 0;
wcx.cbWndExtra = 0;
wcx.hInstance = hInst;
wcx.hIcon = LoadIcon( NULL, IDI_APPLICATION);
wcx.hCursor = LoadCursor( NULL, IDC_ARROW);
wcx.hbrBackground = ( HBRUSH)( COLOR_BTNFACE + 1);
wcx.lpszMenuName = 0;
wcx.lpszClassName = szClassName;
wcx.hIconSm = LoadIcon( NULL, IDI_APPLICATION);
RegisterClassEx( &wcx);
dwStyle = WS_POPUP | WS_VISIBLE | WS_CLIPSIBLINGS | WS_CAPTION;
dwStyleEx = WS_EX_DLGMODALFRAME | WS_EX_CONTROLPARENT | WS_EX_WINDOWEDGE;
hWin = CreateWindowEx( dwStyleEx, szClassName, "What is your name? ", dwStyle, ( GetSystemMetrics( SM_CXSCREEN) - 246) / 2, ( GetSystemMetrics( SM_CYSCREEN) - 110) / 2, 246, 110, 0, (HMENU) 0, hInst, NULL);
hText = CreateWindowEx( WS_EX_CLIENTEDGE, "Edit", "", WS_CHILD | WS_VISIBLE | WS_TABSTOP | ES_AUTOHSCROLL, 21, 20, 201, 19, hWin, (HMENU) IDC_TEXT, hInst, NULL);
SendMessage(hText, (UINT)WM_SETFONT, (WPARAM)hFont, (LPARAM)0);
hOk = CreateWindowEx( 0, "Button", "OK", WS_CHILD | WS_VISIBLE | WS_TABSTOP, 51, 52, 60, 23, hWin, (HMENU) IDC_OK, hInst, NULL);
SendMessage(hOk, (UINT)WM_SETFONT, (WPARAM)hFont, (LPARAM)0);
hCancel = CreateWindowEx( 0, "Button", "Cancel", WS_CHILD | WS_VISIBLE | WS_TABSTOP, 126, 52, 60, 23, hWin, (HMENU) IDC_CANCEL, hInst, NULL);
SendMessage(hCancel, (UINT)WM_SETFONT, (WPARAM)hFont, (LPARAM)1);
SetFocus(hText);
ShowWindow(hWin, SW_SHOW);
while(GetMessage( &uMsg, NULL, 0, 0))
{
if(IsDialogMessage(hWin, &uMsg))
{
continue;
}
TranslateMessage( &uMsg);
DispatchMessage( &uMsg);
}
return uMsg.wParam;
}
LRESULT CALLBACK WndProc (HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
switch(Msg)
{
case WM_DESTROY:
PostQuitMessage(0);
return 0;
case WM_COMMAND:
if((HWND)lParam == hCancel )
{
SendMessage(hWnd, (UINT)WM_CLOSE, (WPARAM)0, (LPARAM)0);
}
}
return DefWindowProc(hWnd, Msg, wParam, lParam);
}
The original code was the PowerBASIC HelloDDT example.
The PbWin9 HelloDDT and the PBWin10 HelloDDT along with all my other c/c++ compilers produce the gcc_hellosdk.jpg image.
James
-
I am not sure that i understand what your concern is.
Perhaps a problem with the nasty DDT DIALOG UNITS using twips rather than pixels.
...
-
Patrice,
It has nothing to do with dialog units or PowerBASIC.
The "c" code posted displays correctly with ALL my c and c++ compilers except Visual Studio 2015 Community.
I know it has DS_xxxx dialog defines scattered about but I have tried it without and it makes no difference.
I thought you might have run into this issue in your travels.
James
-
I updated the code.
James
-
I always work from the client size, then i use AdjustWindowRectEx to compute the correct size of the window.
-
With the correct client that must be 240 x 81
and using AdjustWindowRectEx you will never have this problem again, especially when the size of the caption could vary from one OS to another.
This is especially true for Windows 10.
dwStyle = WS_POPUP | WS_VISIBLE | WS_CLIPSIBLINGS | WS_CAPTION;
dwStyleEx = WS_EX_DLGMODALFRAME | WS_EX_CONTROLPARENT | WS_EX_WINDOWEDGE;
RECT lpr = { 0 };
SetRect(&lpr, 0, 0, 240, 81);
AdjustWindowRectEx(&lpr, dwStyle, FALSE, dwStyleEx);
long w = lpr.right - lpr.left;
long h = lpr.bottom - lpr.top;
long x = max((GetSystemMetrics(SM_CXSCREEN) - w) / 2, 0);
long y = max((GetSystemMetrics(SM_CYSCREEN) - h) / 2, 0);
hWin = CreateWindowEx( dwStyleEx, szClassName, L"What is your name? ", dwStyle, x, y, w, h, 0, (HMENU) 0, hInst, NULL);
-
Thanks Patrice.
It appears this is the way it's always been and is not a new phenomenon!!
All other compilers create a window the width and size asked for except vc??
Fred emailed that it was the same on earlier VS editions also.
I did a light search on it but found nothing.
Where is behavior documented?
James
-
For me i have always used AdjustWindowRectEx, even with PB
And this has been documented since the origin on MSDN, only DDT/CreateDialog was doing it the wrong way :)
https://msdn.microsoft.com/en-us/library/windows/desktop/ms632667(v=vs.85).aspx
And in WinLIFT i have also always considered the client size, when using a theme to skin a window, because the non-client area could be indeed much larger than its default value, and this is the reason why there are all the systemmetrics API.
-
Hello James,
I confirm this glitch for at least the VS2013 Ultimate and VS2015 Community releases, where the outer dimensions of the window appear smaller than specified at creation time regardless of compiler bitness, but only under Windows 10.
Of course unlike Windows Classic where the window sizes are always consistent, densely populated client areas also look ugly under themed Vista/7/8/8.1 (and even under XP) due to unpredictable theme/padding interference regardless of compiler, if only the windows aren't created based on their desired client sizes using AdjustWindowRectEx() as Patrice suggests. Naturally this doesn't concern ridiculously huge dialogs with sparse child controls such as e.g. Adobe Flash or Oracle Java installers/updaters.
So, all is not gold that glisters and old friends and old wine are best, speaking of one's most trusted tools and environments. :)
(And sorry for thread necromancy)
-
Mike,
I get truncation with cl ver 18 & 19 on Windows 7 64
James
-
No James,
This isn't truncation. The outer dimensions of the window are exactly 246x110 pixels regardless of bitnesses and native visual styles. Pls check the size of your snapshot: it's exactly 246x110 pxs large as are all mine per the attached snapshots.
Naturally, the client area gets smaller when visual styles are applied and extra padding (something we didn't have on pre-Vista platforms) adds up to the usual border thickness. But AdjustWindowRectEx() with all the additional tweaks that Patrice and José suggested will compensate for that phenomenon very efficiently if you'd prefer to create your windows based off of their desired client sizes rather than their outer dimensions.
Contrary to that, both CL 18 and 19 would distort the outer sizes of the window under Windows 10 actually making them visibly smaller than specified in the CreateWindow[Ex] call. I suspect the same would occur also under Windows 8/8.1 but I can't verify it as I've never had those inferior OSes installed on my machines.
My 32/64 bit CL 18 compilations are also attached below for reference.
-
Mike,
I guess my next question is why do all other compilers have these dimensions:
Client: 240x81
Window: 246x110
But Visual Studio 2015 Community has these:
Client: 230x71
Window: 246x110
I do not believe it is the CreateWindowEx Function.
I did a Loadlibrary/GetProcessAddress on User32.dll and the results were the same.
I understand HOW to display it correctly. I would like to know when it changed.
Fred said it displayed correctly with an earlier VS?
James
-
OMG James,
You're absolutely correct! Just look at that mess below... This miserable NET thing gets smaller even under Windows 7 Aero! Moreover, it lies blatantly about its own outer size! >:(
The things get even worse under Windows 10 where it gets smaller not only under (unofficial) Aero but also under the one and only stock visual style!
As for me, I'm using GCC but Patrice may get really hurt by this CL 18/19 nuisance that he uses for his compilations ...
-
I do not know why you are using this dwStyleEx for a popup window.
dwStyleEx = WS_EX_DLGMODALFRAME | WS_EX_CONTROLPARENT | WS_EX_WINDOWEDGE;
try with dwStyleEx = 0, and see if it makes any difference.
...
-
WS_EX_WINDOWEDGE will be added by Windows automatically to any non-owned top-level window regardless of whether dwStyleEx is 0 or has explicit WS_EX_WINDOWEDGE.
WinSpy++ allows you to add or remove any and all window (ex)styles in real time, and I assure you I tried and I can confirm the WS_EX_DLGMODALFRAME and WS_EX_CONTROLPARENT exstyles used here do not affect any metrics in any of these compilers under any of these OSes. And as I noted, you can't avoid WS_EX_WINDOWEDGE nor can you remove it.
The issue is not in a particular (ex)style being added or removed by this or that compiler. All of them generate the exact same set of (ex)styles. The issue is only with CL 18/19 that add extra 4 pixels of padding all on their own under themed 7/10 where noone asks them to. :D And another big issue is with a faulty and misleading outer size report under 7 Aero and 10 that doesn't match the actual non-client outer size of the window.
-
I fully agree that there is a faulty misleading outer size report.
What i checked however is that using dwStyleEx = 0, strangely produce the correct client area size, just like when using AdjustWindowRectEx.
But the size reported by GetWindowRect is still wrong, when compared to the pixel size of a screen capture of the window done in PhotoShop.
Be aware also that in Windows 10, the border of a resizable window or a fixed one, are now looking always the same.
Only one single pixel line, with no more grip on the bottom right corner in case of resizable window.
Thus things have changed, and especially for those who are not using the AdjustWindowRectEx before using CreateWindowEx with a popup window.
The only way to have a consistent appearence with all OS, is to use a Skin Engine. ;)
...