我确信这曾经适合我,我已经在网上看到了它(Jolyon Smith和David Moorhouse).刚刚在D2007和XE2试用版中的一个简单程序中尝试过它,它不会保留修改后的消息.一旦"加注"发生,该消息将恢复为原始异常.
我错过了什么盲目明显的事情？另一种方法是"引发Exception.Create(...)",但我想只是在链上传播原始异常,只是在每个异常块上标记了附加信息.
var a: Integer;
begin
try
a := 0;
Label1.Caption := IntToStr(100 div a);
except
on e: Exception do
begin
e.Message := 'Extra Info Plus the original : ' + e.Message;
raise;
end;
end;
end;
在32位与64位下编译时,TPair的默认排序似乎存在差异.在32位下,默认排序的行为就像它在对的Key上排序一样,在64位下,它看起来按值排序.这是预期的,还是我错过了什么？
使用Delphi XE2测试,更新4.在VCL应用程序中,将按钮,复选框和列表框拖放到屏幕上,声明以下类型
type TPairComparer = TComparer<TPair<integer,integer>>;
然后将下面的代码放在OnClick按钮上并运行.在32位下,使用默认排序,按键列出对,即1,2,3,4,5,6.在64位下,这些对按值列出,即2,5,6,7,8,9,而不是按键.
为了使代码在两个平台上一致地工作,我需要指定我自己的比较器来强制在64位可执行文件上按键排序.
procedure TForm1.Button1Click(Sender: TObject);
var PriorityList : TList<TPair<Integer,integer>>;
Pair : TPair<integer,integer>;
PairComparer : IComparer<TPair<integer,integer>>;
iLoop : integer;
begin
PriorityList := TList<TPair<Integer,integer>>.Create;
PairComparer := TPairComparer.Construct(
function(const Left, Right: TPair<integer,integer>): Integer
begin
case Left.Key = Right.Key of
true : Result := 0;
else case Left.Key < Right.Key of
true : Result := -1;
else Result := +1;
end;
end;
end);
Pair.Key := 6;
Pair.Value := 6;
PriorityList.Add(Pair);
Pair.Key := 5;
Pair.Value := 5;
PriorityList.Add(Pair); …经过更多我想进行的调查之后，我得出了一个结论（也许是错误的），BRCC32在创建包含具有不同色深的ICO图像的资源文件时遇到了问题。
具体来说，如果ICO文件中的图标同时具有8位256色和24位XP（alpha）图像，则BRCC32将生成一个包含这些图像的RES文件，但是8位和24位图像都将被标记作为24位。然后的问题是，希望显示24位图像的系统（即能够显示超过256种颜色的系统）将选择符合该要求的第一张图像。至少就我而言，这恰好是“伪” 24位256色图标。因此，您在桌面上获得的分辨率图标比应使用的分辨率低。
使用HeavenTools的“资源调谐器”，可以清楚地看到“组图标”信息包含8位图像的24位描述符。
我有两种前进的方式。删除256色ico图像，这将在结果RES文件中仅生成“正确的” 24位XP Alpha图像。缺点是您没有256个彩色图标。更好的方法是使用http://www.godevtool.com/#rc中的GoRC.exe（资源编译器）替代BRCC32。这样可以正确处理8位和24位图像的组合。结果是窗口可以选择适合系统显示分辨率的正确图标。
作为附带问题，我还看到BRCC32似乎无法处理PNG压缩图像（出现错误15 分配失败）。我在GoRC中遇到了这个错误（通过Jan Wichers博客）。
有没有人有类似的经历可以证实我的发现，还是我缺少一些关键知识？我的追随者是，这仍然是D2009 / D2010中的问题吗？
保罗
这个很长一段时间一直让我烦恼,并且几个月前我已经直接从D2007切换到XE2我不能保证这可能已经开始了,但是在D2007我没有这个问题.
单位越大,在进行代码更改时使用F12在单位和表格之间切换的速度就越慢.即使您取消对表单设计器(返回D7格式),只需在代码更改时单击返回表单,会导致BDS.exe长时间在CPU上最大化.在我的情况下,在我最大的表格(30,000行)上,这可能超过一分钟.我不确定重新激活表单时正在进行哪些检查,但是如果IDE已被"告知"所有内容都是uptodate,则交换机是即时的.因此,我的解决方法是在重新激活表单之前按Ctrl + F9编译表单.编译所花费的时间只有几秒钟.然后,我可以立即切换到表单,没有问题.如果我在切换之前没有编译,那么比较那一分钟或更长的等待我忍受...
那么,除了减小单位尺寸外,还有什么可能性？!