[5.00] PanelGadget Alignment Problem

[Blankname]

When gadgets are placed inside the PanelGadget, they are aligned to the right for some reason. The form designer is right, the generated code is right, so I think it's a internal PB problem.

Bug: Objects inside PanelGadget() are being indented to the right by an extra 4px.
Image: http://i45.tinypic.com/vxew3l.png

Code: Select all

Global Window_2

Global Panel_0, Frame3D_0, ProgressBar_0, ScrollArea_0

Procedure InitWindow_2()
  Window_2 = OpenWindow(#PB_Any, 0, 0, 600, 400, "", #PB_Window_SystemMenu)
  Panel_0 = PanelGadget(#PB_Any, 10, 10, 580, 380)
  AddGadgetItem(Panel_0, -1, "Tab 1")
  Frame3D_0 = Frame3DGadget(#PB_Any, 10, 8, 560, 90, "Frame")
  ProgressBar_0 = ProgressBarGadget(#PB_Any, 10, 108, 560, 20, 0, 0)
  ScrollArea_0 = ScrollAreaGadget(#PB_Any, 10, 138, 560, 210, 760, 410,1)
  CloseGadgetList()
  CloseGadgetList()
EndProcedure

Procedure Window_2_Events(event)
  Select event
    Case #PB_Event_CloseWindow
      ProcedureReturn #False

    Case #PB_Event_Gadget
      Select EventGadget()
      EndSelect
  EndSelect
  ProcedureReturn #True
EndProcedure

InitWindow_2()

Repeat
  event = WaitWindowEvent()
Until Window_2_Events(event) = #False

Also posted here: http://purebasic.fr/english/viewtopic.php?f=22&p=400917
I moved it here as it does indeed seem to be a internal PB problem.

[BorisTheOld]

RTFM - it's a feature not a bug.

http://www.purebasic.fr/english/viewtop ... 22&t=52910

[Blankname]

RTFM - it's a feature not a bug.

http://www.purebasic.fr/english/viewtop ... 22&t=52910

Either way its still a bug, as the form designer on windows is not generating the right code for proper operation. The form designer is generating code like this.

Code: Select all

If OpenWindow(0, 0, 0, 400, 200, "PanelGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  PanelGadget(0, 10, 10, 380, 180)
  AddGadgetItem(0, -1, "Tab 1")
  PanelGadget(1, 10, 10, 360, 140)
  AddGadgetItem(1, -1, "Tab 2")
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

When it should be.

Code: Select all

If OpenWindow(0, 0, 0, 400, 200, "PanelGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  PanelGadget(0, 10, 10, 380, 180)
  AddGadgetItem(0, -1, "Tab 1")
  PanelGadget(1, 7, 7, 360, 140)
  AddGadgetItem(1, -1, "Tab 2")
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

The old form designer set x to 8 for all of its inside controls. But its suppose to be different for a couple of different controls. To get these two different controls perfectly centered inside a existing PanelGadget(), with a grid size of 10 "x" has to be set to as follows.

Code: Select all

PanelGadget() = 7
All Other Gadget = 6

You can use paint and just snip one side, and drag it over the other to see if they line up exactly (what I have done). Tho again this changes once someone changes their grid size...

[BorisTheOld]

When gadgets are placed inside the PanelGadget, they are aligned to the right for some reason. The form designer is right, the generated code is right, so I think it's a internal PB problem.

Definitely not an internal problem, as the Panel is behaving exactly as documented. However, I'm puzzled why it was designed to have the internal padding, because it seems to serve no purpose.

Our PanelItem class includes a container gadget that we place over the full area of the panel gadget (excluding the tab area). We do this using a negative origin, which the panel gadget doesn't seem to mind. We then build our design on the container rather than the underlying panel gadget item.

We use auto-resizing with all our GUI classes and often use coloured tab panels, so eliminating that annoying padding on the panel gadget has many benefits. We also use our own in-house designer. But on account of my extreme old age I'd forgotten that the PB designer would have to take account of the padding.

So if the PB Designer isn't giving the correct code, then yes, there must be a bug in it.

[Polo]

I'm not quite sure on how to tackle this problem as the padding is relative to OS, and the form designer should create OS-independent code.

[BorisTheOld]

We got around the problem by calculating the padding size at run time, and adjusting the gadget positions accordingly. This will automatically provide a cross-platform solution.

Here is a procedure from our PanelItem class. The margins are calculated when the first tab is created. Once calculated, the margins remain constant, no matter what resizing is done to the Panel.

Excuse the strange code, but it should give you some ideas.

Code: Select all

;
;-----------------------------------------------
;
PrivateSubroutine(PanelItem, UpdatePanelItemSize)      (ByVal(Me, strPanelItem))
;
;  UpdatePanelItemSize                 update the panel item size
;
;
  Local(oGenericPanel, objPanel)                                               ; 16384 : generic reference to a tab panel object
  Local(iParentWidth, typInt32)                                                ; 16458 : parent container width (pixels)
  Local(iParentHeight, typInt32)                                               ; 16459 : parent container height (pixels)
  Local(iPanelWidthMargin, typInt32)                                           ; 16496 : width margin for a tabbed panel
  Local(iPanelHeightMargin, typInt32)                                          ; 16497 : height margin for a tabbed panel
;
;  Note:
;
;  The panel items are automatically resized when the panel is resized.
;
;  This procedure refreshes the actual size info for panel items, prior to
;  their child objects being resized.
;

  oGenericPanel = Me\exoParent                                                 ; reference the parent panel

  iParentWidth   = Get(oGenericPanel, exiActualWidth)
  iParentHeight  = Get(oGenericPanel, exiActualHeight)

  If IsTrue(Get(oGenericPanel, exlPanelMarginFlag))                            ; use the precalculated panel margins

    Me\exiActualLeft   = 0
    Me\exiActualTop    = 0
    Me\exiActualWidth  = iParentWidth  - Get(oGenericPanel, exiPanelWidthMargin)
    Me\exiActualHeight = iParentHeight - Get(oGenericPanel, exiPanelHeightMargin)

  Else                                                                         ; calculate the margins when the first tab is created

    Me\exiActualLeft   = 0
    Me\exiActualTop    = 0
    Me\exiActualWidth  = GetGadgetAttribute(Me\priGadgetNumber, #PB_Panel_ItemWidth)
    Me\exiActualHeight = GetGadgetAttribute(Me\priGadgetNumber, #PB_Panel_ItemHeight)

    iPanelWidthMargin  = iParentWidth  - Me\exiActualWidth
    iPanelHeightMargin = iParentHeight - Me\exiActualHeight

    Set(oGenericPanel, exiPanelWidthMargin,  iPanelWidthmargin)                ; save the panel margin sizes in the parent panel
    Set(oGenericPanel, exiPanelHeightMargin, iPanelHeightmargin)

    Set(oGenericPanel, exlPanelMarginFlag, True)                               ; panel margins have been calculated

  EndIf

EndSubroutine

[Blankname]

Any news on this being fixed? I tested with ButtonImage() and still same result on 5.00. Can anyone confirm the panel alignment problem is fixed for 5.10 release (I don't use beta packages). It seems to be with only certain controls.

[rsts]

Any news on this being fixed? I tested with ButtonImage() and still same result on 5.00. Can anyone confirm the panel alignment problem is fixed for 5.10 release (I don't use beta packages). It seems to be with only certain controls.

You don't need to "use" beta's, but they are out there for testing. Which is what you should do if you want to see if something is fixed to your satisfaction.

cheers

[Blankname]

Any news on this being fixed? I tested with ButtonImage() and still same result on 5.00. Can anyone confirm the panel alignment problem is fixed for 5.10 release (I don't use beta packages). It seems to be with only certain controls.

You don't need to "use" beta's, but they are out there for testing. Which is what you should do if you want to see if something is fixed to your satisfaction.

cheers

I'm easily satisfied if someone can confirm a fix has been implemented. Running the code in the first post via the IDE compiler, and posting a resulting screen would also confirm if it has been fixed or not in the latest version of PB. Tho I will take ones word if Fred or Polo have confirmed it fixed.