不要在Destroy中做启动别的窗体的动作，把启动代码放到最前面READ EVENTS之后，另外再开一个窗体（即前面的窗体是另外一个程序执行完毕继续执行另外一个），就是15楼所说另一种解决办法。代码要放在逻辑上正确的位置，不要随手，固然可以达到目的，但将来你自己或别人维护时，就很难根据逻辑去定位你的代码，也难维护。

[此贴子已经被作者于2015-12-8 13:50编辑过]

*MyForm.PRG
*红字哪里有什么作用。。。
DEFINE CLASS MyForm AS Form

    PROCEDURE Arrange
        FOR EACH obj IN This.Controls FOXOBJECT
            IF (VARTYPE(obj.CanArrange) == "L") .AND. obj.CanArrange
                obj.Arrange
            ENDIF
        NEXT
    ENDPROC

    PROCEDURE Activate
        This.Arrange
    ENDPROC
   
    PROCEDURE Resize
        This.Arrange
    ENDPROC
   
    PROCEDURE Destroy
        CLEAR EVENTS
    ENDPROC
   
ENDDEFINE

检索窗体内部的所有控件，看是否包含Arrange方法，有的话就执行它，这用于本窗体的外观被改变时批量调整所有控件的布局，后面不用再费神了，那是自动的。

我也刚想问同样的问题　　　看到一个VFP的帮助文档　　　也没看太懂　　　　看到你的解释　　　　我懂了一点点　　　以后在程序中多用几次　　　　可能明白更多些

你运行时拖拉一下我现在这个程序显示的窗口尺寸，会看到效果——后面写的类不用主动执行Arrange了，你只要把每个容器的Arrange写好，它会在需要的时候自己触发。这就是面向对象继承的有点。

PROCEDURE Arrange
        WITH This.cmdLogin
            .Top = (This.Height - .Height) / 2
            .Left = (This.Width - .Width) / 2
        ENDWITH
 ENDPROC
你提到重定义问题，上面这里是不是重定义了Arrange，怎么还能实现自动调整窗口大小

*这里的Destroy，是真的重新定义了，不会发出CLEAR EVENTS
DEFINE CLASS C_Login AS MyForm
    Caption = "登陆"
    ShowWindow = 1
    WindowType = 1
    Width = 300
    Height = 200
    AutoCenter = .T.
    PROCEDURE Destroy
        * 重写Destroy否决父类中默認CLEAR EVENTS的动作
    ENDPROC
ENDDEFINE

办法好

好像，T版的这里列子，精髓就在这个Arrange....
慢慢研究，看看这个Arrange变化，，

你看我MyForm父类中是在什么事件触发下主动调用本类的Arrange方法？是在这个父类的Arrange方法中，再依次调用本类实例对象中所有容器的Arrange方法。

我不用挂靠，是因为动态计算重新布局比挂靠有更多的灵活性，它可以依据窗体尺寸的实际大小变换布局，而不是死板的挂靠。vfp9的新功能有挂靠，但未必比最原始的手段管用，何况，这种实现方式不存在兼容性问题，在vfp6中也可以用，挂靠就不可以了。