Author Topic: Visual Studio 2015 Community issues  (Read 5756 times)

James Fuller

  • Newbie
  • *
  • Posts: 15
Visual Studio 2015 Community issues
« 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.
Code: [Select]

#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
« Last Edit: November 18, 2016, 07:15:39 pm by James Fuller »

Patrice Terrier

  • Administrator
  • *****
  • Posts: 952
    • zapsolution
Re: Visual Studio 2015 Community issues
« Reply #1 on: November 18, 2016, 04:17:33 pm »
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
(Always working with the latest Windows version available...)

James Fuller

  • Newbie
  • *
  • Posts: 15
Re: Visual Studio 2015 Community issues
« Reply #2 on: November 18, 2016, 04:57:17 pm »
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


James Fuller

  • Newbie
  • *
  • Posts: 15
Re: Visual Studio 2015 Community issues
« Reply #3 on: November 18, 2016, 07:16:10 pm »
I updated the code.

James

Patrice Terrier

  • Administrator
  • *****
  • Posts: 952
    • zapsolution
Re: Visual Studio 2015 Community issues
« Reply #4 on: November 18, 2016, 07:30:22 pm »
I always work from the client size, then i use AdjustWindowRectEx to compute the correct size of the window.

Patrice
(Always working with the latest Windows version available...)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 952
    • zapsolution
Re: Visual Studio 2015 Community issues
« Reply #5 on: November 18, 2016, 07:42:16 pm »
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.

Code: [Select]
    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);
« Last Edit: November 18, 2016, 07:44:02 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

James Fuller

  • Newbie
  • *
  • Posts: 15
Re: Visual Studio 2015 Community issues
« Reply #6 on: November 18, 2016, 11:05:07 pm »
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

Patrice Terrier

  • Administrator
  • *****
  • Posts: 952
    • zapsolution
Re: Visual Studio 2015 Community issues
« Reply #7 on: November 18, 2016, 11:32:18 pm »
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.
« Last Edit: November 18, 2016, 11:45:32 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 777
Re: Visual Studio 2015 Community issues
« Reply #8 on: November 21, 2016, 11:29:39 pm »
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
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

James Fuller

  • Newbie
  • *
  • Posts: 15
Re: Visual Studio 2015 Community issues
« Reply #9 on: November 22, 2016, 02:35:08 pm »
Mike,
  I get truncation with cl ver 18 & 19  on Windows 7 64
James

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 777
Re: Visual Studio 2015 Community issues
« Reply #10 on: November 23, 2016, 09:39:53 am »
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
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

James Fuller

  • Newbie
  • *
  • Posts: 15
Re: Visual Studio 2015 Community issues
« Reply #11 on: November 23, 2016, 01:14:16 pm »
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



Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 777
Re: Visual Studio 2015 Community issues
« Reply #12 on: November 23, 2016, 06:41:57 pm »
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 ...
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 952
    • zapsolution
Re: Visual Studio 2015 Community issues
« Reply #13 on: November 23, 2016, 08:00:32 pm »
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.

...
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 777
Re: Visual Studio 2015 Community issues
« Reply #14 on: November 23, 2016, 09:26:53 pm »
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.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)