在应用程序关闭期间停止WNDPROC处理
我已经定义了wndproc
,该看起来与下面相似(代码以C ++构建器编写,但也适用于Delphi的形式):
#define WM_SETTINGS_UPDATE WM_APP + 1234
#define WM_GUI_UPDATE WM_APP + 1235
void __fastcall TForm1::WndProc(TMessage &fMessage)
{
switch (fMessage.Msg)
{
default: break;
case WM_SETTINGS_UPDATE: ProcessMySettingsUpdate();
fMessage.Result = 1;
return;
break; // I know this is not needed, I do this purely for aesthetics
case WM_GUI_UPDATE: ProcessMyGUIUpdate();
fMessage.Result = 1;
return;
break; // I know this is not needed, I do this purely for aesthetics
}
TForm::WndProc(fMessage);
}
因此,本质上是:
检查检查在这种情况下
处理这些消息,然后设置
fmessage.result
1 已处理了指示消息并返回(避免tform:wndproc(fmessage),
,我理解的是在Delphi中继承
,如果已处理消息,则不需要)。如果未处理我的消息,它只会调用
tform:wndproc(fmessage)
(或encol> encarioned
)进行默认处理。
我担心的是 - 如果在某种情况下,应用程序正在关闭,并且仍然有一些消息未加工(在消息队列中由postmessage()
)呢?
在这种情况下,我想做的是避免打电话给我自己的处理,因为这可能导致某些非专业化的内存访问或类似。这基本上是足够的,还是我需要应用一些特殊的处理以避免这种情况,或者处理一些“申请关闭”代码?
而且 - 我是否需要调用继承
/tform:wndproc(fmessage)
我完成处理后,还是可以安全地执行此操作(set set <代码>结果至1并返回)?
注意 - 这不一定适用于mainform
(创建的第一个表单)。
I have defined a WndProc
which looks similar to below (the code is written in C++Builder, but it applies in similar form to Delphi as well):
#define WM_SETTINGS_UPDATE WM_APP + 1234
#define WM_GUI_UPDATE WM_APP + 1235
void __fastcall TForm1::WndProc(TMessage &fMessage)
{
switch (fMessage.Msg)
{
default: break;
case WM_SETTINGS_UPDATE: ProcessMySettingsUpdate();
fMessage.Result = 1;
return;
break; // I know this is not needed, I do this purely for aesthetics
case WM_GUI_UPDATE: ProcessMyGUIUpdate();
fMessage.Result = 1;
return;
break; // I know this is not needed, I do this purely for aesthetics
}
TForm::WndProc(fMessage);
}
So in essence this:
checks for my custom
WM_APP
range messages (WM_SETTINGS_UPDATE
andWM_GUI_UPDATE
) in this case.processes those messages and then sets
fMessage.Result
to1
indicating message was processed and returns (avoidingTForm:WndProc(fMessage)
, which I understand is the same asinherited
in Delphi, and not needed if the message is processed).if my messages are not processed, it just calls
TForm:WndProc(fMessage)
(orinherited
) to do the default processing.
My concern is this - what if there is a situation where the application is shutting down, and there are still some messages being unprocessed (left in the message queue by PostMessage()
)?
What I'd like to do in such a situation is to avoid calling my own processing, as it might result in some uninitialized memory Access Violations or similar. Is this basically enough, or do I need to apply some special processing to avoid that kind of situation, or process some "application shutting down" code?
And also - do I need to call inherited
/ TForm:WndProc(fMessage)
after I am done with my processing, or is it safe to do it like above (set Result
to 1 and return)?
Note - this does not necessarily apply to the MainForm
(the first Form being created).
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
没关系。一旦表单的
hwnd
被销毁,当主邮件循环派遣时,该窗口发布的任何剩余消息都将简单地丢弃。您的wndproc
将不会为他们呼唤。这不应该担心。第一,因为被销毁后不会将消息派发到您的表单
hwnd
,而两个,当关闭Mainform
时,主邮件循环发出信号以停止运行,在任何活动形式hwnd
s被销毁之前。因此,无论如何都不会有任何进一步的消息。就足够了。通常,您不需要处理这个特殊的东西(除非您的自定义消息将指针携带到必须释放的对象)。
如果您真的想检测到应用程序何时关闭,请尝试使用
wndproc
处理wm_close
消息(或者您可以使用表单的onclose/query < /代码>事件)。
自定义消息完全可以。
That is perfectly OK. Once a Form's
HWND
is destroyed, any remaining messages that were posted for that window will simply be discarded when dispatched by the main message loop. YourWndProc
will not be called for them.That should not be a concern. One, because messages won't be dispatched to your Form's
HWND
after it is destroyed, and two, when theMainForm
is closed, the main message loop is signaled to stop running, before any active FormHWND
s are destroyed. So, there won't be any further message dispatching anyway.It should be enough. You typically do not need to handle this special (unless your custom messages are carrying pointers to objects that have to be freed).
If you really want to detect when the app is being shut down, try having your
WndProc
handle theWM_CLOSE
message (or you can use the Form'sOnClose/Query
events).That is perfectly OK for custom messages.