[5.60b1] Static control over client area?!

[chi]

I really hope this is not intentional! Windows created with 5.60b1 have now a static control (Label) on top of the client area. So changing GCL_HBRBACKGROUND or intercepting WM_ERASEBKGND is completely ineffective.
This behavior would break a lot of code IMHO

Code: Select all

OpenWindow(0, 0, 0, 320, 200, "", #PB_Window_SystemMenu|#PB_Window_MinimizeGadget|#PB_Window_MaximizeGadget|#PB_Window_SizeGadget|#PB_Window_ScreenCentered|#PB_Window_Invisible)
SetClassLongPtr_(WindowID(0), #GCL_HBRBACKGROUND, GetStockObject_(#DKGRAY_BRUSH))
HideWindow(0, #False)
While WaitWindowEvent() ! #PB_Event_CloseWindow : Wend

[netmaestro]

Let's hope it's a mistake as that's not the only thing it breaks - can't draw to WindowOutput() anymore.

In the meantime this will set it back to normal:

Code: Select all

DestroyWindow_(GetWindow_(WindowID(0), #GW_CHILD))

[chi]

can't draw to WindowOutput() anymore.

Good point! Not to mention the performance impact while resizing a window...

@Fred: May I ask for the reason behind this change?

[kenmo]

Related to this?
http://www.purebasic.fr/english/viewtop ... 4b#p501154

[Fred]

It is intentional as it's the now the gadget container. Using this, we can shift it to adjust the client area when using a toolbar or menu for example.

[chi]

Are those adjustments really worth the damage? Every code/3rd party plugin rendering to/from the native client area would be broken and needs a special fix for PB only. Resizing is a little bit slower due to the additional control and might also flicker with current anti-flicker workarounds.

I'd be happy to help find a maybe better solution for the adjustments!

[IdeasVacuum]

Are those adjustments really worth the damage?

I very much doubt it

[netmaestro]

Too drastic a step for such meager gain imho. I hope the team will reconsider this one.

[chi]

@Fred: Just an idea... Why don't you use a flat FrameGadget (button control, BS_GROUPBOX) instead of the static control? Get rid of the border and you've got a hollow gadget container.

But I'd still prefer the "no extra control" version

[chi]

After reading a few new posts I've got the bad feeling we have to stick with this new container

From my point of view, developing a skin engine (dll) that should hopefully work in any programming language, I have to write a 2nd subclass only for PB! One for the usual window (Frame + Client = 1 Callback) and one for the new static control on top. The new container also natively ignores GCL_HBRBACKGROUND, so you have to subclass now in order to change the background. I'm not saying it can't be done, but it's annoying and pretty time consuming (runtime + writing more code). And for what? So we can have self-adjusting controls IF we decide to toggle Menu, Toolbar or Statusbar after the window was created... We could do such a simple task manually without breaking so much already existing code! As you can see, I still don't get the powerful reason behind this change... But maybe that's just me!

Following code was written having a dll in mind, where the user most likely only passes the handle of the window. WindowId(), IsMenu(), IsStatusbar(), ... don't function within a dll for an external window.
Also the window is not vertically centered anymore, unless you call HideWindow(0, 0, #PB_Window_ScreenCentered) a second time.

Code: Select all

LoadImage(0, #PB_Compiler_Home + "Examples\3D\Data\Textures\Geebee2.bmp")

OpenWindow(0, 0, 0, 800, 500, "title", #WS_OVERLAPPEDWINDOW|#PB_Window_ScreenCentered|#PB_Window_Invisible)

CreateMenu(0, WindowID(0))
MenuTitle("File")

CreateToolBar(0, WindowID(0))
ToolBarStandardButton(0, #PB_ToolBarIcon_New)
ToolBarStandardButton(1, #PB_ToolBarIcon_Open)
ToolBarStandardButton(2, #PB_ToolBarIcon_Save)

CreateStatusBar(0, WindowID(0))

Global brush = CreatePatternBrush_(ImageID(0)) : FreeImage(0)
SetClassLongPtr_(WindowID(0), #GCL_HBRBACKGROUND, brush)

;{ extra code only for the new gadget container ;(
  ;;----------------------------------------------
  Global oldProc
  Procedure WndCallback(hWnd, Msg, wParam, lParam)
    Select Msg
      Case #WM_ERASEBKGND
        GetWindowRect_(GetParent_(hWnd), wRect.RECT)
        GetClientRect_(hWnd, cRect.RECT)
        If GetMenu_(GetParent_(hWnd))
          menu_offset = GetSystemMetrics_(#SM_CYMENU)
        EndIf
        hStatusBar = FindWindowEx_(GetParent_(hWnd), #Null, "msctls_statusbar32", #Null)
        If hStatusBar
          GetWindowRect_(hStatusBar, sRect.RECT)
          stb_offset = sRect\bottom - sRect\top
        EndIf
        tb_offset = wRect\bottom - wRect\top - cRect\bottom - cRect\top - (GetSystemMetrics_(#SM_CYFRAME)*2 + GetSystemMetrics_(#SM_CYCAPTION))
        SetBrushOrgEx_(wParam, 0, menu_offset + stb_offset - tb_offset, 0)
        FillRect_(wParam, cRect, brush)
        ProcedureReturn 1
    EndSelect
    ProcedureReturn CallWindowProc_(oldProc, hWnd, Msg, wParam, lParam)
  EndProcedure
  
  Procedure PropEnumProc(hwnd, *lpszString, hData)
    If *lpszString >> 16
      If PeekS(*lpszString, 14) = "PB_GadgetStack"
        ProcedureReturn #False
      EndIf
    EndIf
    ProcedureReturn #True
  EndProcedure
  
  newGadCon = GetWindow_(WindowID(0), #GW_CHILD)
  If newGadCon
    If EnumProps_(newGadCon, @PropEnumProc()) = 0
      oldProc = SetWindowLongPtr_(newGadCon, #GWL_WNDPROC, @WndCallback())
    EndIf
  EndIf
  ;;----------------------------------------------
;}

HideWindow(0, 0)
While WaitWindowEvent() ! #PB_Event_CloseWindow : Wend
DeleteObject_(brush)

[Fred]

If you think the groupbox instead static could solve the transparency issue I could give it a try. To understand better the problem, see the code I posted in this thread:

http://www.purebasic.fr/english/viewtop ... 60#p501160

[chi]

If you think the groupbox instead static could solve the transparency issue I could give it a try.

It could solve the transparency issue but might also raise other difficulties?!

To understand better the problem, see the code I posted in this thread: viewtopic.php?p=501160#p501160

And for what? So we can have self-adjusting controls IF we decide to toggle Menu, Toolbar or Statusbar after the window was created...

I was already referring to your example in this thread . And comparing the Pros and Cons about this functionality I wouldn't implement it at all!


Other question: If we use

Code: Select all

DestroyWindow_(GetWindow_(WindowID(0), #GW_CHILD))
UseGadgetList(WindowID(0))

in the mainthread, what other functions then WindowWidth() and WindowHeight() are affected and return a wrong value?
Because it would be much easier to tell customer using PB and my dll to just include above code and don't use those two functions... And I don't have to change a single line in my dll

[IdeasVacuum]

Not sure that either the StatusBar or the Toolbar are that popular anyway. StatusBar is unnecessary for most apps and looks too old fashioned anyway. Toolbar, even now, is too restrictive. I make my own toolbars with a flat container - this allows any size button and you are not limited to just buttons.

[chi]

Not sure that either the StatusBar or the Toolbar are that popular anyway.

I'd second that without hesitation BUT they are still standard controls and for that they should/must be included in such decision.
Imagine no more StatusBar and Toolbar in PB... It would be an outrage! It's a no no like putting a Gadget over the client area so it's completely covered... Wait, uhmm... What??

[IdeasVacuum]

..indeed, but they are not important enough to require a drastic change to everything else.