显示带有超时值的消息框
问题来自这样的代码。
Set scriptshell = CreateObject("wscript.shell")
Const TIMEOUT_IN_SECS = 60
Select Case scriptshell.popup("Yes or No? leaving this window for 1 min is the same as clicking Yes.", TIMEOUT_IN_SECS, "popup window", vbYesNo + vbQuestion)
Case vbYes
Call MethodFoo
Case -1
Call MethodFoo
End Select
这是从 VBA(或 VB6)显示带有超时消息框的简单方法。
在 Excel 2007 中(显然有时也会发生在 Internet Explorer 中),弹出窗口不会超时,而是等待用户输入。
这个问题很难调试,因为它只是偶尔发生,而且我不知道重现该问题的步骤。我认为这是 Office 模式对话框和 Excel 无法识别超时已过期的问题。
请参阅 http://social .technet.microsoft.com/Forums/en-US/ITCG/thread/251143a6-e4ea-4359-b821-34877ddf91fb/
我发现的解决方法是:
A. 使用 Win32 API 调用
Declare Function MessageBoxTimeout Lib "user32.dll" Alias "MessageBoxTimeoutA" ( _
ByVal hwnd As Long, _
ByVal lpText As String, _
ByVal lpCaption As String, _
ByVal uType As Long, _
ByVal wLanguageID As Long, _
ByVal lngMilliseconds As Long) As Long
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" ( _
ByVal lpClassName As String, _
ByVal lpWindowName As String) As Long
Public Sub MsgBoxDelay()
Const cmsg As String = "Yes or No? leaving this window for 1 min is the same as clicking Yes."
Const cTitle As String = "popup window"
Dim retval As Long
retval = MessageBoxTimeout(FindWindow(vbNullString, Title), cmsg, cTitle, 4, 0, 60000)
If retval <> 7 Then
Call MethodFoo
End If
End Sub
B. 使用手动计时器使用设计得像消息框的 VBA 用户窗体。使用全局变量或类似变量来保存需要传递回调用代码的任何状态。确保使用提供的 vbModeless 参数调用用户窗体的 Show 方法。
C.将对 wscript.popup 方法的调用包装在 MSHTA 进程中,这将允许代码在进程外运行并避免 Office 的模式特性。
CreateObject("WScript.Shell").Run "mshta.exe vbscript:close(CreateObject(""WScript.Shell"").Popup(""Test"",2,""Real%20Time%20Status%20Message""))"
A、B 或 C 或您自己的答案在 VBA 中显示带有超时值的消息框的最佳方法是什么?
The question comes from code like this.
Set scriptshell = CreateObject("wscript.shell")
Const TIMEOUT_IN_SECS = 60
Select Case scriptshell.popup("Yes or No? leaving this window for 1 min is the same as clicking Yes.", TIMEOUT_IN_SECS, "popup window", vbYesNo + vbQuestion)
Case vbYes
Call MethodFoo
Case -1
Call MethodFoo
End Select
This is a simple way to display a message box with a timeout from VBA (or VB6).
In Excel 2007 (apparently also happens in Internet Explorer at times) the popup window will not timeout, and instead wait for user input.
This issue is tough to debug as it only happens occasionally and I do not know the steps to reproduce the issue. I believe it to be an issue with Office modal dialogs and Excel not recognising the timeout has expired.
See http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/251143a6-e4ea-4359-b821-34877ddf91fb/
The workarounds I found are:
A. Use a Win32 API call
Declare Function MessageBoxTimeout Lib "user32.dll" Alias "MessageBoxTimeoutA" ( _
ByVal hwnd As Long, _
ByVal lpText As String, _
ByVal lpCaption As String, _
ByVal uType As Long, _
ByVal wLanguageID As Long, _
ByVal lngMilliseconds As Long) As Long
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" ( _
ByVal lpClassName As String, _
ByVal lpWindowName As String) As Long
Public Sub MsgBoxDelay()
Const cmsg As String = "Yes or No? leaving this window for 1 min is the same as clicking Yes."
Const cTitle As String = "popup window"
Dim retval As Long
retval = MessageBoxTimeout(FindWindow(vbNullString, Title), cmsg, cTitle, 4, 0, 60000)
If retval <> 7 Then
Call MethodFoo
End If
End Sub
B. Use a manual timer with a VBA userform that is designed to look like a messagebox. Use a global variable or similar to save any state that needs to be passed back to the calling code. Ensure that the Show method of the userform is called with the vbModeless parameter supplied.
C. Wrap the call to wscript.popup method in the MSHTA process which would allow the code to run out of process and avoid the modal nature of Office.
CreateObject("WScript.Shell").Run "mshta.exe vbscript:close(CreateObject(""WScript.Shell"").Popup(""Test"",2,""Real%20Time%20Status%20Message""))"
What is the best way of A, B or C or your own answer to display a message box with a timeout value in VBA?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
这是一个很长的答案,但有很多基础内容需要涵盖:这也是一个迟到的答复,但自从对此(以及类似问题)的一些答复已发布在堆栈上以来,事情已经发生了变化。这就像三相交流电上的吸尘器一样糟糕,因为它们在发布时是很好的答案,并且经过了很多思考。
简短的版本是:我注意到 Script WsShell Popup 解决方案一年前在 VBA 中不再为我工作,我为 VBA MsgBox 函数编写了一个有效的 API 计时器回调。
直接跳到下面的代码如果您急需答案,标题调用超时消息框的 VBA 代码 - 我确实这样做了,我确实有数千个自动解除“MsgPopup”替代 VBA 的实例。 MsgBox 进行编辑,下面的代码适合一个独立的模块。
然而,这里的 VBA 编码员(包括我自己)需要一些解释来解释为什么完美的代码似乎不再有效。如果您了解原因,您也许可以使用隐藏在文本中的“取消”对话框的部分解决方法。
我注意到 Script WsShell Popup 解决方案一年前在 VBA 中停止为我工作 - “SecondsToWait”超时被忽略,对话框就像熟悉的 VBA.MsgBox 一样挂在周围:
我想我知道原因:你无法再从打开对话窗口的线程以外的任何地方向对话窗口发送 WM_CLOSE 或 WM_QUIT 消息。同样,User32 DestroyWindow() 函数不会关闭对话框窗口,除非它被打开对话框的线程调用。
雷德蒙德的某人不喜欢在后台运行脚本并向所有那些停止工作的基本警告发送 WM_CLOSE 命令的想法(如今,让它们永久消失需要本地管理员权限)。
我无法想象谁会写这样的脚本,这是一个糟糕的主意!
该决定会产生后果和附带损害:单线程 VBA 环境中的 WsScript.Popup() 对象使用 Timer 回调实现其“SecondsToWait”超时,并且该回调发送 WM_CLOSE 消息或类似消息...在大多数情况下会被忽略,因为它是回调线程,而不是对话框的所有者线程。
您可能让它在带有“取消”按钮的弹出窗口上运行,一两分钟后就会明白为什么会这样。
我尝试过向弹出窗口编写 WM_CLOSE 定时器回调,但在大多数情况下,这对我来说也失败了。
我尝试过一些奇特的 API 回调来扰乱 VBA.MsgBox 和 WsShell.Popup 窗口,现在我可以告诉您,它们不起作用。您无法使用不存在的内容:这些对话框窗口非常简单,其中大多数根本不包含任何功能,除了按钮单击中的响应 - 是、否、确定、取消、中止、重试、忽略和帮助。
“取消”是一个有趣的功能:当您指定
vbOKCancel
或vbRetryCancel
或vbYesNoCancel 时,您似乎可以从内置对话框的原始 Windows API 中获得免费赠品
- “取消”功能是通过对话框菜单栏中的“关闭”按钮自动实现的(您无法使用其他按钮实现该功能,但可以使用包含“忽略”的对话框随意尝试) ,这意味着......如果 WsShell.Popup() 对话框有“取消”选项,它们有时会响应 SecondsToWait 超时。
如果您想要的只是让 WsShell.Popup() 函数再次响应 SecondsToWait 参数,那么对于阅读本文的人来说,这可能是一个足够好的解决方法。
这也意味着您可以使用回调上的 SendMessage() API 调用将 WM_CLOSE 消息发送到“取消”对话框:
严格来说,这应该仅适用于
WM_SYSCOMMAND, SC_CLOSE
消息 - “关闭”命令栏中的框是一个“系统”菜单,其中包含一类特殊的命令,但正如我所说,我们可以从 Windows API 获得免费赠品。我开始工作,然后我开始思考:如果我只能使用现有的东西,也许我最好找出实际存在的东西...
答案很明显:Dialog框有自己的一组 WM_COMMAND 消息参数 -
并且,由于这些是将用户响应返回给对话框的调用者(即调用线程)的“用户”消息,因此对话框很乐意接受它们并自行关闭。
您可以询问对话框窗口以查看它是否实现了特定命令,如果实现了,您可以发送该命令:
剩下的挑战是检测“超时”并拦截返回的消息框响应,并替换我们自己的值:如果我们遵循
WsShell.Popup()
函数建立的约定,则为 -1。因此,我们的带有超时消息框的“msgPopup”包装器需要执行三件事:...或者将用户响应返回到对话框,如果他们响应
在
其他地方,我们需要声明所有这些的 API 调用,并且我们绝对必须有一个公开声明的“TimerProc”函数供 Timer API 调用。该函数必须存在,并且它必须运行到“结束函数”,没有错误或断点 - 任何中断,并且 API Timer() 将平息操作系统的愤怒。
调用带有超时消息框的 VBA 代码:
以下是 API 声明 - 请注意 VBA7、64 位 Windows 和普通 32 位的条件声明:
最后一点:我欢迎经验丰富的 MFC C++ 开发人员提出改进建议,因为您将拥有更好地掌握“对话框”窗口底层的基本 Windows 消息传递概念 - 我使用一种过于简单化的语言工作,并且我的理解中的过度简化很可能已经超出了我的解释中的彻底错误。
This is a long answer, but there's a lot of ground to cover: it's also a late reply, but things have changed since some of the replies to this (and similar questions) have been posted on the stack. That sucks like a vacuum cleaner on triple-phase AC, because they were good answers when they were posted and a lot of thought went into them.
The short version is: I noticed that the Script WsShell Popup solution stopped working for me in VBA a year ago, and I coded a working API timer callback for the VBA MsgBox function.
Skip straight to the code under the heading VBA code to call a Message Box with a Timeout if you need an answer in a hurry - and I did, I have literally thousands of instances of a self-dismissing 'MsgPopup' substitute for VBA.MsgBox to redact, and the code below fits into a self-contained module.
However, the VBA coders here - myself included - need some explanation as to why perfectly good code no longer seems to work. And if you understand the reasons, you may be able to use the partial workaround for 'Cancel' dialogs, buried in the text.
I noticed that the Script WsShell Popup solution stopped working for me in VBA a year ago - The 'SecondsToWait' timeout was being ignored, and the dialog just hung around like the familiar VBA.MsgBox:
And I think I know the reason why: you can no longer send a WM_CLOSE or WM_QUIT message to a dialog window from anywhere other than the thread which opened it. Likewise, the User32 DestroyWindow() function will not close a dialog window unless it's called by the thread that opened the dialog.
Someone in Redmond doesn't like the idea of a script running in the background and sending a WM_CLOSE commands to all those essential warnings that halt your work (and, these days, making them go away permanently needs local admin privileges).
I can't imagine who would write a script like that, it's a terrible idea!
There are consequences and collateral damage to that decision: WsScript.Popup() objects in the single-threaded VBA environment implement their 'SecondsToWait' timeout using a Timer callback, and that callback sends a WM_CLOSE message, or something like it... Which is ignored in most cases, because it's a callback thread, not the owner thread for the dialog.
You might get it to work on a popup with a 'CANCEL' button, and it'll become clear why that is in a minute or two.
I've tried writing a timer callback to WM_CLOSE the popup, and that failed for me, too, in most cases.
I've tried some exotic API callbacks to mess with the VBA.MsgBox and WsShell.Popup window, and I can tell you now that that they didn't work. You can't work with what isn't there: those dialog windows are very simple and most of them don't contain any functionality, at all, except for the responses in the button clicks - Yes, No, OK, Cancel, Abort, Retry, Ignore, and Help.
'Cancel' is an interesting one: it appears that you get a freebie from the primitive Windows API for built-in dialogs when you specify
vbOKCancel
orvbRetryCancel
orvbYesNoCancel
- the 'Cancel' function is automatically implemented with a 'close' button in the dialog's Menu bar (you don't get that with the other buttons, but feel free to try it with a dialog containing 'Ignore'), which means that....WsShell.Popup() dialogs will sometimes respond to the SecondsToWait timeout if they have a 'Cancel' option.
That might be a good enough workaround for someone reading this, if all you wanted was to get WsShell.Popup() functions to respond to the SecondsToWait parameter again.
This also means that you can send WM_CLOSE messages to the 'Cancel' dialog using the SendMessage() API call on a callback:
Strictly speaking, this should only work for the
WM_SYSCOMMAND, SC_CLOSE
message - the 'close' box in the command bar is a 'system' menu with a special class of commands but, like I said, we're getting freebies from the Windows API.I got that to work, and I started thinking: If I can only work with what's there, maybe I'd better find out what's actually there...
And the answer turns out to be obvious: Dialog boxes have their own set of WM_COMMAND message parameters -
And, as these are the 'user' messages which return the user responses to the caller (that is to say, the calling thread) of the dialog, the dialog box is happy to accept them and close itself.
You can interrogate a dialog window to see if it implements a particular command and, if it does, you can send that command:
The remaining challenge is to detect a 'Timeout' and intercept the returning Message Box response, and substitute our own value: -1 if we're following the convention established by the
WsShell.Popup()
function. So our 'msgPopup' wrapper for a Message Box with a timeout needs to do three things:...Or return the user response to the dialog, if they responded in
time
Elsewhere, we need to declare the API calls for all this, and we absolutely must have a Publicly-declared 'TimerProc' function for the Timer API to call. That function has to exist, and it has to run to 'End Function' without errors or breakpoints - any interruption, and the API Timer() will call down the wrath of the operating system.
VBA code to call a Message Box with a Timeout:
And here are the API declarations - note the conditional declarations for VBA7, 64-Bit Windows, and plain-vanilla 32-bit:
A final note: I would welcome suggestions for improvement from experienced MFC C++ developers, as you are going to have a much better grasp of the basic Windows message-passing concepts underlying a 'Dialog' window - I work in an oversimplified language and it is likely that the oversimplifications in my understanding have crossed the line into outright errors in my explanation.
采用答案 A. Win32 解决方案。这满足了要求,并且从迄今为止的测试来看是稳健的。
Going with Answer A. the Win32 solution. This meets the requirements, and is robust from testing so far.
简单的
Easy
从这篇文章中的示例开始,我的最终代码如下:
Starting with the samples in this post my final code is as follows: