Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

menu from systray won't go away

65 views
Skip to first unread message

davidn...@gmail.com

unread,
Sep 21, 2005, 8:35:12 AM9/21/05
to
[CC'ed replies appreciated - thanks!]

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

Helmut Giese

unread,
Sep 21, 2005, 9:07:18 AM9/21/05
to
On 21 Sep 2005 05:35:12 -0700, "davidn...@gmail.com"
<davidn...@gmail.com> wrote:

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

davidn...@gmail.com

unread,
Sep 21, 2005, 9:27:01 AM9/21/05
to
Ok, thanks! This definitely helps.

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...

Wojciech Kocjan

unread,
Sep 21, 2005, 9:46:52 AM9/21/05
to

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/

Wojciech Kocjan

unread,
Sep 21, 2005, 9:59:21 AM9/21/05
to
On Wed, 21 Sep 2005 15:27:01 +0200, davidn...@gmail.com
<davidn...@gmail.com> wrote:

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

davidn...@gmail.com

unread,
Sep 21, 2005, 10:22:59 AM9/21/05
to
Ok, I did some experimenting of my own. The code you posted doesn't
work for me (using menu instead of a toplevel). I tried a number of
different things in the WM_RBUTTONUP case. focus -force looks like it
ought to call the right bits of the windows API, but it doesn't change
anything here by itself. I finally *seem* to have something that works
by doing the following:

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?

davidn...@gmail.com

unread,
Sep 21, 2005, 10:28:41 AM9/21/05
to
I spoke just a moment too soon... looks like this works even better:

wm overrideredirect .info 1
wm geometry .info 0x0-1000-1000
focus -force .info
raise .info

update
.info post $x $y

Wojciech Kocjan

unread,
Sep 21, 2005, 10:35:35 AM9/21/05
to
davidn...@gmail.com napisał(a):

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

David N. Welton

unread,
Sep 23, 2005, 4:35:51 AM9/23/05
to

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/

Jeff Hobbs

unread,
Sep 25, 2005, 1:00:10 PM9/25/05
to David N. Welton
David N. Welton wrote:
> Wojciech Kocjan wrote:
>>davidn...@gmail.com napisał(a):
>>>I spoke just a moment too soon... looks like this works even better:
>>>
>>> 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?
>
>
> 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

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

David N. Welton

unread,
Sep 25, 2005, 5:17:39 PM9/25/05
to
Jeff Hobbs wrote:

>> 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:-)

Jeff Hobbs

unread,
Sep 26, 2005, 1:32:27 AM9/26/05
to David N. Welton
David N. Welton wrote:
> Jeff Hobbs wrote:
>
>
>>>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.

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.

Donal K. Fellows

unread,
Sep 26, 2005, 11:46:31 AM9/26/05
to
Jeff Hobbs wrote:
> 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.

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.

Pat Thoyts

unread,
Sep 27, 2005, 6:17:56 PM9/27/05
to

OK.

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

David N. Welton

unread,
Sep 28, 2005, 7:44:15 AM9/28/05
to
Pat Thoyts wrote:
> OK.
>
> Winico 0.6 released
>
> CHANGES

> 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!

Steve Landers

unread,
Sep 28, 2005, 8:38:06 AM9/28/05
to
David N. Welton wrote:
> Pat Thoyts wrote:
>
>>OK.
>>
>>Winico 0.6 released
>>
>>CHANGES
>
>
>> 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

0 new messages