tk_messageBox’s Misbehavior
ho...@mm.st
In Windows, at least, tk_messageBox does not seem to behave as it
ought to.
When a normal Windows program presents you with a message box
requiring a response, you can, while the message box is active, switch
to another program unfettered, and then come back later to the first
program and deal with the message box just as you left it.
On the other hand, when I run any Tcl/Tk program I have written that
throws up a tk_messageBox, I can switch to another program, but the
message box remains on top of the other program’s windows. While the
program I have switched to does have the focus, the Tk message box
remains, covering up part of the other program and requiring me to go
back to my Tcl/Tk program to close it down so I can use the other
program properly.
I don’t consider this normal or polite behavior for a message box.
Does someone know how I can keep this from happening?
Thanks,
Jim
Roy Terry
Looks like a defect to me too. I note that in the tcl/tk install dir
you will find
lib/tk8.4/mesgbox.tcl
which includes tk:MessageBox,
a Tcl only version of the message box and it does not
exhibit the annoying behavior. However, you lost the
Windows platform native look.
Alexandre Ferrieux
You are perfectly right !
Looking at the code, the culprit is the MB_SYSTEMMODAL flag used at
line 2183 of tkWinDialog.c
I really don't know why it is not MB_APPLMODAL, but since that code is
9 years old, I'm a bit shy to change it so quickly. In any case, I've
just tested, making the change does solve the problem. Please open a
bug on SF,
and attach the patch below.
-Alex
Index: tkWinDialog.c
===================================================================
RCS file: /cvsroot/tktoolkit/tk/win/tkWinDialog.c,v
retrieving revision 1.59
diff -r1.59 tkWinDialog.c
2183c2183
< flags |= icon | type | MB_SYSTEMMODAL;
---
> flags |= icon | type | MB_APPLMODAL;
Óscar Fuentes
>> In Windows, at least, tk_messageBox does not seem to behave as it
>> ought to.
>>
>> When a normal Windows program presents you with a message box
>> requiring a response, you can, while the message box is active, switch
>> to another program unfettered, and then come back later to the first
>> program and deal with the message box just as you left it.
>>
>> On the other hand, when I run any Tcl/Tk program I have written that
>> throws up a tk_messageBox, I can switch to another program, but the
>> message box remains on top of the other program’s windows. While the
>> program I have switched to does have the focus, the Tk message box
>> remains, covering up part of the other program and requiring me to go
>> back to my Tcl/Tk program to close it down so I can use the other
>> program properly.
>>
>> I don’t consider this normal or polite behavior for a message box.
>> Does someone know how I can keep this from happening?
>
> You are perfectly right !
> Looking at the code, the culprit is the MB_SYSTEMMODAL flag used at
> line 2183 of tkWinDialog.c
> I really don't know why it is not MB_APPLMODAL, but since that code is
> 9 years old, I'm a bit shy to change it so quickly. In any case, I've
> just tested, making the change does solve the problem. Please open a
> bug on SF,
> and attach the patch below.
Maybe is caused by this:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/df0f458d4a4c0265
See the first and last message on that thread.
I submitted a bug+patch (sf bug #1847002) about the general problem
mentioned above (AFAIK the issue with tk_messageBox is a workaround for
that) but it was ignored.
--
Oscar
Alexandre Ferrieux
No, what we are talking about today is a standalone native call
(MessageBox) used exclusively in the C, Win-specific implementation of
tk_messageBox. I'm not saying that similar issues in generic Tk should
not be chased though :-)
-Alex
Óscar Fuentes
>> > You are perfectly right !
>> > Looking at the code, the culprit is the MB_SYSTEMMODAL flag used at
>> > line 2183 of tkWinDialog.c
>> > I really don't know why it is not MB_APPLMODAL, but since that code is
>> > 9 years old, I'm a bit shy to change it so quickly. In any case, I've
>> > just tested, making the change does solve the problem. Please open a
>> > bug on SF,
>> > and attach the patch below.
>>
>> Maybe is caused by this:
>>
>> http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/df0...
>
> No, what we are talking about today is a standalone native call
> (MessageBox) used exclusively in the C, Win-specific implementation of
> tk_messageBox. I'm not saying that similar issues in generic Tk should
> not be chased though :-)
What I'm trying to say is that tk_messageBox uses MB_SYSTEMMODAL because
if it were using MB_APPLMODAL the message box could be hidden by other
tk toplevels.
--
Oscar
Alexandre Ferrieux
Not in my trials. Can you give an example showing that ?
-Alex
Óscar Fuentes
>> What I'm trying to say is that tk_messageBox uses MB_SYSTEMMODAL because
>> if it were using MB_APPLMODAL the message box could be hidden by other
>> tk toplevels.
>
> Not in my trials. Can you give an example showing that ?
It is all explained on the bug report mentioned on my first message. (sf
#1847002)
I assume that MessageBox with MB_APPLMODAL will create a "toplevel"
equivalent to
toplevel .t ; grab .t
and hence will be affected by the misbehaviour described on the bug
report.
If this assumption is wrong, I'm all for the patch you proposed. This
would fix a long lasting bug on my app.
--
Oscar
Alexandre Ferrieux
> Alexandre Ferrieux <alexandre.ferri...@gmail.com> writes:
> >> What I'm trying to say is that tk_messageBox uses MB_SYSTEMMODAL because
> >> if it were using MB_APPLMODAL the message box could be hidden by other
> >> tk toplevels.
>
> > Not in my trials. Can you give an example showing that ?
>
> It is all explained on the bug report mentioned on my first message. (sf
> #1847002)
Sorry but this thread is all but focused ;-)
Please write the minimalist few lines of Tcl to check against my
modified tk_messageBox.
(A simple grab has no problems.)
-Alex
ho...@mm.st
The Microsoft documentation says:
-----------------
To indicate the modality of the dialog [message] box, specify one of
the following values.
MB_APPLMODAL
The user must respond to the message box before continuing
work
in the window identified by the hWnd parameter. However, the
user
can move to the windows of other threads and work in those
windows.
Depending on the hierarchy of windows in the application, the
user
may be able to move to other windows within the thread. All
child
windows of the parent of the message box are automatically
disabled,
but pop-up windows are not.
MB_APPLMODAL is the default if neither MB_SYSTEMMODAL nor
MB_TASKMODAL
is specified.
MB_SYSTEMMODAL
Same as MB_APPLMODAL except that the message box has the
WS_EX_TOPMOST
style. Use system-modal message boxes to notify the user of
serious,
potentially damaging errors that require immediate attention
(for example,
running out of memory). This flag has no effect on the user's
ability to
interact with windows other than those associated with hWnd.
-----------------
It would seem to me, based on MS's documentation, that even if
MB_APPLMODAL does not solve the probem, MB_SYSTEMODAL is definitely
the wrong modality option for the message box.
Thanks,
Jim
Óscar Fuentes
For checking your modified tk_messageBox I'll need to build tcl&tk and
this is too much work for a Saturday night :-)
Let's see if they accept your patch and then I'll check the alpha/beta
whatever that includes it.
OTOH, some people think that a message box should stare at the face of
the user, no matter what he is doing. For those people, using
MB_APPLMODAL is the right thing. Maybe the original writer of
tk_messageBox implementation is one of those.
--
Oscar
Alexandre Ferrieux
> Alexandre Ferrieux <alexandre.ferri...@gmail.com> writes:
> >
> > Please write the minimalist few lines of Tcl to check against my
> > modified tk_messageBox.
> > (A simple grab has no problems.)
>
> For checking your modified tk_messageBox I'll need to build tcl&tk and
> this is too much work for a Saturday night :-)
>
> Let's see if they accept your patch and then I'll check the alpha/beta
> whatever that includes it.
Very strange. It seems wiser for you to send me a few lines of Tcl
than for me to commit before testing... Or maybe the critical setup is
hard to put into place ?
In that case, MB_SYSTEMMODAL would be crippling all apps just for the
sake of one contorted combination of grabs ?
> OTOH, some people think that a message box should stare at the face of
> the user, no matter what he is doing. For those people, using
> MB_APPLMODAL is the right thing. Maybe the original writer of
> tk_messageBox implementation is one of those.
You mean MB_SYSTEMMODAL I guess.
Within an app, yes. But system-wide-modal is only meaningful for
system-wide criticality like "your battery is running out". Not the
dominant use of Tk.
Moreover, the system-modal behavior right now is not even consistent:
the window stays on top regardless, but you can still interact with
the desktop etc. Just with a stupid hole right in the middle.
Nonsense.
-Alex
Alexandre Ferrieux
consisting of using MB_TASKMODAL | MB_SETFOREGROUND.
See the detailed discussion in
https://sourceforge.net/tracker/index.php?func=detail&aid=2484771&group_id=12997&atid=112997
-Alex