MenuHeight(), StatusBarHeight(), ToolBarHeight() returns 0?

[Fred]

It would be something like that:

Code: Select all

OpenWindow(0,10,10,600,0,"test")
CreateStatusBar(0,WindowID(0))
statusheight=StatusBarHeight(0)

GetWindowRect_(FindWindow_("Shell_TrayWnd",0),taskwin.RECT)
taskheight=taskwin\bottom-taskwin\top

screenheight=GetSystemMetrics_(#SM_CYSCREEN)

; ResizeWindow(0,10,10,600,screenheight-taskheight-(statusheight*2.5))
SetWindowPos_(WindowID(0), 0, 0, 0, 600, screenheight-taskheight-10, #SWP_NOZORDER | #SWP_NOMOVE)

Repeat : Until WaitWindowEvent()=#PB_Event_CloseWindow

[Dude]

Hi Fred, I don't think that'll help, so here's a better example of what I need to do.

When you run this app, the button's height resizes to match the window height. Then, you click the button and the height changes of the window and the button changes. However, the window height MUST stay above the taskbar at all times! So when the window and button are small, and you resize the taskbar higher, and then click the button, the window must resize to stay at the top of the screen and above the taskbar.

Code: Select all

; Works perfectly with 5.51
; Totally dead with 5.60 Beta

OpenWindow(0,10,10,600,0,"test",#PB_Window_SystemMenu|#PB_Window_SizeGadget)
CreateStatusBar(0,WindowID(0))
AddStatusBarField(#PB_Ignore)
StatusBarText(0,0,"Hello")

Global statusheight=StatusBarHeight(0)
Global bigwindow=1

ButtonGadget(0,10,10,580,0,"Click this button to toggle size")

Procedure SetWindowSize()
  bigwindow=1-bigwindow
  GetWindowRect_(FindWindow_("Shell_TrayWnd",0),taskwin.RECT)
  taskheight=taskwin\bottom-taskwin\top
  screenheight=GetSystemMetrics_(#SM_CYSCREEN)
  If bigwindow=0
    ResizeWindow(0,10,10,600,100)
    ResizeGadget(0,#PB_Ignore,#PB_Ignore,#PB_Ignore,WindowHeight(0)-45)
  Else
    ResizeWindow(0,10,10,600,screenheight-taskheight-(statusheight*2.5))
    ResizeGadget(0,#PB_Ignore,#PB_Ignore,#PB_Ignore,WindowHeight(0)-45)
  EndIf
EndProcedure

SetWindowSize()

Repeat
  Event=WaitWindowEvent()
  If Event=#PB_Event_Gadget
    SetWindowSize()
  EndIf
Until Event=#PB_Event_CloseWindow

[Fred]

I don't understand, did you try the command I pasted ?

Code: Select all

; Works perfectly with 5.51
; Totally dead with 5.60 Beta

OpenWindow(0,10,10,600,0,"test",#PB_Window_SystemMenu|#PB_Window_SizeGadget)
CreateStatusBar(0,WindowID(0))
AddStatusBarField(#PB_Ignore)
StatusBarText(0,0,"Hello")

Global statusheight=StatusBarHeight(0)
Global bigwindow=1

ButtonGadget(0,10,10,580,0,"Click this button to toggle size")

Procedure SetWindowSize()
  bigwindow=1-bigwindow
  GetWindowRect_(FindWindow_("Shell_TrayWnd",0),taskwin.RECT)
  taskheight=taskwin\bottom-taskwin\top
  screenheight=GetSystemMetrics_(#SM_CYSCREEN)
  If bigwindow=0
    ResizeWindow(0,10,10,600,100)
    ResizeGadget(0,#PB_Ignore,#PB_Ignore,#PB_Ignore,WindowHeight(0)-45)
  Else
    ; ResizeWindow(0,10,10,600,screenheight-taskheight-(statusheight*2.5))
    SetWindowPos_(WindowID(0), 0, 0, 0, 600, screenheight-taskheight-10, #SWP_NOZORDER | #SWP_NOMOVE)
    ResizeGadget(0,#PB_Ignore,#PB_Ignore,#PB_Ignore,WindowHeight(0)-20)
  EndIf
EndProcedure

SetWindowSize()

Repeat
  Event=WaitWindowEvent()
  If Event=#PB_Event_Gadget
    SetWindowSize()
  EndIf
Until Event=#PB_Event_CloseWindow

[Dude]

Yes, I tried your original example code. And even your example above doesn't resize the ButtonGadget() properly. It creates a big gap between the bottom of the ButtonGadget() and the top of the StatusBar when the window is small; and the width of the ButtonGadget() is wrong (too wide) when the window is big. Toggle the button with both versions of PureBasic to see what I mean. And when the window is big in 5.60 beta, it sits ON the top of the taskbar, instead of slightly above it.

[Fred]

It's because there is no adjustwindowsrect for the API, but I though you would get the idea.. You just have to adjust the "-12" constant to define the gap at the bottom between your window and the taskbar. Here is a another code:

Code: Select all

; Works perfectly with 5.51
; Totally dead with 5.60 Beta

OpenWindow(0,10,10,600,0,"test",#PB_Window_SystemMenu|#PB_Window_SizeGadget)
CreateStatusBar(0,WindowID(0))
AddStatusBarField(#PB_Ignore)
StatusBarText(0,0,"Hello")

Global statusheight=StatusBarHeight(0)
Global bigwindow=1

ButtonGadget(0,10,10,580,0,"Click this button to toggle size")

Procedure SetWindowSize()
  bigwindow=1-bigwindow
  GetWindowRect_(FindWindow_("Shell_TrayWnd",0),taskwin.RECT)
  taskheight=taskwin\bottom-taskwin\top
  screenheight=GetSystemMetrics_(#SM_CYSCREEN)
  If bigwindow=0
    ResizeWindow(0,10,10,600,100)
  Else
    ; ResizeWindow(0,10,10,600,screenheight-taskheight-(statusheight*2.5))
    SetWindowPos_(WindowID(0), 0, 0, 0, 616, screenheight-taskheight-12, #SWP_NOZORDER | #SWP_NOMOVE)
  EndIf
  ResizeGadget(0,#PB_Ignore,#PB_Ignore,#PB_Ignore,WindowHeight(0)-20)
EndProcedure

SetWindowSize()

Repeat
  Event=WaitWindowEvent()
  If Event=#PB_Event_Gadget
    SetWindowSize()
  EndIf
Until Event=#PB_Event_CloseWindow

[Dude]

Okay, that's looking better and probably the solution... but I'm going to play Devil's Advocate and bring up skywalk's question: how can the following code run on 5.60 beta now? We're losing this type of functionality. (And don't say overlapping gadgets is not supported, for the answer).

And what if I want to create a row of buttons to be the same height as the menu bar? Not possible anymore.

Is there any compelling reason those commands can't just stay in? Or are there API equivalents we can use (such as SendMessage) instead?

Code: Select all

; Put a half-size ProgressBarGadget() inside the center of the StatusBar.
; Not possible with 5.60 beta but works perfectly with 5.51 and below. :)

If OpenWindow(0, 100, 150, 300, 100, "", #PB_Window_SystemMenu | #PB_Window_SizeGadget)

  hstatus= CreateStatusBar(0, WindowID(0))
  If hstatus
    AddStatusBarField(100)
    statusheight=StatusBarHeight(0)
  EndIf

  Hprogress=ProgressBarGadget(0, 120, statusheight/4, 150, statusheight/2, 0,100)

EndIf

SetParent_(Hprogress,hstatus)
SetGadgetState(0,50)

Repeat

Until WaitWindowEvent() = #PB_Event_CloseWindow

[Fred]

If you use the API to tweak the statusbar, you should also use API to get the height. We remove them because it was non constistent on all OS, and if you used it in your window size calc, it's still behaving the same. I will add the flag parameter to resizewindow (and openwindow) to set the height/weight as frame coordinate instead of inner coordinates as it can be useful somewhen.

[skywalk]

Thanks Fred. That flag will reduce many code rewrites. Will the new resizewindow + outerframe flag respect all adjustments to menu,toolbar,statusbar,panelgadget,splitter?

[Fred]

Sure, all will fit in the new frame dimension as if you had resized it with the mouse.

[kenmo]

A ResizeWindow() flag would be great!

Even better if ResizeWindow() and WindowHeight() had 3 flags, not just 2!

Outer Frame <-- WindowHeight() already supports this
Inner <-- including menu, statusbar, toolbar, how PB 5.5 WindowHeight() worked
Inner Gadget Space <-- excluding menu, statusbar, toolbar, how PB 5.6b1 WindowHeight() works



EDIT: While we're talking about it...
My opinion: I wish PB 5.6 would reduce the inner gadget space (like 5.5) when adding menu/tool/status, instead of automatically growing.
I like the window to stay the size I specified in OpenWindow

[Mistrel]

I will add the flag parameter to resizewindow (and openwindow) to set the height/weight as frame coordinate instead of inner coordinates as it can be useful somewhen.

I think that is the best compromise. Sometimes I want to specify the client area and other times I want to specify the window height. Additional intermediary use cases can be handled as special cases.

My opinion: I wish PB 5.6 would reduce the inner gadget space (like 5.5) when adding menu/tool/status, instead of automatically growing.
I like the window to stay the size I specified in OpenWindow

It's hard to say which one is better because each have their uses. For example, a 3D render window may be expected to stay at a particular resolution and resize the window. While a business application or utility might want to resize the contents.

[IdeasVacuum]

It's hard to say which one is better

Automatically growing the size of the Window is terrible! The developer should decide how the app he designs is going to behave.

[Mistrel]

It's hard to say which one is better

Automatically growing the size of the Window is terrible! The developer should decide how the app he designs is going to behave.

You can have a use case for either.

For example, I have a window which is displaying a pixel-perfect representation of an image. This window has a button to bring up a status bar. In this case I would want the window to change size and not the client area, as the intent is to display a 1:1 representation of the image.

In a business or utility application where the content is flexible then you would most likely want the window to remain the same size.

We previously had the facilities for both, or at least the illusion of both with MenuHeight(), StatusBarHeight(), and ToolBarHeight() not being cross-platform. Now that we've been made aware that this was never a solution, we're having this argument.

The problem is that the argument is about which behavior is better where the correct answer is: it depends.

[Dude]

If someone could post a quick Windows API way to get StatusBarHeight() and ToolBarHeight() then I'd be 100% happy.

MenuHeight() is no problem because it can be found with GetSystemMetrics_(#SM_CYMENU).

[Fred]

I agree autoresizing window can be not the expected behavior. I will add a flag to autoresize it if the programmer wants this feature, else the inner area will be shrinked (default).