... For this reason, it is worth sticking to the default frame naming convention and having a panel on the form into which a frame can be dropped with client alignment.
It occurred to me overnight that, while using client alignment is pretty much unavoidable, it might be contributing to the problem: if the containing form is opened hence loads the frames, one of things it might try to save is the actual size and position of some of the components.
However, attempting to prove or disprove the above might have helped localise the problem. I'd got a "clean" collection of .lfms, i.e. no spurious inherited blocks. I opened the form that contains various frames, added a space to the corresponding .pas file, and closed the form.
On inspecting the form, it had gained inherited blocks for TCheckGroup, TRadioGroup, TCheckBox, TGroupBox and TStringGrid controls, but not for various page controls, buttons etc. The distinguishing feature of the CheckGroup and RadioGroup controls in particular is that they tend to have an ItemIndex and/or various checked states that are set to non-default values as part of the design process... however it is sizes rather than these which are being saved.I think it's something to do with anchors: almost all of the inserted blocks look like this:
inline FramePulse1: TFramePulse
Height = 477
Width = 691
Align = alClient
ClientHeight = 477
ClientWidth = 691
DesignLeft = 1320
DesignTop = 166
inherited CheckBoxPulseEnabled: TCheckBox
AnchorSideRight.Control = FramePulse1
Left = 594
end
end
Note the way that a component is anchored to a frame. and that frame has been aligned alClient.
MarkMLl