Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!ucbvax!BAE.BELLCORE.COM!aw
From: aw@BAE.BELLCORE.COM (Andrew Wason)
Newsgroups: comp.windows.x.motif
Subject: Re: XmBulletinBoard questions
Message-ID: <9104011723.AA02583@bellcore.bellcore.com>
Date: 1 Apr 91 17:23:12 GMT
References: <1991Apr1.134136.4176@world.std.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 28

world!kdg@uunet.uu.net (Keith D Gregory) writes:
> 1) allowOverlap:
>    Does this work? It doesn't appear to have any effect on my system. I've
>    tried all sorts of strangeness - unmanaging and then remanaging an
>    overlapping child, after realization, with XtFlushes everywhere. I would
>    assume that the child would not be managed, or its geometry would be
>    changed, but that's not the case.


If allowOverlap is False, children can overlap - but geometry
requests which would result in overlapping children will be denied.
So you can create/manage a widget which overlaps other widgets,
but you can't change a widgets Position/Dimension which would
result in it overlapping another widget.  This is what the documentation
for allowOverlap implies when it talks about allowing/disallowing
"geometry requests" (creating a child widget and managing/unmanaging child
widgets aren't considered geometry requests).

When allowOverlap is False, BulletinBoard actually forces child
widgets to be at least one pixel apart.  This seems like an off-by-one bug.

Andrew

_______________________________________________________________________________

Andrew Wason                                       Bell Communications Research
aw@bae.bellcore.com                                Piscataway, NJ
bellcore!bae!aw