Menu mapping trouble... (Exceed's problem?)
David E. Wall
Greetings,
We have a semi reproducible, transient problem with menus
failing to post/map (yet with their cascade entries properly
posting if you select as if the menu were visible).
Specs:
Tcl/Tk8.0 (from the plus-patched full distribution)
Tix4.1.8.0
on AIX 4.1.5 - compiled with gcc
Displayed to a Win95 box with Hummingbird's Exceed (ver. 5.0.1).
Description:
Any menu (main menu items, cascade menu items, and tixOptionMenus)
can, at times, fail to be drawn to the screen. It appears that
the Menu-title is selected (raised-relief appears), but the menu
is not mapped to the screen. If one drags the selection to a
cascade menu entry, the cascade is mapped to the screen, seemingly
out of thin air. For those menus without tell-tale cascade items,
the menu-title-button appears to not work... but "selected" operations
invoke with button release.
This never seems to occur when first selecting a menu. It appears
to occur after dismissing a pop-up top-level (destroyed). It also
will occur to one menu (of 4-5) while the others maps fine, or to
all menus for a given set (all the menus derived from a parent)
while not affecting the tixOptionMenus, or visa versa.
These menus do not re-map if selected time and again, nor do
they reappear if other options are selected and the menus
tried again.
Temporary Solution:
The one consistently menu-saving action is to click-away from
the Tk application then click back to restore focus. Then all
the menus behave as if nothing had happened.
My theory:
Since this application is being displayed to the Win95 screen
through Exceed, and I have not read of such problems from all
the users of comp.lang.tcl, this "must" be a Xwindow mapping
problem in Exceed (not talking Tcl/Tk Xwindow calls properly).
Any ideas?
Ancillary (possibly connected) problem:
If the Windows 95 start/task bar is resized to more than 1 line,
or moved to another location on screen edge (top, left, right)
the menus map only partially. They are transparent for the
amount of the width/height of the newly-placed taskbar. I.e.-
if the task bar is placed at the top of the screen, the first
line of multi-line menus is transparent when mapped, leaving
the widgets below visible, and the menu selectable, but obviously
graphically corrupt. If the task bar is to the left, menus
and tixOptionMenus are only drawn from the left edge shifted
right by the task bar width.
Solution:
Tell the users to leave their task-bar on the bottom of the
screen and only one line wide. *Not* a great solution.
Any ideas? Menu Meister, Syd Polk? Ioi? I am at a loss.
Thank you for any help,
David
David E. Wall -- david....@boeing.com
Nesting & NC Catia Applications
Sydney R. Polk
>Greetings,
>We have a semi reproducible, transient problem with menus
>failing to post/map (yet with their cascade entries properly
>posting if you select as if the menu were visible).
>Specs:
>Tcl/Tk8.0 (from the plus-patched full distribution)
>Tix4.1.8.0
>on AIX 4.1.5 - compiled with gcc
>Displayed to a Win95 box with Hummingbird's Exceed (ver. 5.0.1).
>Description:
>Any menu (main menu items, cascade menu items, and tixOptionMenus)
>can, at times, fail to be drawn to the screen. It appears that
>the Menu-title is selected (raised-relief appears), but the menu
>is not mapped to the screen. If one drags the selection to a
>cascade menu entry, the cascade is mapped to the screen, seemingly
>out of thin air. For those menus without tell-tale cascade items,
>the menu-title-button appears to not work... but "selected" operations
>invoke with button release.
Actually, the menu is coming up underneath the toplevel window. If you
move the toplevel away, you will see it.
>This never seems to occur when first selecting a menu. It appears
>to occur after dismissing a pop-up top-level (destroyed). It also
>will occur to one menu (of 4-5) while the others maps fine, or to
>all menus for a given set (all the menus derived from a parent)
>while not affecting the tixOptionMenus, or visa versa.
>These menus do not re-map if selected time and again, nor do
>they reappear if other options are selected and the menus
>tried again.
>Temporary Solution:
>The one consistently menu-saving action is to click-away from
>the Tk application then click back to restore focus. Then all
>the menus behave as if nothing had happened.
>My theory:
>Since this application is being displayed to the Win95 screen
>through Exceed, and I have not read of such problems from all
>the users of comp.lang.tcl, this "must" be a Xwindow mapping
>problem in Exceed (not talking Tcl/Tk Xwindow calls properly).
>Any ideas?
Indeed. This is only reproduceable with Exceed. It is reproduceable
running Wish from any X Windows machine with Exceed as the X Server.
And it is bloody annoying.
>Ancillary (possibly connected) problem:
>If the Windows 95 start/task bar is resized to more than 1 line,
>or moved to another location on screen edge (top, left, right)
>the menus map only partially. They are transparent for the
>amount of the width/height of the newly-placed taskbar. I.e.-
>if the task bar is placed at the top of the screen, the first
>line of multi-line menus is transparent when mapped, leaving
>the widgets below visible, and the menu selectable, but obviously
>graphically corrupt. If the task bar is to the left, menus
>and tixOptionMenus are only drawn from the left edge shifted
>right by the task bar width.
>Solution:
>Tell the users to leave their task-bar on the bottom of the
>screen and only one line wide. *Not* a great solution.
>Any ideas? Menu Meister, Syd Polk? Ioi? I am at a loss.
Complain to Exceed. This works with every other X Server I have tried.
>Thank you for any help,
>David
I am not much of a help, and I don't work for Sun anymore. Sorry I could not
be of more help.
Syd Polk
--
Syd Polk
jaz...@rahul.net