标签: delphi-xe7

在Firemonkey中,我们可以使用TShadowEffect来绘制漂亮的阴影.

此阴影还会调整其不透明度和半透明度,以便在控件重叠时显示其下方的正确组件.

没有TShadowEffect:

使用TShadowEffect:

有没有办法在VCL表单中绘制相同的阴影效果而不嵌入FMX表单？

对于使用本机组件的多平台应用程序,标准的Delphi方法已不再适用.到目前为止,我们的结构只有部分:GUI(表单)和业务逻辑.我们现在需要将"Forms"部分拆分为两个,这在MVVM上下文中将是View和ViewModel.

View和ViewModel之间的绑定可以通过不同方式处理:

• Delphi中的LiveBindings
• DSharp(德尔斐法术)
• Delphi Spring(Spring4D)

可能会有更多.我知道这对某些人来说是一个宗教问题,但我仍然希望能得到客观答案:

如果您在Firemonkey应用程序中使用适合长期视角的多平台开发的解决方案:您做出的决定背后有哪些考虑因素？

我有一个源自TMemo的控件.在我第一次使用Delphi XE7 VCL样式之前,它工作得很好.在Delphi XE7下,样式不会应用于控件的滚动条.如果使用黑暗的主题/风格,它看起来很可怕,而滚动条是银色的.

尝试创建一个我们可以重现错误的最小项目我发现了一些非常有趣的东西:添加/删除随机代码行(或DFM控件)会使错误出现/消失.

问题:什么真正导致这种奇怪的行为以及如何解决它？

源代码在这里:

http://s000.tinyupload.com/index.php?file_id=24129853712119260018

我正在尝试解决此编译错误,仅在Debug配置中发生,并且仅在下面描述的情况下:

[dcc32 Fatal Error] MyIndyTCPChannel.pas(22): F2051 Unit IdIOHandlerSocket was compiled with a different version of IdGlobal.IdDisposeAndNil

我正在开发一个非常大的Delphi代码库,拥有250万行内部代码和300万行组件代码,其中包括几个大型商业Delphi组件套件(Developer Express,TeeChart等),以及大量代码库开源delphi组件,以及一个相当大的内部开发组件集,编号252个包,其中大约140个是设计时+运行时或设计时,其他是运行时包(也被加载到IDE中)在运行时,由其关联的设计时包中的DLL依赖项).

我们的主库路径已经优化到尽可能小,并且它包含Delphi附带的路径作为标准,再加上我们添加的三个,主要的是单个"OurCompanyLibraryDCU"文件夹,其中包含下面的文件夹我们使用的两个平台和两个配置:

c:\dev\OurCompanyLibraryDCU\Win32\Release
c:\dev\OurCompanyLibraryDCU\Win32\Debug
c:\dev\OurCompanyLibraryDCU\Win64\Release
c:\dev\OurCompanyLibraryDCU\Win32\Debug

上述每个文件夹都包含一个文件夹中的BPL,DCP和DCU文件集,用于该平台/配置组合.

在项目选项中使用了如下的宏,因此我们可以更改平台和配置,并正确解析目录:

$(OURCOMPANYLIBRARYDCU)\$(Platform)\$(Config)

OURCOMPANYLIBRARYDCU是一个环境变量,$(X)是在Delphi IDE的上下文中扩展环境变量的语法.

我正在尝试将最重要和最大的VCL应用程序项目(称为BigApp.dproj)构建,以便项目搜索目录仅包含我们的APPLICATION源文件夹,并且不需要项目搜索路径来包含我们所有的第三方组件LIBRARY源代码.为此,我们需要链接调试DCU或释放DCU.

到目前为止,除了可以使用Debug和Release DCU的情况外,我们一切正常.版本DCU位于库路径中,调试DCU位于IDE设置中的Debug DCU路径中.面对这两个库之间的选择,Delphi的链接器似乎失败,每当存在两组DCU时,这种形式的错误,当我单击Build,并且Build Configuration设置为Release时,我得到F2051错误.F2051错误的普通原因是存在多个不兼容的二进制DCU并且都是可访问的,并且链接器无法使其全部工作.但是,如果你想在库路径中同时使用Debug和Release DCU,我认为这种情况不会发生,因为Linker会为你选择调试或释放DCU.

如果我没有构建调试DCU,则不会发生上述问题.我怀疑我的调试DCU是微妙的"无效"或Delphi中的Debug-DCU选择算法不起作用,但不知道为什么,或如何解决这个问题.

多部分问题:

A.每个平台/配置组合都有一个文件夹,在单个文件夹中包含DCU,BPL和DCP,然后添加到已知导致问题的IDE库路径中？我是否需要三个子文件夹,每个平台+ config + filetype共有12个文件夹,或者我可以通过platform + config将它们保存在一起吗？

