Window “W” appears as a callback to a widget in the base window. An
area in W is empty because it is where one of two independent windows
(“A” or “B”) will be placed and made to appear alternately depending
on a dynamic status variable. Windows A and B are known through
their internal links which specify a module-relative location of
(x,y).
When W is realized, A and B are assigned W as parent to each:
ApModuleParent(ABM_A, AP_PARENT, ABW_W);
ApModuleParent(ABM_A, AP_PARENT, ABW_W);
then one is created and a widget pointer saved as follows:
if (use_A)
A_w = ApCreateModule(ABM_A, ABW_W, NULL);
else
B_w = ApCreateModule(ABM_B, ABW_W, NULL);
Later, use_A may become false leading to A_w being destroyed and B_w
created.
</excruciating detail>
Here’s the problem:
Both A and B appear and replace each other as desired. BUT, when the
parent window W is dragged, A and B stay fixed in their original
position relative to the screen. I, of course, want A or B to move
with W. I tried setting anchor properties thus:
PtSetResource(A_w, Pt_ARG_ANCHOR_FLAGS, Pt_ANCHOR_ALL,
Pt_IS_ANCHORED) but to no effect.
I tried using PtAnchorWidget(A_w) but that resulted in a compile error
about “not enough arguments.” After much searching, I found the
prototype in PtProto.h which indicates there should be a second
argument, an integer. Taking a blind stab, I tried
PtAnchorWidget(A_w, 0) but that also didn’t anchor A or B within W.
Help?
P.S. I’ve tried to think of other methods to do the overlay/flip-flop
thing but both A and B have a fair number of interactive child
widgets and, for example, making each into a Group seemed even more
complicated.
Windows are disjoint widgets and therefore can’t be anchored to
anything. I suggest you either setup a move callback in Window W and
then move A or B accordingly or you can use panel’s inside of Window W.
Thanks,
Rodney
rlb wrote:
Window “W” appears as a callback to a widget in the base window. An
area in W is empty because it is where one of two independent windows
(“A” or “B”) will be placed and made to appear alternately depending
on a dynamic status variable. Windows A and B are known through
their internal links which specify a module-relative location of
(x,y).
excruciating detail
When W is realized, A and B are assigned W as parent to each:
ApModuleParent(ABM_A, AP_PARENT, ABW_W);
ApModuleParent(ABM_A, AP_PARENT, ABW_W);
then one is created and a widget pointer saved as follows:
if (use_A)
A_w = ApCreateModule(ABM_A, ABW_W, NULL);
else
B_w = ApCreateModule(ABM_B, ABW_W, NULL);
Later, use_A may become false leading to A_w being destroyed and B_w
created.
/excruciating detail
Here’s the problem:
Both A and B appear and replace each other as desired. BUT, when the
parent window W is dragged, A and B stay fixed in their original
position relative to the screen. I, of course, want A or B to move
with W. I tried setting anchor properties thus:
PtSetResource(A_w, Pt_ARG_ANCHOR_FLAGS, Pt_ANCHOR_ALL,
Pt_IS_ANCHORED) but to no effect.
I tried using PtAnchorWidget(A_w) but that resulted in a compile error
about “not enough arguments.” After much searching, I found the
prototype in PtProto.h which indicates there should be a second
argument, an integer. Taking a blind stab, I tried
PtAnchorWidget(A_w, 0) but that also didn’t anchor A or B within W.
Help?
P.S. I’ve tried to think of other methods to do the overlay/flip-flop
thing but both A and B have a fair number of interactive child
widgets and, for example, making each into a Group seemed even more
complicated.
Windows are disjoint widgets and therefore can’t be anchored to
anything. I suggest you either setup a move callback in Window W and
then move A or B accordingly or you can use panel’s inside of Window W.
I’d definitely recommend the latter. If you use a callback to move the
child window, what will happen is that when a person moves the parent
window, it will get an expose event and draw some contents in the strip
that got exposed; then it’ll find out that it’s been moved, and run
your callback that asks the window manager to move the child window; and
finally, moving the child will send another expose to the parent,
causing it to draw again. In short, you’ll get a lot of flicker around
the edges of the child window. And unless you have opaque drawing
disabled, all the extra events going back and forth will make the
dragging of the window feel jumpy.
Thanks for clarifying the status of a PtWindow. Taking another look
at online Help (“PtDisjoint”) tells that these objects have no parent
so my call to ApModuleParent() wasn’t going to do the trick.
Thanks for clarifying the status of a PtWindow. Taking another look
at online Help (“PtDisjoint”) tells that these objects have no parent
so my call to ApModuleParent() wasn’t going to do the trick.
Actually, they may have a parent, and ApModuleParent() does work with
windows. The main difference is that while a regular widget lives
“inside” its parent (i.e. is clipped by it, and its position is relative
to the parent’s origin), a disjoint widget lives “outside” of its
parent, if any, and has an independent position on the screen that
doesn’t move when the parent moves. But this difference only applies to
X and Y but not Z – a child window always stays in front of its parent,
and you can’t put an unrelated window (or an “uncle”) between them.
(This gets trickier if you mix windows with other disjoint widgets, such
as PtMenus or PtRegions.)
Oh yes, PtPanelGroup as a means of switching between two or more sets
of presentations. I used this widget months ago in another prototype
and totally forgot about it. Thanks for the memory jogging
suggestion.