一年之后,我正试图做一些事情,因为这个问题显示How do I use enum values when their type is defined indirectly in another unit?我被其他用户鼓励离开这种心态,因为出于各种原因这不是一个好方法。
好吧,几天前我正在为我们的软件做一些自定义对话框,我想使用delphi提供的一些类型而不是声明我的拥有。令我惊讶的是文件vcl.dialogs
具有相同的技术,我鼓励不要像代码所示那样做:
{ Message dialog }
mtWarning = System.UITypes.TMsgDlgType.mtWarning;
mtError = System.UITypes.TMsgDlgType.mtError;
mtInformation = System.UITypes.TMsgDlgType.mtInformation;
mtConfirmation = System.UITypes.TMsgDlgType.mtConfirmation;
mtCustom = System.UITypes.TMsgDlgType.mtCustom;
mbYes = System.UITypes.TMsgDlgBtn.mbYes;
mbNo = System.UITypes.TMsgDlgBtn.mbNo;
mbOK = System.UITypes.TMsgDlgBtn.mbOK;
mbCancel = System.UITypes.TMsgDlgBtn.mbCancel;
mbAbort = System.UITypes.TMsgDlgBtn.mbAbort;
mbRetry = System.UITypes.TMsgDlgBtn.mbRetry;
mbIgnore = System.UITypes.TMsgDlgBtn.mbIgnore;
mbAll = System.UITypes.TMsgDlgBtn.mbAll;
mbNoToAll = System.UITypes.TMsgDlgBtn.mbNoToAll;
mbYesToAll = System.UITypes.TMsgDlgBtn.mbYesToAll;
mbHelp = System.UITypes.TMsgDlgBtn.mbHelp;
mbClose = System.UITypes.TMsgDlgBtn.mbClose;
所以基本上delphi会对最初在System.UITypes
上向vcl.dialogs
文件声明的此类型进行复制。
所以问题是:为什么他这样做有合理的解释?德尔福坏了吗?这种做法不是那么糟糕吗?如果没有足够的方法来使用它吗?
答案 0 :(得分:3)
这些不是类型别名。这些实际上是常量。这些是真正的常量而不是类型常量。这意味着您可以导入Vcl.Dialogs
或System.UITypes
并使用mtWarning
。
Embarcadero已经做到这一点,允许跨平台使用此类型,并保持与现有代码的向后兼容性。引入FireMonkey时出现了跨平台需求。
需要在Windows以外的平台中使用此类型。但是,VCL仅适用于Windows。因此,在VCL名称空间单元中声明的类型不起作用。因此引入了System.UITypes
。为了允许现有代码继续编译,设计人员选择从Vcl.Dialogs
导出相同的值。
新代码应使用System.UITypes
来访问此枚举类型。
答案 1 :(得分:2)
有一种更好的方式来做你想要完成的事情。在不同的单元中使用相同的枚举类型会导致维护问题,并且您并不真正需要它来实现您想要完成的任务。
据我所知,没有更好的方法来做VCL开发人员想要完成的事情。 VCL开发人员做确实需要相同的枚举类型才能在两个独立的单元中使用,并准备好应对由此引起的任何维护困难。如果这是任何其他图书馆,他们可以说"只需将System.UITypes
添加到您的uses
列表",然后从Vcl.Dialogs
中删除该类型。但是,VCL需要付出很大努力来保持兼容性,以确保使用旧版Delphi编译的代码仍然可以使用更高版本编译。它需要,因为任何以前无法编译的有效代码都是潜在的丢失客户,因为Delphi本身远远超过各种第三方库。
答案 2 :(得分:1)
解释很简单 - 有太多的旧代码对“System.UITypes'' System.UITypes'''和' vcl.dialogs'。他们只知道对话框''''模块。
这个旧的程序仍然可以编译运行。因此,我认为它只是向后兼容性和跨平台开发的预备。