[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
|
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
1322.0. "why does my menu stay on screen too long ?" by HANNAH::OSMAN (see HANNAH::IGLOO$:[OSMAN]ERIC.VT240) Tue Aug 22 1989 12:29
I've mentioned some of these problems before, but I still haven't solved them,
and they may be related to each other, so I bring them up together and again.
My product has some interface problems that I just can't figure out. The
main symptoms are these two:
1) If I focus on my graphics window by clicking in it, I can type
fine. However, if I focus on it by clicking in the title bar, I can
only type while the mouse is kept in the window.
2) If I pull up a menu with the mouse and move the mouse off the menu
and onto my graphics window and release the mouse, the menu stays
on the screen. But if I instead move the mouse off the menu and onto
gray screen background to release the mouse, the menu disappears as
it should.
All I can guess is that I'm not handling events properly. I'm trying to be
careful, but who knows. My event handler is a bit hairy for the following
reasons:
1) Since the product is a emulator (TEK 4125), we need to handle
both DECwindows events and pty events. Hence we can't use XtMainLoop.
2) Since we have some colormap considerations, we have a mixed bag
of UIL objects and our own X windows. Hence we have to make sure
that neither the toolkit or ourself throws away any of each other's
events.
To hopefully solicit some help with my problems, let me reveal two things,
our main window tree structure, and our event handler strategy.
First, the window tree:
main window widget with menu bar
|
|
window widget
|
|
our graphics window
The graphics window we create with XCreateWindow and the rest is made
with a standard .UIL file.
The event handler strategy is the following:
There is a routine called process_one_event, which uses XtNextEvent to
read exactly one event.
If the event is ClientMessage, we call our x11_event_handler routine directly
(explained soon), and then exit.
If the event is something else, we look at it's window id and see if it's
one on our list of non-uil windows. If so, we also call x11_event_handler
and then exit.
If we haven't exited yet, we assume the event is a uil one, so we call
XtDispatchEvent.
The x11_event_handler is a huge switch statement in C in which we respond
to the event type, such as exposure, click, keys, etc.
As I write this, I'm starting to wonder if perhaps we're handling
certain client messages that we should be letting XtDispatchEvent see.
I'll send this note, and go check that possibility.
Anyone have any ideas ?
Thanks.
/Eric
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1322.1 | | LEOVAX::TREGGIARI | | Tue Aug 22 1989 14:26 | 17 |
| Yes, there are events that the toolkit needs to "see" that it is not getting.
1. Clicking on the title bar causes the window manager to send a client
message to the shell widget. If you are taking away all client messages
that would cause the focus problem.
2. Menubar processing depends upon a "grab" facility in the Intrinsics
which guarantees that the widget will "see" the button-up event no
matter where it happens. If you are not XtDispatch'ing the button-up
event, that is why the menu stays down.
You can probably "hack" around these problems, but there are probably
others. The only "safe" solution is to write your graphics window as
a widget.
Leo
|
| 1322.2 | how can we use our colormap on widget on Firefox? | HANNAH::OSMAN | see HANNAH::IGLOO$:[OSMAN]ERIC.VT240 | Tue Aug 22 1989 15:03 | 14 |
| The reason our graphics window is not a widget is that we had colormap
problems on the Firefox.
The firefox complained about "bad match" because the visual type of our
colormap was different from that of the window.
Has anyone else found a way to associate their own colormap with a
widget on a Firefox ?
If so, I might be able to go back to using the widget as our graphics
window.
/Eric
|
| 1322.3 | | PSW::WINALSKI | Meetings are our most important product | Tue Aug 22 1989 16:13 | 11 |
| There aren't any ways (aside from some gross hacks) to get the Toolkit to use
anything other than the default visual. Using the current widgets, that is.
XtCreateWindow takes a visual as its argument, so widget code itself is capable
of specifying a visual other than the default, but the catch is that none of
the existing widgets give you any way to make use of that feature. I suggest
creating your own widget that is a subclass of the window widget. It would
behave exactly like a window widget except that it uses the visual you want
instead of the default.
--PSW
|
| 1322.4 | menu problem solved, still can't quite do focus properly | HANNAH::OSMAN | see HANNAH::IGLOO$:[OSMAN]ERIC.VT240 | Tue Aug 22 1989 17:54 | 43 |
|
Leo sent me some window grow-your-own subwidget code, but it's not yet
clear how easy this is to install.
However, I've made some progress, and I'm hoping someone might have
some ideas.
I've simplified my event handler to not check for ClientMessage at all.
Now the event handler only looks at the window id, and calls XtDispatch
or my private event handler according to whether the window is a uil
window or not.
So the menu disappearance problem is solved.
But the focus problem remains.
I've got two top-level windows on the screen, one's the main window
I mentioned in .0. The other is a totally non-uil window whose parent
is RootWindowOfScreen. We call that one the dialog window.
The application echoes all typein in the dialog window, (if you know
TEK terminals, you know what I mean)
The intent is that if focus is in either the graphics window or the
dialog window, typein should be echoed in the dialog window.
So, there are FOUR ways to get focus, namely by clicking in either
title bar, or either window body.
The problem is, only three out of the four work. The one that doesn't
quite work is clicking in the title of the main window. As I
mentioned, this causes typein only to be echoed if the mouse is left
in the body of the main window, otherwise typein is lost.
The title bar gets highlighted as though focus is being established
properly. But I'd sure like to solve this mouse problem.
Thanks for any more hints.
/Eric
|