TFrame继承重构 [英] TFrame inheritance refactoring

问题描述

另一个TFrame IDE注册组件的问题。感谢所有的帮助，同行程序员。 ：）

Yet another TFrame IDE-registered-component question from me. Thanks for all the help, fellow programmers. : )

播放Darrian的TFrame继承建议这里：

Playing around with Darrian's TFrame inheritance suggestion here:

细节：

基本上，我有一个基于TFrame的组件，我已经注册到IDE，它的工作非常好。我正在开发一些姐妹组件，它们将分享大量现有组件的非视觉功能和属性。然后，将很多事情转移到父类/超类，然后新组件和旧组件都可以继承。

Basically, I have a TFrame-based component that I've registered to the IDE, and it has worked wonderfully. I'm now developing a few "sister" components which will share a great deal of the existing component's non-visual functionality and properties. It makes sense, then, to move a lot of that to a parent/superclass which both the new and the old components can then inherit from.

最好的方法是什么以这种方式重构TFrame继承？ （这可能也适用于TForm类的后代，不确定）。要注意什么注意事项？

What is the best way to "refactor" TFrame inheritance in this way? (This may apply to TForm-class descendants too, not sure). What are the caveats and things to watch out for?

示例：

例如，我尝试创建一个新的TFrame，没有任何东西，并且调用该框架TMyBaseFrame。然后修改我现有组件的类定义（让我们称之为TMyFrameTreeView）继承而不是TFrame。

I tried, for example, creating a new TFrame, with nothing on it, and calling that frame TMyBaseFrame. Then modified the class definition of my existing component (Let's call it TMyFrameTreeView) to inherit from that rather than TFrame.

它编译正常，但是当我尝试将其放在形式，我得到ClientHeight not found（或ClientHeight属性未找到），它不会丢弃在表单上。从相关的DFM中删除ClientHeight和ClientWidth造成严重破坏，而且他们最终还是在调整大小时被替换。我在后代类中注意到了ExplicitHeight和ExplicitWidth，我认为这是继承值的属性值覆盖，但不能确定。

It compiled fine, but when I tried dropping it on a form, I got "ClientHeight not found" (or "ClientHeight property not found"), and it wouldn't drop on the form. Deleting ClientHeight and ClientWidth from the related DFM wreaked havoc, and they ended up replaced upon resizing anyway. I noticed ExplicitHeight and ExplicitWidth in descendent classes, and am thinking that relates to property-value overrides from inherited values, but am not sure. Recreating an entirely new frame via New -> Inherited Items, and then copying everything over, hasn't yielded great results yet either.

最终注解 >

Final Note

我意识到这可能会很快凌乱，流式传输DFM文件和多代后代等....这是为什么我要求整体事情要注意的概念方面，而且还给出了一个特定的现实世界中更简单的版本的问题（在我看来，应该是可行的）。

I realize this could get messy quickly, with streaming DFM files and multiple generations of descendants, etc.... which is part of why I'm asking for the overall "things to look out for" conceptual aspect, but also giving a specific real-world simpler version of the problem as well (which seems to me, ought to be doable).

我已经创建了一个小的测试包来学习尝试，并且学习了很多，但是慢慢进行，并且您的任何指导/见解DelphiJedi Masters会有MOST赞赏。 ：）

I've created a little test package to hack around in learning attempts, and am learning a great deal, but it's slow-going, and any guidance/insight from you Delphi "Jedi Masters" out there would be MOST appreciated. : )

稍后再回答

以下两个答案都是有帮助的。同样，创建一个与正常TFrame没有任何变化的基本框架类，然后在添加任何属性，方法之前继承它，似乎可以极大地稳定继承流。

Both of the answers below were helpful. As well, creating a "Base Frame Class" which has NO changes from the normal TFrame, and THEN inheriting from that before adding any properties, methods, etc. seems to stabilize the inheritance streaming tremendously. Not sure why, but so far it has.

推荐答案

除了更改基本类 TMyFrameTreeView to TMyBaseFrame 将 TMyFrameTreeView 中的第一个单词更改为对象到继承。

In addition to changing base class of TMyFrameTreeView to TMyBaseFrame change the first word in the dfm file for TMyFrameTreeView from object to inherited.

这篇关于TFrame继承重构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！