Effect of #PB_Window_MaximizeGadget

[netmaestro]

Code: Select all

; Run this code, the window should fit the workarea nicely
; Now remove the #PB_Window_MaximizeGadget flag and rerun
; On my system (Windows 7) the window is too big now
;
SystemParametersInfo_(#SPI_GETWORKAREA,0, @this.rect,0)

OpenWindow(0,0,0,0,0,"",#PB_Window_ScreenCentered|#PB_Window_SystemMenu|#PB_Window_MaximizeGadget|#PB_Window_MinimizeGadget)
MoveWindow_(WindowID(0),0,0,this\right-this\left,this\bottom-this\top,1)

Repeat:Until WaitWindowEvent() = #PB_Event_CloseWindow

Any ideas as to why this should be?

[Shield]

No problem here, fits the screen perfectly.
Only tested it on my laptop (single screen).

[ts-soft]

Confirmed, the window is to height without the #PB_Window_MaximizeGadget Flag, but only on Win 7 and Win 8,
no problem on Win XP.

[IdeasVacuum]

It's a perfect fit on WinXP 32bit, which has the Windows default 96 DPI. Is your Win7 32bit or 64bit? I can't see why, but that may have something to do with the issue.

[netmaestro]

My Windows version is 64bit. The issue happens with both PB 5 x64 and x32. I'm going to do some more investigation into this and see if it might be a known issue on Win7/8.

[netmaestro]

Doesn't seem to be an issue with an API-created window, whether it has the Maximize box or not, it shows correctly:

Code: Select all

Global hBrush = CreateSolidBrush_(GetSysColor_(#COLOR_WINDOW))

Procedure WinProc(hWnd, Msg, wParam, lParam) 
  
  Select Msg 
    Case #WM_CLOSE 
      DestroyWindow_(hWnd) 
      
    Case #WM_NCDESTROY 
      DeleteObject_(hBrush)
      PostQuitMessage_(0) 
      ProcedureReturn 0 
      
  EndSelect 
  
  ProcedureReturn DefWindowProc_(hWnd, Msg, wParam, lParam) 
  
EndProcedure 

#wStyle  = #WS_VISIBLE | #WS_SYSMENU | #WS_OVERLAPPEDWINDOW ; | #WS_MAXIMIZEBOX

classname$ = "TestClass" 
With wClass.WNDCLASSEX 
  \cbsize  = SizeOf(WNDCLASSEX) 
  \lpfnWndProc  = @WinProc() 
  \hCursor  = LoadCursor_(0, #IDC_ARROW)
  \hbrBackground  = hBrush
  \lpszClassName  = @classname$
EndWith

RegisterClassEx_(@wClass) 

SystemParametersInfo_(#SPI_GETWORKAREA,0,@this.RECT,0)

hWnd = CreateWindowEx_(0, classname$, "Size Test", #wStyle, 0, 0, 0, 0, 0, 0, 0, 0) 
MoveWindow_(hwnd,0,0,this\right-this\left,this\bottom-this\top,1)

ShowWindow_(hWnd,  #SW_SHOWDEFAULT) 

While GetMessage_(msg.MSG, 0, 0, 0 ) 
  TranslateMessage_(msg) 
  DispatchMessage_(msg) 
Wend

Must be something intrinsic to PureBasic windows

[electrochrisso]

Both codes work ok here on my 1024x600 win7/32 netbook.

[luis]

Hi NM, If I'm non mistaken the style in the api version should be:

Code: Select all

#wStyle  = #WS_VISIBLE | #WS_SYSMENU | #WS_OVERLAPPED | #WS_THICKFRAME | #WS_MINIMIZEBOX ; | #WS_MAXIMIZEBOX

In your code

Code: Select all

#wStyle  = #WS_VISIBLE | #WS_SYSMENU | #WS_OVERLAPPEDWINDOW; | #WS_MAXIMIZEBOX

commenting out #WS_MAXIMIZEBOX has no effect because #WS_OVERLAPPEDWINDOW has that one already set.

I'm not sure what you mean with "too big"... anyway I saw something strange too.

The difference in the behavior I can see between the PB version and the API version seems to be caused by the #WS_THICKFRAME.

Code: Select all

OpenWindow(0,0,0,0,0,"",#PB_Window_SystemMenu|#PB_Window_MinimizeGadget | #WS_THICKFRAME) ; | #PB_Window_MaximizeGadget)

Removing #PB_Window_MaximizeGadget from the PB code seems to reset the #WS_THICKFRAME bit.

Code: Select all

Debug "00000" + Bin(#WS_THICKFRAME)
Debug Bin(#PB_Window_MaximizeGadget)
Debug Bin(#PB_Window_MinimizeGadget)

Is this what you mean ?

[netmaestro]

Hi luis,

You are right I goofed on the style. But when I use the style you posted, with WS_THICKFRAME and without WS_MAXIMIZEBOX, the result is unchanged. For the API window there is no combination of style bits that will result in an incorrectly sized window.

I'm not sure what you mean with "too big"... anyway I saw something strange too.

Here is the top right corner of my monitor with the API window displayed:


And this is what it looks like with the PB window displayed. All 4 corners are half off the monitor:

[netmaestro]

Turns out I can reproduce the incorrectly-sized window in API by removing the WS_THICKFRAME style. With that style bit set, all is well, without it the window is too big for the workarea.

[RASHAD]

Hi NM
Did you tried not to use #PB_Window_ScreenCentered
There is no such thing in API
And that means that this flag trigger some special routine in PB
Maybe it is the cause

BTW :I am using Win 7 x64 and everything looks fine

[luis]

Thanks for the images, ok, we are talking about the same thing.

Turns out I can reproduce the incorrectly-sized window in API by removing the WS_THICKFRAME style. With that style bit set, all is well, without it the window is too big for the workarea.

Yes, that's what I meant.

Code: Select all

SystemParametersInfo_(#SPI_GETWORKAREA,0, @this.rect,0)

OpenWindow(0,0,0,0,0,"", #WS_THICKFRAME | #PB_Window_ScreenCentered | #PB_Window_SystemMenu |#PB_Window_MinimizeGadget | #PB_Window_MaximizeGadget) 
MoveWindow_(WindowID(0),0,0,this\right-this\left,this\bottom-this\top,1)

Repeat:Until WaitWindowEvent() = #PB_Event_CloseWindow

This works ok here with or without the #PB_Window_MaximizeGadget flag.

Same thing with the API version, remove #WS_THICKFRAME and you have the problem.

As I shown above with the binary prints I think the problem is the value of the #PB_Window_MinimizeGadget constant.

I think it should have the #WS_THICKFRAME bit set as in #PB_Window_MaximizeGadget.

(EDIT: uhm, no the other way around, #PB_Window_MaximizeGadget shouldn't have the #WS_THICKFRAME bit set).

[netmaestro]

Ok but if that WS_THICKFRAME bit is set the window becomes sizable. It is equivalent to the WS_SIZEBOX flag.

[electrochrisso]

Hey NM, this problem not got anything to do with windows themes, try turning them off and see what happens.

[luis]

Ok but if that WS_THICKFRAME bit is set the window becomes sizable. It is equivalent to the WS_SIZEBOX flag.

Yes you are right, I didn't considered that, my bad.

But it is exactly like when you use the #PB_Window_MaximizeGadget flag with PB (to obtain the window behavior you liked).

In fact in your original code you can have the #PB_Window_MaximizeGadget removed and #PB_Window_SizeGadget set to have the window "fit the workarea nicely".

Code: Select all

OpenWindow(0,0,0,0,0,"", #PB_Window_ScreenCentered | #PB_Window_SystemMenu |#PB_Window_MinimizeGadget | #PB_Window_SizeGadget) ; | #PB_Window_MaximizeGadget)

Judging from the API test the pixels eroded away are the normal behavior if you don't have a sizable window.

So in end is probably #PB_Window_MaximizeGadget that has a bit set it shouldn't have and #PB_Window_MinimizeGadget is the right one, or you end up with a sizeable window even when you don't want it.
And when you want it you can specify #PB_Window_SizeGadget.

That's for the value of the PB constants. For the behavior itself (the eroded pixels) if it does happen under win7 but not under xp (I didn't try it, nor I did try to enable/disable themes) that's another problem and I don't know what to say. But the difference between API (where you can control the style using the right flags) and your PB example (#PB_Window_MaximizeGadget is messing up the sizeable bit) is due to some not too much coherent PB constant values IMHO. I would say it's a bug.

EDIT: just tried under XP. Your PB code works the way "you like", no pixels cut away. But there is still the problem with the PB constant. #PB_Window_MaximizeGadget makes the windows sizeable even if you didn't specified it that way (it doesn't happen with #PB_Window_MinimizeGadget).