Delphi 2010 中的 ASyncPro 5.00 - 范围检查错误
尝试让 AsyncPro 在 D2010 中运行。使用 Source Forge 的 5.00 版本。
下面的 AsyncPro 代码(在 OOMisc.pas 中)失败,并在下面的 MakeLong 行上出现范围检查错误。我不知道如何开始调试这个。
有没有人在 D2010 中运行 ASyncPro,或者对下面可能发生的情况有一些了解?我在 SourceForge 上发的帖子没有得到任何回应。
function SafeYield : LongInt;
{-Allow other processes a chance to run}
var
Msg : TMsg;
begin
SafeYield := 0;
if PeekMessage(Msg, 0, 0, 0, PM_REMOVE) then begin
if Msg.Message = wm_Quit then
{Re-post quit message so main message loop will terminate}
PostQuitMessage(Msg.WParam)
else begin
TranslateMessage(Msg);
DispatchMessage(Msg);
end;
{Return message so caller can act on message if necessary}
SafeYield := MAKELONG(Msg.Message, Msg.hwnd); // Range Check Error on this line!
end;
end;
TIA
Trying to get AsyncPro running in D2010. Using the 5.00 version from Source Forge.
The AsyncPro code (in OOMisc.pas) below is failing with a range check errror on the MakeLong line below. I don't have a clue how to start debugging this.
Does anyone have ASyncPro running in D2010, or have some insight into what might be going on below? A posting by me on the SourceForge yielded no responses.
function SafeYield : LongInt;
{-Allow other processes a chance to run}
var
Msg : TMsg;
begin
SafeYield := 0;
if PeekMessage(Msg, 0, 0, 0, PM_REMOVE) then begin
if Msg.Message = wm_Quit then
{Re-post quit message so main message loop will terminate}
PostQuitMessage(Msg.WParam)
else begin
TranslateMessage(Msg);
DispatchMessage(Msg);
end;
{Return message so caller can act on message if necessary}
SafeYield := MAKELONG(Msg.Message, Msg.hwnd); // Range Check Error on this line!
end;
end;
TIA
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
看来您在打开范围检查的情况下编译代码:
您可以关闭范围检查以消除运行时错误,但
如果参数之一(或两者)高于 2^16 - 1,则结果不正确。
看起来就像代码是从 16 位 AsyncPro 版本移植到 32 位版本一样,并且所有 32 位 AsyncPro 版本都存在该错误。
It seems that you compile the code with range checking on:
You can switch range checking off to get rid off the runtime error, but the result of
is incorrect if one of the arguments (or both) is above 2^16 - 1.
Looks like the code was ported from 16-bit AsyncPro version without change to 32-bit version and the bug existed where through all 32-bit AsyncPro versions.
鉴于 MAKELONG 如何采用 Word 类型(16 位)的两个参数,并且 Msg.Message 和 Msg.HWnd 都是 32 位,因此出现范围检查错误也就不足为奇了。一般来说,窗口消息< 8000 美元,所以我怀疑价值是问题所在。然而,HWnd的积分值可以遍及整个地图,并且肯定>2。 $FFFF 经常。因此,上面的代码实际上没有任何意义,只是它似乎是很久以前 16 位版本遗留下来的工件。
由于启用了范围检查,它清楚地强调了上述代码需要重新思考的事实。在 Win32 中,您无法再将消息值和窗口句柄放入 32 位中。
我希望我已经给了您一些如何继续的提示。如果不考虑调用此函数的代码,就不可能建议替代实现。
Seeing as how MAKELONG takes two parameters of type Word (16bits), and Msg.Message and Msg.HWnd are both 32bits it is not surprising that you're getting range-check errors. In general, window messages are < $8000 so I doubt that value is the problem. However, the integral value of an HWnd can be all over the map and is certainly > $FFFF quite often. Because of this the above code doesn't really make sense, except that it appears to be a long-ago left over artifact from the 16bit version.
Since range-checking is enabled it is clearly highlighting the fact that the above code needs a bit of a re-think. In Win32, you cannot fit a message value and window handle into 32bits anymore.
I hope I've given you a few hints on how to proceed. Without taking into account the code that calls this function, it is not possible to suggest an alternative implementation.
我同意艾伦的评论——但更进一步。
如果您查看代码的使用方式(也请查看 OoMisc 中的 DelayTicks),调用者要么假设返回值不重要,要么只是消息。将 Msg.hwnd 添加到号码中不仅不起作用,而且也不是呼叫者所期望的。
此代码仅期待一条消息。
我会把这条线
改为
I would echo Allen's comment - but go further.
If you look at how the code is being used (Look at DelayTicks also in OoMisc) callers either assume that the return value is unimportant or is JUST the message. Adding the Msg.hwnd to the number is not just not going to work, it is also not what the callers are expecting.
This code is expecting a message only.
I would change the line
to
(1) 该代码是消息泵,并且
(2)(在上下文中)它受到 R 编译器指令的保护。范围检查已关闭:AwDefine.inc 中的 {$R- 无范围检查}
因此 (1) 如果其他消息导致代码停止,则消息经过时将在此处,并且
(2) 范围检查错误不是来自这里。
这表明异步进程正在导致范围检查异常或模态消息。在我正在使用的 Delphi 版本中,范围检查错误(和列表索引消息)不提供任何源/调试信息,因此我只能建议该错误可能与异步 Comm 事件相关联,甚至与 get-焦点/失去焦点/激活/绘制事件。
(1) That code is a Message Pump, and
(2) (in context) it is protected by a R- compiler directive. Range checking is turned off: {$R- No range checking} in AwDefine.inc
So (1) If some other message causes the code to stop, this is where it will be when the message goes through, and
(2) The range check error does not come from here.
This suggests that an asyncronous process is causing a range check exception or modal message. In the version of Delphi I am working with, range check errors (and list index messages) do not give any source/debug information, so I can only suggest that the error may be linked to an asynchronous Comm event, or even a got-focus/lost-focus/activate/paint event.