2
votes

I have a FireMonkey app with a GridPanelLayout, aligned to client. It's got 6 columns and 16 rows. Controls include glyphs, edits, and buttons. The TEdits span multiple columns, and the TButtons span both multiple columns and rows. The controls are currently all aligned to client.

When I compile and run on Windows everything looks and acts as expected. However, on Android devices (I tried two, Android 6.0.1, and Amazon FireOS) none of the controls span more than one column or row. They're each just one cell big. Instead of spanning 6 cols, TEdits span just 1 col; instead of spanning 2 cols and 2 rows, TButtons also span 1 col and 1 row.

Why won't the controls span multiple columns or rows on Android?

1
I use a FlowLayout and the controls render fine on Android and iOS. Having said that, what do you mean by "one cell big"? Do you mean there is only one cell? A pic might helpDave Nottage
I'm not sure if this bug is also present in FMX, but on VCL, the ColSpan and RowSpan attributes of elements in a TGridPanel often get lost on subclasses. Your Android view is probably a subclass of your master view. But I suppose this bug would already manifest at design time in the IDE which is not the case, right? I also had the feeling (can't prove it), that building your project with no views (just the DPR file) open in the IDE helps.Günther the Beautiful
@DaveNottage, I edited the text for clarity.Al C
@GünthertheBeautiful, I checked the IDE view and saw the bug manifested in Delphi's simulated picture of my test phone. Checking other UI's, though, I did NOT see it manifested. So I tried deleting the {$R ANDROID} directive and, lo and behold, bug went away! ... If you'd like to write this as an answer, along with any additional explanation, I will accept it.Al C
As far as I can tell, there's no valid {$R ANDROID} directive, since $R is either immediately followed by + or -, or by a valid filename, unless ANDROID is actually a file in your project path, because the compiler will soon complain if it is not thereDave Nottage

1 Answers

2
votes

Both VCL and FireMonkey fail to store the ControlCollection of a TGridPanel / TGridPanelLayout correctly when a frame/form gets subclassed or a frame placed on another frame/form.

This bug applies to both VCL and FMX. It has been reported to the old QC as early as 2011 but never been fixed (examples: #92298, #123225).

Example: Drop a TGridPanelLayout with a TButton in it on a TFrame:

object GridPanelLayout1: TGridPanelLayout
    (...)   
    ControlCollection = <
      item
        Column = 0
        ColumnSpan = 2
        Control = Button1
        Row = 0
        RowSpan = 2
      end>
    object Button1: TButton
      Align = Client
      Size.Width = 421.000000000000000000
      Size.Height = 257.000000000000000000
      Size.PlatformDefault = False
      TabOrder = 0
      Text = 'Button1'
    end
end 

When you later subclass the frame, the IDE tends to store a lot of redundant properties for the components it inherited from the base class. Usually after the first press of F9, the ColumnSpan and RowSpan properties get removed for no reason. On the subclass, it then looks something like this:

inherited GridPanelLayout1: TGridPanelLayout
    (...)
    ControlCollection = <
        item
            Column = 0
            Control = Button1
            Row = 0
        end>
    inherited Button1: TButton
        Size.Width = 210.500000000000000000
        Size.Height = 128.500000000000000000
    end
end

Note how the Size property has changed. Also, the ControlCollection items get re-defined, yet the ColumnSpan and RowSpan properties are missing completely. This is the cause.

This bug applies to you because in FMX, specialized views for specific platforms are implemented as subclasses of the master view.

A version control system helps detecting when redundant properties sneak into DFM files. In the above example, it is legal to completely remove the inherited GridPanelLayout1 block when your subclass does not change it. Moreover, I advise you to build your project with no form designer window open as it often will corrupt your DFM file and re-add the redundant properties at every opportunity.