[comp.windows.x] Motif 1.1 problem with shells and XtRealize and XtUnrealize

dka@hare.cdc.com (d k adams x-2675) (06/07/91)

HELP! DOES ANYONE KNOW OF A WORK AROUND FOR THE FOLLOWING PROBLEM?

My application requires many windows to pop up in response to a selection from
a menu bar. The windows that are popped up are too complex to use a pop up 
shell and XtPopup and XtPopdown.  ( It is my understanding that a pop up shell
can only be the parent of one composite or simple widget. My pop up windows 
are neither of these. ) My solution to get around this was to create all "pop 
up" windows as children of topLevelShells or applicationShells. Then I could
Realize and Unrealize the shells as they were needed. 

The problem is that consecutive calls to XtRealize and XtUnrealize do not work.
The widgets act like they are ignoring input after the second call to XtRealize
the shell. 

The problem only occurrs with Motif 1.1. The program works fine with Motif 1.2.
Based on this I can only assume that it is a Motif bug that was fixed in 1.2.
I have to use Motif 1.1 for my platform.

DOES ANYONE KNOW OF A WORK AROUND FOR THIS PROBLEM USING MOTIF 1.1?

I do know that an option is to create and destroy the widgets dynamically
instead of creating all widgets in the beginning of my programs execution.

I am more interested in fixing the above described problem.

PLEASE SEND A RESPONSE TO  email:  dka.udev.cdc.com
| Dorian K. Adams (dka@hare.udev.cdc.com ) phone: (612) 482-2675
| Control Data Corp.
| 4201 N. Lexington Ave. Arden Hills, Mn 55126-6198 

pete@iris49.biosym.COM (Pete Ware) (06/10/91)

dka> My application requires many windows to pop up in response to a
dka> selection from a menu bar. The windows that are popped up are too
dka> complex to use a pop up shell and XtPopup and XtPopdown.  ( It is
dka> my understanding that a pop up shell can only be the parent of
dka> one composite or simple widget. My pop up windows are neither of
dka> these. ) My solution to get around this was to create all "pop
dka> up" windows as children of topLevelShells or applicationShells.
dka> Then I could Realize and Unrealize the shells as they were
dka> needed.

I could be completely wrong, but I think you are completely missing
the point of using widgets.  A shell may only be able to hold one
child widget, but that child is free to contain as many children as it
implements (ad infinitum).  For example, a typical dialog box may have:

Shell
	 Pane
		ScrolledWindow
			Form
				label1 ... label_n
		RowColumn
			label1 ... label_n
		...
You can see the Shell only has one child.

dka> The problem is that consecutive calls to XtRealize and
dka> XtUnrealize do not work.  The widgets act like they are ignoring
dka> input after the second call to XtRealize the shell.

You really want to popdown the shells.  Also, you may need to wait
until returning to your event loop to get the second XtRealize to take
effect.  Also, I'm not sure how the Motif dialog shell's respond to
XtRealize/Unrealize while popped up.

dka> I do know that an option is to create and destroy the widgets dynamically
dka> instead of creating all widgets in the beginning of my programs execution.

It may be that the Motif dialog shells all pop themselves up whenever
the child is managed.  If you delay managing the shell until you want
to pop it up, things may work.

--pete

asente@adobe.com (Paul Asente) (06/11/91)

You seem to be rather confused...

In article <33913@shamash.cdc.com> dka@mips.COM (d k adams x-2675) writes:
>
>HELP! DOES ANYONE KNOW OF A WORK AROUND FOR THE FOLLOWING PROBLEM?
>
>My application requires many windows to pop up in response to a selection from
>a menu bar. The windows that are popped up are too complex to use a pop up 
>shell and XtPopup and XtPopdown.  ( It is my understanding that a pop up shell
>can only be the parent of one composite or simple widget. My pop up windows 
>are neither of these. )

There are several classes of shells, and all of them have the characteristic
that they can only hold one *immediate* child.  Normally you make the child
be some kind of composite (a dialog box or form, typically) and put other
widgets inside.

The class of shell you use is primarily tied to how you want the window
manager to treat the shell, not how your application treats it:

  popup shell: have the window manager ignore it (e.g. menus)
  transient shell: have the window manager treat the shell's window as a
	second-class citizen, subordinate to another window (whatever this
	means for your particular window manager)
  top level shell: have the window manager treat the shell's window as a
	full-fledged citizen of your screen (ditto)
  application shell: have the window manager (or session manager if
	appropriate) treat the shell's window as an application (ditto)

Having more than one application shell on the same display is usually a
mistake unless your application pretends to be multiple logical applications
to the user.

You can use XtPopup and XtPopdown on any class of shell.

>My solution to get around this was to create all "pop 
>up" windows as children of topLevelShells or applicationShells. Then I could
>Realize and Unrealize the shells as they were needed. 

This should work (modulo bugs) but it will be much slower than using XtPopup
and XtPopdown.  Or, since you're using Motif, use the managing/unmanaging
style of control provided with Motif.

	-paul asente
		asente@adobe.com	...decwrl!adobe!asente

    Ratz put a bucket of liquid in front of me.
   "I wanted a glass of docs, Ratz.  What the hell is this?" I barked.
   "Motif don't fit in a glass anymore," he barked back.
    I looked at the liquid.  It was totally opaque to me.