作为。自关闭相关问题以来 - 下面添加了更多示例。
下面的简单代码(查找顶级 Ie 窗口并枚举其子窗口)可以在“32 位 Windows”目标平台上正常工作。 Delphi 的早期版本也没有问题:
procedure TForm1.Button1Click(Sender: TObject);
function EnumChildren(hwnd: HWND; lParam: LPARAM): BOOL; stdcall;
const
Server = 'Internet Explorer_Server';
var
ClassName: array[0..24] of Char;
begin
Assert(IsWindow(hwnd)); // <- Assertion fails with 64-bit
GetClassName(hwnd, ClassName, Length(ClassName));
Result := ClassName <> Server;
if not Result then
PUINT_PTR(lParam)^ := hwnd;
end;
var
Wnd, WndChild: HWND;
begin
Wnd := FindWindow('IEFrame', nil); // top level IE
if Wnd <> 0 then begin
WndChild := 0;
EnumChildWindows(Wnd, @EnumChildren, UINT_PTR(@WndChild));
if WndChild <> 0 then
..
end;
我插入了一个 Assert
来指示在“64 位 Windows”目标平台上失败的位置。如果我取消嵌套回调,代码就没有问题。
我不确定参数传递的错误值是否只是垃圾,或者是由于某些错误放置的内存地址(调用约定?)。嵌套回调实际上是我一开始就不应该做的事情吗?或者这只是我必须忍受的一个缺陷?
编辑:
为了回应 David 的回答,使用类型化回调声明了 EnumChildWindows
的相同代码。在 32 位上运行良好:
(编辑:下面的内容并没有真正测试大卫所说的内容,因为我仍然使用了“@”运算符。它与该运算符配合得很好,但如果我删除它,它确实不会编译,除非我取消嵌套回调)
type
TFNEnumChild = function(hwnd: HWND; lParam: LPARAM): Bool; stdcall;
function TypedEnumChildWindows(hWndParent: HWND; lpEnumFunc: TFNEnumChild;
lParam: LPARAM): BOOL; stdcall; external user32 name 'EnumChildWindows';
procedure TForm1.Button1Click(Sender: TObject);
function EnumChildren(hwnd: HWND; lParam: LPARAM): BOOL; stdcall;
const
Server = 'Internet Explorer_Server';
var
ClassName: array[0..24] of Char;
begin
Assert(IsWindow(hwnd)); // <- Assertion fails with 64-bit
GetClassName(hwnd, ClassName, Length(ClassName));
Result := ClassName <> Server;
if not Result then
PUINT_PTR(lParam)^ := hwnd;
end;
var
Wnd, WndChild: HWND;
begin
Wnd := FindWindow('IEFrame', nil); // top level IE
if Wnd <> 0 then begin
WndChild := 0;
TypedEnumChildWindows(Wnd, @EnumChildren, UINT_PTR(@WndChild));
if WndChild <> 0 then
..
end;
<小时/>
实际上,这个限制并不特定于 Windows API 回调,但是当将该函数的地址放入过程类型
的变量并将其传递(例如,作为自定义比较器)时,会发生同样的问题到TList.Sort
。
http://docwiki.embarcadero.com/RADStudio/Rio/en/Procedural_Types
procedure TForm2.btn1Click(Sender: TObject);
var s : TStringList;
function compare(s : TStringList; i1, i2 : integer) : integer;
begin
result := CompareText(s[i1], s[i2]);
end;
begin
s := TStringList.Create;
try
s.add('s1');
s.add('s2');
s.add('s3');
s.CustomSort(@compare);
finally
s.free;
end;
end;
当编译为 32 位时,它可以按预期工作,但当编译为 Win64 时,会因访问冲突
而失败。对于 64 位版本的函数 compare
,s = nil
和 i2
= 某个随机值;
如果在 btn1Click
函数之外提取 compare
函数,即使对于 Win64 目标,它也能按预期工作。
最佳答案
这个技巧从未得到该语言的正式支持,并且由于 32 位编译器的实现细节,迄今为止您一直在逃避它。 documentation很清楚:
Nested procedures and functions (routines declared within other routines) cannot be used as procedural values.
如果我没记错的话,一个额外的隐藏参数将通过指向封闭堆栈帧的指针传递给嵌套函数。如果未引用封闭环境,则在 32 位代码中将省略此内容。在 64 位代码中,总是会传递额外的参数。
当然,问题的一个重要部分是 Windows 单元使用无类型过程类型作为其回调参数。如果使用类型化过程,编译器可能会拒绝您的代码。事实上,我认为这是有理由相信你使用的伎俩从来都不合法。对于类型化回调,即使在 32 位编译器中,也永远无法使用嵌套过程。
无论如何,底线是您不能将嵌套函数作为参数传递给 64 位编译器中的另一个函数。
关于delphi - 为什么不能在 64 位 Delphi 中获取嵌套局部函数的地址?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10162749/