charles@mnetor.UUCP (Charles Stoner) (12/01/90)
I am having trouble creating (and destroying) application shells. The code
below is a distilled version of the original source so while it may not do
anything useful, all lines have a purpose.
The code should produce a topLevelShell containing one button, that when hit
will manage and unmanage a prompt dialog and also create and destroy an
application shell. The prompt dialog is created once and attached to the
button while the application shell is created and destroyed dynamically.
When the button in the main app shell is hit a few times the program will crash.
All lines seem to be necessary to generate a memory fault, even keeping
the prompt dialog modal. I have tried the dynamic shell as both a
topLevelShell and a transientShell. Other than transientShells being
iconified when the client is iconified, is there a difference?
I am using X11R4 and Motif 1.1 and compiling with gcc 1.35 and Motorla UNIX
sys V 3.0.
Am I missing the obvious? Any feedback would be appreciated.
Thanks in advance - Chuck.
/*--------------------- cut here -------------------------*/
#include <X11/Intrinsic.h>
#include <X11/StringDefs.h>
#include <X11/Shell.h>
#include <Xm/Xm.h>
#include <Xm/PushB.h>
#include <Xm/SelectioB.h>
static Widget prompt;
static void subshell(Widget w,XtPointer client_data,XtPointer call_data) {
Widget shell = XtCreateApplicationShell("shell",
transientShellWidgetClass,NULL,0);
XtDestroyWidget(shell);
XtManageChild(prompt);
XtUnmanageChild(prompt);
}
void main(int argc,char **argv) {
Widget shell;
Widget button;
Arg arg;
shell = XtInitialize("shell","Shell",NULL,0,(Cardinal *) &argc,argv);
XtManageChild(button = XmCreatePushButton(shell,"button",NULL,0));
XtAddCallback(button,XmNactivateCallback,subshell,NULL);
XtSetArg(arg,XmNdialogStyle,XmDIALOG_APPLICATION_MODAL);
prompt = XmCreatePromptDialog(button,"prompt",&arg,1);
XtRealizeWidget(shell);
XtMainLoop();
}argv@turnpike.Eng.Sun.COM (Dan Heller) (12/01/90)
In article <5613@mnetor.UUCP> charles@mnetor.UUCP (Charles Stoner) writes: > I am having trouble creating (and destroying) application shells. The code > below is a distilled version of the original source so while it may not do > anything useful, all lines have a purpose. I wonder if you'd have the same problem if you use XtVaCreatePopupShell() rather than > Widget shell = XtCreateApplicationShell("shell", > transientShellWidgetClass,NULL,0); if you'd get the same problem. I am having problems creating multiple toplevel shells using XtVaAppCreateShell() with DialogShell widgets. The exact same thing works fine using XtCreatPopupShell(), but not otherwise. The problem only occurs when I try to create a second shell ... no matter which shell is created first, it works fine, but any subsequent shell created crashes. And while I'm griping about shells :-)... Maybe someone can comment on the following.. If you create dialog shells that are "popup shells" from a parent shell, then those dialogs are part of the parent's "group" and will be iconified when the parent is. The problem is, you can't raise the parent to be *over* it's dialogs... The dialogs are also popped up at 0,0 (topleft corner of screen) rather than anywhere you try to position them using XmNx or XmNy. Even if you do this in a mapCallback function. You also can't set these dialogs' colors easily in app-defaults files ... basically, this all happens with: frame = XtVaCreatePopupShell(NULL, xmDialogShellWidgetClass, parent, ...args..., NULL); However, the problem goes away when I do: frame = XtVaAppCreateShell("name", "Class", xmDialogShellWidgetClass, display, ...args..., NULL); But, the latter case causes the problems mentioned in the beginning. Does anyone have any suggestions? -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
gabe@hpcvlx.cv.hp.com (Gabe Begeddov) (12/06/90)
And while I'm griping about shells :-)... Maybe someone can comment on the following.. If you create dialog shells that are "popup shells" from a parent shell, then those dialogs are part of the parent's "group" and will be iconified when the parent is. The problem is, you can't raise the parent to be *over* it's dialogs... The dialogs are also popped up at 0,0 (topleft corner of screen) rather than anywhere you try to position them using XmNx or XmNy. Even if you do this in a mapCallback function. You also can't set these dialogs' colors easily in app-defaults files ... basically, this all happens with: Popup shells are secondary windows (see style guide) by default especially in the case of DialogShell. In fact DialogShell is intended for use mainly with motif dialog widgets (subclasses of BulletinBoard). In XUI DialogShell wasn't even visible to the programmer (it was called HiddenShell). In any case you should usually be using subclasses of ApplicationShell with XtAppCreateShell and are asking for trouble if you pass a lesser shell in. To solve your problem of stacking order you can use the XmNtransient boolean resource that is available on all WMShell subclasses. If set to false then the transient_for property will not be set and Mwm will treat it as a seperate top level window (for both iconification and stacking). On the issue of placement, I don't know why it wouldn't work if you are specifying an x,y prior to popping it up. If you use DialogShell in the default motif way then you would be "popping" it up by managing the dialog child in which case you could use the XmNdefaultPosition resource to get centering over the grandparent of the dialog. If you need a general purpose secondary window that wont be used with Bulletin boards then use TransientShell or TopLevelShell rather than DialogShell.
marbru@attc.UUCP (Martin Brunecky) (12/07/90)
In article <110630029@hpcvlx.cv.hp.com> gabe@hpcvlx.cv.hp.com (Gabe Begeddov) writes: > > And while I'm griping about shells :-)... > >On the issue of placement, I don't know why it wouldn't work if you are specifying >an x,y prior to popping it up. If you use DialogShell in the default motif way >then you would be "popping" it up by managing the dialog child in which case you >could use the XmNdefaultPosition resource to get centering over the grandparent >of the dialog. > Most often overlooked "feature" of XmDialogShell is the fact it IGNORES x,y values set by the user for the *shell*, and uses the x,y specified for it's *child*, i.e. manager widget. The "feature" comes from XUI's decision to *hide shells*, i.e. make the programmer *unaware* of the shell presence. Wheather it was the best descision ... Note the use of the child's x,y for the shell's position also implies several hacks for get values ... To OSF: (just a minor proposal) May be, the XmDialogShell should default to "Xm_UNSPECIFIED_POSITION" for x,y; meaning "use child's x,y instead". The same should apply for shell width,height. If the user has specified x,y for the shell, i.e. it is no more "Xm_UNSPECIFIED_POSITION", the shell could behave like any normal, good behaving Xt shell. This would preserve functionality for those who like/depend upon XUI style of "hidden things", but also eliminate confusion for those who know (or believe to know) what the shell is for. =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404 -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404