Delphi:框架属性在我期望的时候没有更新(它们被卡住了)

发布于 2024-11-28 05:39:18 字数 156 浏览 1 评论 0原文

我在表格上有一个框架。当我更改框架(添加/删除按钮、标签)时,表单上不会出现任何更改,或者控件在表单中具有框架中的其他位置。如果要从表单中删除框架并重新添加->好的。

为什么?我记得 Delphi 2010(现在的 Delphi XE)中没有任何问题。

谢谢。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

我ぃ本無心為│何有愛 2024-12-05 05:39:18

因此,您创建了一个框架,然后将其实例拖放到另一个窗体上,问题是后来对原始框架所做的更改不会立即显示,直到您删除该实例并重新拖放它?

您不需要删除框架,只需右键单击并选择您希望其属性来自其主(原始框架)属性的控件,然后单击恢复为继承。奇怪的是,“全选”在框架中不起作用。

这是我避免使用框架的原因之一。我希望框架有一个“不允许自定义”属性(AllowCustom=false),通过不允许框架具有这种奇怪的双属性集,可以防止任何设计时 DFM 冲突。

规范化框架的另一种方法是右键单击并以文本形式查看表单,然后将框架缩小为:

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

现在它根本不包含覆盖的属性。

如果我将其中一个控件拖动到其他位置(即使是意外),则在已删除框架的 DFM 中会发生以下情况:

 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

DFM 中的这些额外内容会干扰您在其他级别所做的更改。通常添加额外的控件和删除控件是没有问题的(额外的控件应该在添加时自动显示,而删除的控件应该消失),但是由于定位问题(控件重叠/等)的影响,效果可能是你不这样做稍后才能看到变化。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文