Delphi: frame properties do not update when I expect them to (they get stuck)

Question

I have a frame on a form. When I change the frame (add/delete buttons, labels) no changes appear on the form or controls have other positions in the form that in the frame. If to delete the frame from the form and add it again -> Ok.

Why? As I remember there were no problems in Delphi 2010 (now-Delphi XE).

Thanks.

Michikomichon

You can prevent these changes with the Lock Controls command in the Edit menu. My Ctrl-L hotkey designtime package might be handy for toggling this menu item. – Trista

I wish there was just a way to lock just the frames. :-) – Vaticinate

Answer 1

So you had created a frame, and then dropped an instance of it on another form, and the problem is that later changes made to the original frame are not immediately shown until you delete the instance and re-drop it?

You don't need to delete the frame, just right click and select the controls you want to have their properties come from their master (original frame) properties, and click Revert to inherited. Oddly enough, Select All doesn't work in frames.

This is one of the reasons I avoid frames. I wish frames had a "don't allow customization" property (AllowCustom=false) that would prevent any designtime DFM conflicts by not allowing frames to have this weird double-sets-of-properties.

Another way to normalize your frames is to right click and view the form as text, and reduce your frame to this:

 inline Frame61: TMyFrame61
    Left = 0
    Top = 0
    Width = 500
    Height = 500
    Align = alNone
    TabOrder = 0
    ExplicitLeft = 31
    ExplicitTop = 33
  end

Now it contains no overridden properties at all.

If I drag one of the controls somewhere else (even accidentally), the following happens in the DFM where the Frame has been dropped:

 inline Frame61: TMyFrame6
    Left = 0
    Top = 0
    Width = 500
    Height = 500
    Align = alNone
    TabOrder = 0
    ExplicitWidth = 527
    ExplicitHeight = 337
    inherited Edit2: TEdit
      Left = 19
      Top = 77
      ExplicitLeft = 19
      ExplicitTop = 77
    end   
  end

These extra bits of stuff in the DFM interfere with changes that you made at the other level. Normally adding extra controls and deleting controls is no problem (extra controls should show up when added, automatically, and deleted controls should go away), but with the effects of positioning problems (control overlaps/etc) the effect can be that you don't see the change until later.

Vaticinate

+1 for "Revert to inherited." I didn't know that. I've been deleting the frame from the form and then adding it again. This is much better! Thanks, Warrne. – Lorenz

+1 for "I avoid frames". For simple projects (like pseudo-forms placed in a tabbed panel), they are just fine. But when you start playing with inheriting frames... it's just a nightmare to maintain! – Hydroquinone

"Oddly enough, Select All doesn't work in frames." - Hold down the Ctrl key, and drag to select all controls in the instance of the frame. Then right-click in the frame, and Revert to Inherited. Frames are cool and very useful, if not slightly idiosyncratic (is that a word?). Almost all problems with frames are caused by editing the instance (very easy to do by mistake), rather than the original. – Alisha

I have found it much better to do runtime composition of classes, some of which are "Panels or sub-Form like objects" than to use Frames. The fact that it's easy to do bad things, that are nearly invisible is key to why Frames are bad. They are not only slightly idiosyncratic, they are dodgy as hell. – Vaticinate