Window Resize and Update under Linux not predictable

Targets Linux
1

I use a disclosure triangle to show and hide a detail panel in a very simple window. When the user activates the Disclosure Triangle, I unlock the existing controls from the bottom of the window and resize the existing window height to allow a GroupBox to be seen and make the GroupBox visible. On OS X it woks perfectly. However, on Linux the window does not always resize before I re-lock the existing controls to the bottom. This results in the window expanding after the GroupBox placement and show and the controls being repositioned at various moments in the resize.

Here’s my code from the DisclosureTriangle’s Action event:

  // Me = DisclosureTriangle, WQuickArchive is the window
  If Me.Value Then // user has activated the disclosure triangle
    stHideDetails.Text = "Hide Device Details"
    lbBackupPaths.LockBottom = False
    cbSessionArchiveMode.LockBottom = False
    cbTapeDoublerMode.LockBottom = False
    pbClearSelections.LockBottom = False
    Me.LockBottom = False
    stHideDetails.LockBottom = False
    WQuickArchive.UpdateNow
    WQuickArchive.Height = WQuickArchive.Height + (gbDeviceDetails.Height + 8)
    WQuickArchive.MinHeight = WQuickArchive.MinHeight + (gbDeviceDetails.Height + 8)
    WQuickArchive.Invalidate
    WQuickArchive.Refresh(true)
    WQuickArchive.UpdateNow
    gbDeviceDetails.Top = Me.Top + 26
    gbDeviceDetails.Visible = True
    gbDeviceDetails.LockBottom = True
    lbBackupPaths.LockBottom = True
    lbBackupPaths.LockBottom = True
    cbSessionArchiveMode.LockBottom = True
    cbTapeDoublerMode.LockBottom = True
    pbClearSelections.LockBottom = True
    Me.LockBottom = True
    stHideDetails.LockBottom = True
    gbDeviceDetails.Refresh(True)
  Else  // user has deactivated the disclosure triangle
  ...

That should hold the existing controls’ position, resize the window to include the previously hidden groupbox, re-lock the controls, and then continue. That is what it does on OS X.

Any ideas?

2

Found it - it appears that the LockTop = True is implicit if you set LockBottom = False for a control under OS X when LockBottom is True and the LockTop is not set. In Linux, this is not the case. If LockBottom is True, LockTop is not set and you set LockBottom to False, the control’s Top/Bottom lock state is now undefined.

By setting LockTop = True and then LockBottom = False the controls behave.

3

Well, more testing and more varying results.

It wasn’t as simple as what i did above, so now I’m back to my original scenario of the resize actions and code not running in a predictable or even determinate order.