pop@linus.mitre.org (Paul O. Perry) (11/08/90)
From hagerman@ece.cmu.edu Wed Nov 7 14:59:32 1990
So I tried to work around the problem with a gross hack: I initialize
the toolkit, and then for each display I create an application context
and do an XtOpenDisplay. Then instead of XtAppMainLoop I use my own
routine that checks for and dispatches events for each application
context in a round-robin fashion (no use of select, so the loop uses
all available cycles). I had hoped that the bad state information
would be in the application context, but apparently not; I still get
the same error when I try to open multiple displays.
Does anyone know of a successful work-around?
I don't see this as a gross hack, this is the way I thought you would
have to support multiple displays. I would improve the event loop by
using the select(), and maybe putting a cutoff (an event quantum) to
the number of events you will handle for one context at any one time.
This should prevent any one user from starving everybody else. If
there is a better way to do this let me know.
I tried this out with an application I have and ran into the same
problem :
X Error of failed request: BadCursor (invalid Cursor parameter)
Major opcode of failed request: 1 (X_CreateWindow)
Minor opcode of failed request: 0
Resource id in failed request: 0xa00099
Serial number of failed request: 417
Current serial number in output stream: 460
I'm useing X11R4 to patch level 18 and Motif1.1. Anyone know what I'm
missing ?
P.S. Should I make unique copies of all the elements of argv for each
XtOpenDisplay, or can I use the same strings in the different argv's?
Now this seems relevant. I would think that this is what you have to
do if for example you want users to be able to use multiple -d's at
the command line.
Thanks, Paul.
--
Paul O. Perry MITRE Corporation
Phone: (617) 271-5230 Burlington Road
ARPA: pop@mitre.org Bedford, MA 01730
UUCP: ...{decvax,philabs,genrad}!linus!popmarbru@attc.UUCP (Martin Brunecky) (11/09/90)
In article <POP.90Nov7155026@uci12.linus.mitre.org> pop@linus.mitre.org (Paul O. Perry) writes: > > From hagerman@ece.cmu.edu Wed Nov 7 14:59:32 1990 > > So I tried to work around the problem with a gross hack: I initialize > the toolkit, and then for each display I create an application context > and do an XtOpenDisplay. Then instead of XtAppMainLoop I use my own > routine that checks for and dispatches events for each application > context in a round-robin fashion (no use of select, so the loop uses > all available cycles). I had hoped that the bad state information > would be in the application context, but apparently not; I still get > the same error when I try to open multiple displays. > > Does anyone know of a successful work-around? > >I don't see this as a gross hack, this is the way I thought you would >have to support multiple displays. I would improve the event loop by I think you are wrong here. My programs use a single app-context, multiple XtOpenDisplay and work just fine. Creating multiple app-contexts only causes problems. The toolkit has been designed to deal with multiple displays under a single app context, and (unless you have a bad version of toolkit) it does it right. Including proper event dispatching, time sequencing (with obvious limitations), send event delivery etc. So, instead of inventig gross hacks, I'd look at your tooolkit. May be it does not have some of the mandatory patches. Or may be you did something wrong in the first place. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky [BORN TO BASH UIL] marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
wex@dali.pws.bull.com (Buckaroo Banzai) (11/13/90)
In article <903@attc.UUCP> marbru@attc.UUCP (Martin Brunecky) writes: In article <POP.90Nov7155026@uci12.linus.mitre.org> pop@linus.mitre.org (Paul O. Perry) writes: > From hagerman@ece.cmu.edu Wed Nov 7 14:59:32 1990 > So I tried to work around the problem with a gross hack: I initialize > the toolkit, and then for each display I create an application context > and do an XtOpenDisplay. Then instead of XtAppMainLoop I use my own > >I don't see this as a gross hack, this is the way I thought you would >have to support multiple displays. I would improve the event loop by I think you are wrong here. My programs use a single app-context, multiple XtOpenDisplay and work just fine. Creating multiple app-contexts only causes problems. The toolkit has been designed to deal with multiple displays under a single app context, and (unless you have a bad version of toolkit) it does it right. Brunecky is right, but for the wrong reasons. You do not *have* to create multiple application contexts - it's possible to get many displays working under a single context. HOWEVER, he's wrong that it's a "gross hack." In many cases, there are things that are specific to an application context that you'd like to have be different for different users. In these cases, you do indeed need more than one application context. In some cases, you may in fact need one application context per display. Having these additional structures does make your program a lot more unwieldy, so you shouldn't use them unless you really need them. But there are also some extremely neat tricks you can do once you've got them there. -- --Alan Wexelblat phone: (508)294-7485 Bull Worldwide Information Systems internet: wex@pws.bull.com Never worry about theory as long as the machinery does what it's supposed to do.
pop@linus.mitre.org (Paul O. Perry) (11/15/90)
I seem to have a problem with xmPanedWindowWidgets. I open a panedWindow and I manage a number of frames (or bulletinboards) within it. It works fine, and it works well when I duplicate the same interface in a second application shell WHEN the two toplevel windows go to the same display. However, it does not work if I try to forward the second window to a different display. I fail with the following error: X Error of failed request: BadCursor (invalid Cursor parameter) Major opcode of failed request: 1 (X_CreateWindow) Minor opcode of failed request: 0 Resource id in failed request: 0xa0009e Serial number of failed request: 318 Current serial number in output stream: 341 This type of error was being discussed recently in the context of trying to open multiple displays. I have opened multiple displays, I just have not been able to do it with panedWidgets that have children. clive@x.co.uk (Clive Feather) writes: > Fixes: > 1: Try setting the resources so that a different named cursor is used for > each display. > 2: Patch CvtStringToCursor to stop it storing the value. > 3: Fixed in R4 (from a quick glance at the code). How do I do #1 ? I tryed XCreateCursorFont with no success. As for 2, and 3, I am using Motif1.1 and X11R4(patchlevel 18) on a Sparc1 SunOS4.0.3. I'm actually compiling under g++(1.37.1) but I don't think that (at this point) it's the source of the problem. Alternatively, how can I debug the code to find the offending line in my code? XSynchronize(display) doesn't seem to get me close enough to something that would need to do enything with cursors. Thanks again, Paul. Paul O. Perry MITRE Corporation Phone: (617) 271-5230 Burlington Road ARPA: pop@mitre.org Bedford, MA 01730 -- Paul O. Perry MITRE Corporation Phone: (617) 271-5230 Burlington Road ARPA: pop@mitre.org Bedford, MA 01730 UUCP: ...{decvax,philabs,genrad}!linus!pop
aw@KITCHEN.BELLCORE.COM (Andrew Wason, aw@cellar.bae.bellcore.com) (12/12/90)
[ repost, sorry if you've seen this before ]
I am also having problems using XmPanedWindow on multiple displays
with X11R4(fix18) and Motif 1.1.
The program below opens 2 displays and creates an XmPanedWindow
on each. This results in a BadCursor error:
X Error of failed request: BadCursor (invalid Cursor parameter)
Major opcode of failed request: 1 (X_CreateWindow)
Minor opcode of failed request: 0
Resource id in failed request: 0x1000010
Serial number of failed request: 50
Current serial number in output stream: 59
I traced all the calls to XCreateWindow, and 4 of them
specified CWCursor in their valuemask. For these 4,
attributes->cursor was 0x1000010. I guess the XmSash widget
creates 2 windows each one with a cursor specified.
It seems like someone is caching the cursor for all 4
windows, even though 2 of those windows are in a different
server (where those cursor IDs are invalid).
If you run the program below and specify the same display
for both displays, and also specify the -sync option, it works fine.
e.g.
try -sync -display jello:0 jello:0
I guess this is because the first 2 XCreateWindows cache
the cursor, and the next 2 XCreateWindows are for the same server
and that cached cursor exists and is valid (since we are synchronous,
the cursor is definitely in the server from the previous XCreateWindow).
Does anyone know who is caching the cursor (if that is what is happening)?
The Intrinsics CvtStringToCursor converter uses XtCacheByDisplay,
so I don't think it is the problem (I don't know if XmSash even uses
CvtStringToCursor, also I might be misunderstanding the meaning
of XtCacheByDisplay).
Are there any workarounds?
I think someone had suggested using resources to specify a different
cursor for each XmSash, but I don't see a cursor resource.
Is this only a problem for XmSash, or do any other widgets have
this problem too?
Thanks for any help,
Andrew
[ Sun Sparc1+, SunOS 4.1, MIT X11R4, Quest Motif 1.1 ]
--------------------------------------------------------------------------------
Andrew Wason Bell Communications Research
aw@cellar.bae.bellcore.com Piscataway, NJ
bellcore!cellar!aw
--------------------------------------------------------------------------------
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of shell archive."
# Contents: try.c
# Wrapped by aw@garage on Fri Dec 7 14:51:52 1990
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'try.c' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'try.c'\"
else
echo shar: Extracting \"'try.c'\" \(2254 characters\)
sed "s/^X//" >'try.c' <<'END_OF_FILE'
X#include <stdio.h>
X#include <Xm/Label.h>
X#include <Xm/PanedW.h>
X
X/*
X * cc -D_NO_PROTO -o try try.c -lXm -lXt -lX11
X */
X
Xmain(argc, argv)
XCardinal argc;
Xchar *argv[];
X{
X XtAppContext app;
X Widget toplevel1, toplevel2, pop1, pop2;
X Widget paned;
X Display *dpy1, *dpy2;
X String *saved_argv;
X Cardinal saved_argc;
X String server;
X
X /*
X * save argc/argv since XtOpenDisplay messes with them and we need
X * them for XtAppCreateShell
X */
X saved_argv = (String *)XtMalloc(argc * sizeof(String));
X saved_argc = argc;
X memcpy(saved_argv, argv, argc * sizeof(String));
X
X XtToolkitInitialize();
X app = XtCreateApplicationContext();
X
X if ((dpy1 = XtOpenDisplay(app, NULL, NULL, "Try",
X NULL, 0, &saved_argc, saved_argv)) == NULL)
X XtAppError(app, "Failed to open local display.");
X
X if (saved_argc == 2) {
X server = saved_argv[1];
X saved_argc = argc;
X memcpy(saved_argv, argv, argc * sizeof(String));
X if ((dpy2 = XtOpenDisplay(app, server, NULL, "Try",
X NULL, 0, &saved_argc, saved_argv)) == NULL)
X XtAppError(app, "Failed to open remote display.");
X }
X else {
X fprintf(stderr, "Usage: %s other-display
[toolkitoptions]\n", argv[0]);
X exit(1);
X }
X
X /*
X * now we are done with it
X */
X XtFree(saved_argv);
X
X /*
X * create dummy toplevels which will never be realized
X */
X toplevel1 = XtVaAppCreateShell(NULL, "Try",
X applicationShellWidgetClass, dpy1,
X XmNargc, argc,
X XmNargv, argv,
X NULL);
X toplevel2 = XtVaAppCreateShell(NULL, "Try",
X applicationShellWidgetClass, dpy2,
X XmNargc, argc,
X XmNargv, argv,
X NULL);
X
X pop1 = XtCreatePopupShell("pop1",
X topLevelShellWidgetClass, toplevel1,
X NULL, 0);
X paned = XtCreateManagedWidget("paned1",
X xmPanedWindowWidgetClass, pop1,
X NULL, 0);
X XtCreateManagedWidget("label1",
X xmLabelWidgetClass, paned,
X NULL, 0);
X XtCreateManagedWidget("label1",
X xmLabelWidgetClass, paned,
X NULL, 0);
X
X pop2 = XtCreatePopupShell("pop2",
X topLevelShellWidgetClass, toplevel2,
X NULL, 0);
X paned = XtCreateManagedWidget("paned2",
X xmPanedWindowWidgetClass, pop2,
X NULL, 0);
X XtCreateManagedWidget("label2",
X xmLabelWidgetClass, paned,
X NULL, 0);
X XtCreateManagedWidget("label2",
X xmLabelWidgetClass, paned,
X NULL, 0);
X
X XtPopup(pop1, XtGrabNone);
X XtPopup(pop2, XtGrabNone);
X
X XtAppMainLoop(app);
X}
END_OF_FILE
if test 2254 -ne `wc -c <'try.c'`; then
echo shar: \"'try.c'\" unpacked with wrong size!
fi
# end of 'try.c'
fi
echo shar: End of shell archive.
exit 0