Conference bulova::decw_jan-89_to_nov-90

Have you tried using async event handling?  Check out the man pages for
XSelectAsyncEvent and XSelectAsyncInput.
				Jeff

 see a couple points of confusion.  First, the serial number:  That number has
nothing to do with the event queue size.  It is the serial number for the last
request that the server saw from your connection.  It does keep increasing till
it wraps at 16 (?) bits.

Second, regarding events:  Did you really want ResizeRedirect and not just
ConfigureNotify?  I am suspicious of using ResizeRedirect.  People don't do that
very often; there may be a bug, or there may be some interaction with the window
manager.  What you are telling it, in effect, is "when the window manager tries
to resize my window, don't do it.  Just tell me."  However, the window manager
will also have something similar set (actually SubstructureRedirect on the
parent) so it will get control when you try to resize the window.  I'm wondering
if maybe there is some sort of funny interaction here.  The SubstructureRedirect
has precedence, according to the protocol.

Finally, about XSync.  That only flushes the OUTPUT queue.  What you need to make
sure of is that if something that you just requested was
going to cause the event you are waiting for, you'd better make sure it is
flushed first.

The "standard" way to do what you want would be to use XEventsPending to see if
there were any events in the queue.  If not, go on about
your business.  If so, do XNextEvent (guarnateed not to block because there is
something in the queue).  If the event is uninteresting, ignore it.  That way,
the queue will be emptied as you go along.

Burns

Hi Burnie, (you didn't mention your first name [I think])

this X windows stuff seems to be pretty awesome.  It's like there's not
anyone person who knows all about it.  For instance here is paragraph
from the X library (Guide to) :

    8.6 Handling the Output Buffer
    8-42 Events and Event-Handling Functions.

    XSync(display, discard)
            Display *display ;
            Bool    discard ;

    display ...
    discard Specifies a Boolean value that indicates whether XSync
            discards all events on the event queue.

        .
        .
        .

    Finally, if you passed False, XSync does not discard the events in
    the queue.  If you passed True, XSync discards all events in the
    queue, including those events that were on the queue before XSync
    was called.

This means that the output buffer is not the only queue you can manipulate!

Anyway thanks for the info on XEventsPending and XSelectSync*.  More X functions
that I have overlooked.

Can you explain more about this SubstructureRedirect thingy and how it relates
to my problem of not been able to resize a window under program control.

			I HAVE A BELIEF

		THE MOUSE IS NOT THE ONLY METHOD OF

		USER INPUT THAT CAN BE USED TO CONTROL

		YOUR WINDOWS ENVIROMENT.

I have been trying to use :

	XResizeWindow() & XSetNormalHints() & XSetSizeHints()

to resize my window from program control.  There seems to be a problem in UWS
2.2(d) that make the window manager ignore all these requests.

The arguement being that : the windows should only be controlled by/from the
user and not the program.

Well has anyone heard about keyboards lately.  These are funny little user input
devices that can also be used to control the user enviroment.

I have an application that has a hot key selection for minimum/maximum window
sizing.  For example :

	user hits ALT-B :- and window becomes as big as possible.
	user hits ALT-S :- and window becomes small.
	user hits ALT-W :- and a dialog box appears and prompts for the
			   exact window dimensions (critical in mining apps.)

Well my program work from VMS DECwindows and it works from UWS 2.1 RISC but
from UWS 2.2(d) RISC my windows never change size.

Could you explain this SubstructureRedirect business to me and how I can force
the window manager to resize my windows under user control via my program.

I will try the ConfigureNotify event and see if that helps me.

Regards,

Walter Zambotti.

>this X windows stuff seems to be pretty awesome.  It's like there's not
>anyone person who knows all about it.

That is certainly true, unless it is someone like Bob Scheiffler, who seems
to have total recall.

>For instance here is paragraph
>from the X library (Guide to) :
>
>
>    8.6 Handling the Output Buffer
>    8-42 Events and Event-Handling Functions.
>
>    XSync(display, discard)
>            Display *display ;
>            Bool    discard ;
>
>    display ...
>    discard Specifies a Boolean value that indicates whether XSync
>            discards all events on the event queue.

I'll be darned.  Either I never knew that, or I forgot.  I've always just
kind of cut and paste XSync when I needed it with 0 as the second parameter.
What do you know.

Of course, I guess using it in the way you did does not guarantee you that there
is not another event of interest in the queue.  That is the hard part about
everything being so asynchronous.  A new, interesting event might come in between
the time you check the queue and the time you flush.  I still recommend
XEventsQueued (I had the wrong name before...there is XPending, and
XEventsQueued; I mixed the two names).

===========================================================================
Substructure Redirect:  This is intended for use by a window manager.  What
happens is that the window manager owns the parent window of any windows that
you create.  It puts Substructure Redirect on the parent window.  Then any
requests (like configure, unmap, etc) which you make on your window are sent
to the window manager (via a *Request event) rather than being acted on by
the server.  The window manager then gets to change all its decorations before
actually changing your window.

=============================================================================
Window manager interaction:  The theory is that the window manager is supposed
to control the screen real estate.  This implies that it has to be "in the loop"
for all window config changes.  The window manager is allowed to deny changes.
That is, if you do a programmed size change on the window, the winmgr can feel
free to ignore it.  The theory continues that if, in a particular job, you
want the program to be able to do this stuff, write a window manager that does
what you want.  Note:  This is not necessarily a statement of what I as an
individual or DECwindows as a program believe is right; its just the way X works.

Now a few months after DECwindows came out (including the dwm window manager),
a document called the ICCCM was written.  This includes some communications
conventions between clients and the window manager.  Some of these things are
the various HINT properties you can give the winmgr.  Dwm was out before all this
stuff and does not support it all.  When Motif appears soon, mwm, should support
it all.  It is a lot more customizable than dwm.

I hope this helps; any window manager gurus et al should feel free to step in
and clarify.  This is about the extent of my knowledge on the subject.

Burns (my real first name) Fisher (my last name)