B.在包编译情况下,是否可以让IDE库路径包含OurCompanyLibraryDCU文件夹,并将该文件夹配置为DCP输出目录,包输出目录和单元输出目录？我担心的是,通过使输入文件夹和输出文件夹相同,有一种情况是编译器可能无法从.pas源重建单元,只是链接先前编译的DCU.

C.如果我发生了这个问题,我应该如何防止每次构建BigApp时从源代码编译超过250万行的组件LIBRARY代码,而只是通过DCU链接它们,并且仍然有调试并释放dcus正常工作？

D.如果我转到Win32\Debug文件夹并删除IdGlobal.dcu,我可以通过原始错误.这告诉我,我的包编译(用于调试配置)正在生成INVALID IdGlobal.dcu.这甚至可能吗？delphi可以默默输出乱码的DCU吗？

注意:我没有使用,也无法使用Runtime Packages来处理应用程序大小问题.

更新:我应该在这里做的第一件事是验证ZERO额外的DCU文件在我的硬盘驱动器上是任何地方,无论如何.这是标准的F2051错误建议.在我处理完这个问题后,我会更新这个问题.似乎Delphi本身可以将DCU从一个地方复制到另一个地方,或者不在CURRENT搜索路径中的虚假DCU可能已经在某个其他项目的搜索路径中.可能会出现一种坏DCU拷贝的桶式旅.一旦我确定发生了什么样的坏DCU代或副本,我就会更新问题.

更新2:我现在保证在构建之前不存在IdGlobal.dcu的额外副本,并且问题仍然存在.因此,问题随后打开了构建IdGlobal.dcu时使用的编译器选项,版本化了在Debug构建中构建BigApp.dproj时使用的编译器选项.

更新3:虽然我的所有程序包编译似乎都没有错误地完成,但是在启动DCC32.exe或MSBUILD.exe来构建程序包期间,它们似乎没有使用正确的库搜索路径.这个库路径不一致问题似乎是核心问题,感谢Rufo爵士指出这一点.

我知道关于浮点数的近似问题,所以我理解4.5如果它近似为4.4999999999999991,可以向下舍入到4.我的问题是为什么使用相同类型的32位和64位存在差异.

在下面的代码中,我有两个计算.在32位中,MyRoundValue1的值为4,MyRoundValue2的值为5.在64位中,它们都是4.不应该结果与32位和64位一致吗？

{$APPTYPE CONSOLE}
const
  MYVALUE1: Double = 4.5;
  MYVALUE2: Double = 5;
  MyCalc: Double = 0.9;
var
  MyRoundValue1: Integer;
  MyRoundValue2: Integer;
begin
  MyRoundValue1 := Round(MYVALUE1);
  MyRoundValue2 := Round(MYVALUE2 * MyCalc);
  WriteLn(IntToStr(MyRoundValue1));
  WriteLn(IntToStr(MyRoundValue2));
end.

我刚刚将'64位平台'添加到我的项目中,我的Delphi(XE7)不断生成一个巨大的RSM文件(这会增加编译时间).根据帮助,如果禁用"包含远程调试符号"选项,则不应该发生这种情况.

在我的情况下它被禁用.
还有别的东西要禁用吗？

我试图得到相同的drophadow窗口使用这个:

在我的形式的树视图控件上.

在我的研究中,我发现可以使用CS_DROPSHADOW(链接)在表单上创建这种阴影效果.
它是否可能以某种方式分配CS_DROPSHADOW或类似于控件？

为什么这段代码:

  w: word;
  s: String;
begin
  str(w, s);

在XE7中生成此警告:

[dcc32 Warning] Unit1.pas(76): W1057 Implicit string cast from 'ShortString' to 'string'

汤姆

我编写了一个接受类类型(T)和接口类型(I)的函数,并将一个接口(I)返回给对象(T).这是代码.

interface

function CreateObjectInterface<T: Class, constructor; I: IInterface>(
  out AObject: TObject): I;

...

implementation

function TORM.CreateObjectInterface<T, I>(out AObject: TObject): I;
begin
  AObject := T.Create;

  if not Supports(AObject, GetTypeData(TypeInfo(I))^.Guid, Result) then
  begin
    AObject.Free;
    AObject := nil;

    raise EORMUnsupportedInterface.CreateFmt(
      'Object class "%s" does not support interface "%s"',
      [AObject.ClassName, GUIDToString(GetTypeData(TypeInfo(I))^.GUID)]
    );
  end;
end;

该功能按预期工作,没有内存泄漏或其他不受欢迎的问题.

还有其他方法可以达到相同的效果吗？

我有这段代码:

INTERFACE

{$WARN SYMBOL_PLATFORM OFF}
USES
   Winapi.Windows, etc, {$IFDEF MSWINDOWS}Vcl.FileCtrl, {$ENDIF} System.IniFiles;
{$WARN SYMBOL_PLATFORM ON}

编译器显示:

[dcc32警告] W1005单元'Vcl.FileCtrl'特定于平台

即使{$ WARN SYMBOL_PLATFORM OFF}在那里.
为什么？