Hi,
I'm using the winico extension to create an app that normally is
"withdraw"n, and just sits in the windows systray. Like other normal
systray applications, if you right click on it, a little menu comes up.
So far, so good. The problem is when you click somewhere outside the
menu. That should normally make it go away, but it doesn't. Any ideas
on how to go about accomplishing this? Is it a bug?
Thanks,
Dave
Which OS?
I remember having read sometime that special code (at the C level of
course) was necessary to work around a bug in the OS. Apparently
winico does not do this.
... searching hard disk ...
Ok, here goes: The relevant part of the article has this to say:
---
// The LPARAM of the message identifies the type of mouse message.
// When they right click, show the popup menu. When they double
// click with the left mouse, show the form.
switch(Msg.LParam)
{
case WM_RBUTTONUP:
// Find the mouse cursor and popup the popupmenu at that
// location. The SetForegroundWindow and PostMessage calls
// fix an OS bug that prevents the menu from closing when
// the user clicks outside the menu. KB article Q135788
POINT WinPoint;
GetCursorPos(&WinPoint);
SetForegroundWindow(Handle);
PopupMenu1->Popup(WinPoint.x,WinPoint.y);
PostMessage(Handle, WM_NULL, 0,0);
break;
case WM_LBUTTONDBLCLK:
Visible = true;
ShowWindow(Application->Handle, SW_SHOW);
break;
}
---
I can mail you the whole article and source code if you want to.
HTH
Helmut Giese
I looked up the bug number referenced:
http://support.microsoft.com/kb/q135788/
And then I looked up those two functions in the Tk sources. They both
exist, I suppose it's a matter of getting them called in the right
order. I wonder if it's possible from straight Tk...
Perhaps it would help to focus some Tk window after WM_RBUTTONUP? Or after
the popup is opened.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Ok. Not exactly the most elegant way in the world, but...
toplevel .popupdummywindow
wm overrideredirect .popupdummywindow 1
wm geometry .popupdummywindow 0x0-1000-1000
proc winicoCallback {m x y} {
switch -- $m {
WM_LBUTTONUP {
wm deiconify .
}
WM_RBUTTONUP {
focus -force .popupdummywindow
.popupmenu post $x $y
wm overrideredirect .info 1
wm geometry .info 0x0-1000-1000
focus -force .info
raise .info
.info post $x $y
Seems dodgy to me though... If I leave out the geometry bit, the raise
command creates an "evil twin" menu in the upper left corner that
mirrors what I do in the "real" menu, and vice versa. While the crazy
evil twin menu exists, clicking elsewhere gets rid of the normal menu.
But if I exit the evil twin menu, then things go back to working as
they were before. I guess the geometry keeps the evil twin around but
without actually being visible?
wm overrideredirect .info 1
wm geometry .info 0x0-1000-1000
focus -force .info
raise .info
update
.info post $x $y
I'm not sure you can do update inside an event.
Perhaps try after 100 [list .info post $x $y] as the last line. Does
that do the trick?
--
WK
The after works too.
In any case, I opened a bug, because it seems as if things could be made
to "just work", although I'm afraid I don't have ideas on how.
https://sourceforge.net/tracker/index.php?func=detail&aid=1297800&group_id=12997&atid=112997
Thanks,
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
Hmmm, I find it kind of mean to publish this as a Tk bug when it
is obviously mentioned as a bug/issue by Microsoft, and Tk
doesn't even support the winico stuff. At best, I'd say you
should re-register it with winico. Even then, I'd say it is
just another doc point around a known system limitation.
Have you also considered keeping around a fully transparent
1-pixel toplevel for this app?
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
>> In any case, I opened a bug, because it seems as if things could be made
>> to "just work", although I'm afraid I don't have ideas on how.
>>
>> https://sourceforge.net/tracker/index.php?func=detail&aid=1297800&group_id=12997&atid=112997
>>
>
>
> Hmmm, I find it kind of mean to publish this as a Tk bug when it
> is obviously mentioned as a bug/issue by Microsoft, and Tk
> doesn't even support the winico stuff.
No "meanness" meant! If anything I wasn't sure where to post it and I
decided in favor of Tk because the problem is the menu that gets posted.
Sure, it gets posted from a winico icon, but it's still a regular old Tk
menu. I just wanted to save it somewhere, so I went with Tk. I will
change it to winico if that's the best place for it.
> At best, I'd say you
> should re-register it with winico. Even then, I'd say it is
> just another doc point around a known system limitation.
> Have you also considered keeping around a fully transparent
> 1-pixel toplevel for this app?
With the understanding that I'm not very knowledgeable about Windows
programming, my initial reaction to hacky workarounds or just
documenting the problem is... "isn't it possible that Tk or winico can
just 'do the right thing'?". Perhaps I'm kind of spoiled but often
enough, Tcl and Tk do "do the right thing", so I'm used to it:-)
I didn't intend it in any negative way ... I'm always sensitive
to what goes into the Tk bug db since half the bugs seem to
auto-assign to me. ;) I think winico is the right place for
this.
>>Have you also considered keeping around a fully transparent
>>1-pixel toplevel for this app?
>
> With the understanding that I'm not very knowledgeable about Windows
> programming, my initial reaction to hacky workarounds or just
> documenting the problem is... "isn't it possible that Tk or winico can
> just 'do the right thing'?". Perhaps I'm kind of spoiled but often
> enough, Tcl and Tk do "do the right thing", so I'm used to it:-)
Sure, I'm just not certain what "the right thing" is here. The
MS docs sort of indicate you should have some window with focus.
OK, Tk provides all the right stuff, you just have to program it
in. For example, someone on another list was commenting that Tk
seemed unpolished because the text widgets don't all have one of
those Cut/Copy/Paste edit context menus by default. I've always
argued that this is one of those things you just have to add.
I'm not sure that it isn't different for winico ... but then
again, maybe not.
Given the things I've done with the text widget in the past, I'm very
glad it doesn't have those menus by default. :-)
Donal.
Winico 0.6 released
CHANGES
Tray tooltip text may now be displayed using unicode glyphs where
Windows supports this (Windows XP is known to work, Windows 98 will
display '?' glyphs).
A Tk popup menu raised from a winico taskbar callback event would not
pop down if another application was clicked. This has been fixed.
If Windows Explorer is restarted for some reason winico will now
notice the restart and re-add any taskbar icons.
Added a new demo program to hopefully make the usage clearer.
In particular with the popup menu handling it avoids loosing focus in
case you are focused on another toplevel in your app.
Get it from http://sourceforge.net/projects/tktable
--
Pat Thoyts http://www.patthoyts.tk/
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
> A Tk popup menu raised from a winico taskbar callback event would not
> pop down if another application was clicked. This has been fixed.
I'm running it now, and so far so good.
Thankyou very much for the fast turnaround!
Yes - works for me too.
Thanks Pat!
Steve