修改 VCL 组件代码答案

【问题标题】：Modifying VCL Component CODE修改 VCL 组件代码
【发布时间】：2011-10-28 10:35:17
【问题描述】：

我需要更改组件中的功能。当您收到“您无法覆盖此”消息，或者您需要更改私有方法中的代码（“基类中不存在该方法”消息）时，您会怎么做，导致组件无法下降？

【问题讨论】：

标签： delphi components vcl

【解决方案1】：

如果我遇到这个问题，

我首先尝试从组件或其 CustomXXX 祖先继承，看看是否能解决问题。如果没有，
我更深入，即尝试拦截进来的消息。这可以动态完成。如果结果太深，因为必须构建的代码太广泛，或者如果我仍然需要访问我无法访问的项目，
我尝试破解。一种技巧是将组件和依赖代码复制到具有不同名称的新单元，重命名组件并修改需要修改的内容。
有时我只需要重做一两个方法就可以使我的新行为成为可能。

永远不要忘记给单元和组件一个不同的名称（可能从原始组件或其祖先之一继承，因此它们保持在相同的层次结构中）。切勿修改原始源代码，然后重新编译 VCL。这是维护的噩梦。

我不喜欢插入器类，即从原始类继承的与原始类具有相同名称但行为不同的类。它们的功能取决于包含在uses 子句中的顺序，这对我来说似乎不太可靠。我不建议这样做。

但我所做的很大程度上取决于问题。我认为不能（或不应该）给出涵盖所有情况的一揽子建议。

但我的主要建议是：不要修改原始单位，始终将新代码放在新单位 em> 并使用一个新的类名。这样，原始版本和修改后的版本可以和平共存，在 IDE 中也是如此。

【讨论】：

只要运行时包被禁用，并且您不需要对interface 部分进行任何更改，那么您就不需要重命名单元或其类。只需复制项目本地的单元，将副本添加到项目中，然后根据需要修改其implementation 部分。它将在编译期间覆盖 VCL 的本机代码。
对不起，Remy，但不这样做是，IMO，不好的做法和维护的噩梦。单位和班级的重命名是 IMO 唯一优雅的方式来做到这一点。技术上没有必要，但不重命名是 IMO 不好的做法。
更改单元和类名需要更改引用它们的代码。保留原始名称并不罕见，因此不需要更改现有代码，尤其是在意图更改/修复内部行为（即修复 RTL/VCL 错误）的情况下。
我会站在雷米这边。有时当我在测试东西时（尽管我从未在部署中这样做过），我只是将 VCL 源单元复制到本地目录，然后编辑和重新编译。恕我直言，重命名类，当它只是修改同一个类时，是维护的噩梦。如果在以后的 Delphi 版本中修复了“错误”/功能，那么您需要做的就是归档该单元，然后您将返回到原始 VCL。如果您重命名单元和类，这是不可能的。并且更容易合并未来版本的新单元版本。
Changing the unit and class names requires changing code that refers to them. 是的，确实如此，因为这表明您使用的是经过修改的组件。修改 VCL 中的原件是，IMO，一个坏主意，因为它使您的 VCL 与其他人的 VCL 不兼容，并且使您的代码成为维护的噩梦。任何错误都可能是由于您的修改或原始代码造成的。如果将它们分开，会发生什么就很清楚了。

【解决方案2】：

在修改私有方法或其中的行为时，有一些（主要是 hacky）选项：

修改原始源，重新编译单元并按照建议here使用更改后的dcu；从来没有这样做过，但我认为当您的代码使用新的 dcu 但其他 VCL 代码不这样做时，这可能会让您头疼
通常组件行为由大量窗口消息控制 - 看看您是否可以通过修改对其中一些消息的反应来实现更改；您可以覆盖消息处理方法（带有message 关键字的方法），即使它们被声明为私有，您也可以替换 WndProc
您可以使用像 this 这样的技巧来修补投射
您可以使用答案here 中描述的一些迂回机制

或者你可以得到另一个组件。

【讨论】：

到您的第一点：我宁愿复制单元，重命名它和我更改的类，并删除我不需要的所有内容（如有必要，“包括”原始单元以定义常量，使用的类型等）。这避免了大部分的头痛。永远不要修改原始来源，那是维护的噩梦。
我同意。这更像是“修改、编译、使用 dcu、撤消修改”。但你的方法听起来更好。只需复制单位并根据需要进行更改。缺点仍然是频繁更新的第三方组件也需要一些维护。但如果是 VCL，那么下一个 bug 修复/更新将是 Delphi 的下一个版本，所以不用担心。