Re: How to change Input Window

New Message Reply Date view Thread view Subject view Author view

YAMANAKA MASAHIKO (wryml++at++dimwit.dst.nk-exa.co.jp)
Thu, 17 Jul 1997 19:33:29 +0900

Thank you for your reply, Dirk!
However...

^) you can read the x window events of the performer window from anywhere,
^^) also another process. finally performer ends up on a Xwindow, which you
^^) can access. when the performer window is opened you can:

What I want to do is...

motif-app (launcher):
  invoke a performer-app and send the value of XtWindow(widget) to the perf-app.
  after creating some managedWidgets...
    XtRealizeWidget( toplevel );
    Window xWin = XtWindow(widget);
    sprintf( cmd, "perf-app %d", xWin );
    system( cmd );
    XtMainLoop()

perf-app:
  process all of the performer-work such as drawing, event processing, etc.
  after creating Shared->pw...
    Shared->pw->setWSWindow( XOpenDisplay( NULL ), xWin )

I tried this with very very simple motif-app and simple perf-app (complex.C).
In this case, Drawing works very well, but perf-app can't process events because of
an error...

X Error of failed request: BadAccess (attempt to access private resource denied)
  Major opcode of failed request: 2 (X_ChangeWindowAttributes)
  Serial number of failed request: 153
  Current serial number in output stream: 159

This error occurs at the XSelectInput(pfGetCurWSConnection(),...) in the InitXInput().

I'm not familier with X-development, so I think someone know some workarounds about this...

Thanks,

--
M.Y.


^^) performer app:
^^) 
^^) 	pfPipeWindow* pw // is open
^^) 
^^) 		// get the window
^^) 	Window xw = pw->getWSWindod();
^^) 		// and the X connection
^^)         const char* con = pf->getWSConnectionName();
^^) 
^^) now the performer app can continue. by some magic IPC you pass w and con
^^) to another process which now can:
^^) 	
^^) x event reader and decoder:
^^) 
^^) 		// open your OWN ! connection to Window Manager
^^)     	Display* display = XOpenDisplay(con);
^^) 		// ask for the events he want from the Performer Window
^^)     	long e_mask = 	KeyPressMask | KeyReleaseMask |
^^) 			ButtonPressMask | ButtonReleaseMask |
^^)                     	PointerMotionMask;
^^)     	XSelectInput(display, xw, e_mask);
^^) 
^^) 		// and forever read events...
^^)     	XEvent e;
^^)     	while(1) {
^^)         	XWindowEvent(display, xw, e_mask, &e);
^^)         	cerr << "e type = " << e.type << endl;
^^)     	}
^^) 
^^) you now can decode that events in this process and with some more IPC
^^) magic pass higher level Application commands back to your performer
^^) application:
^^) 
^^) performer app:
^^) 	
^^) 	while(1) {
^^) 		pfFrame();
^^) 		
^^) 		read_app_commands_from_somewhere();
^^) 	}
^^) 
^^) works for me. and added design benefit is, that the performer app doesnt
^^) really see window manager events any longer. you can log events and play
^^) them back from disk. sometimes quit usefull.
^^) initially more work, but pays back, pretty soon.
^^) 
^^) dirk.
^^) 
^^) 			
^^) 
^^) 
^^) 
^^) YAMANAKA MASAHIKO wrote:
^^) > 
^^) > Hello all,
^^) > This might be a proper question for this mailing list, however please let me
^^) > ask...
^^) > 
^^) > I made 2 simple test programs.
^^) > 
^^) > One is the launcher which uses some Xt routines like...
^^) > 
^^) >   Widget toplevel = XtInitialize(...);
^^) >   Widget fmWidget = XtVaCreateManagedWidget(...xmFormWidgetClass, toplevel,...);
^^) >   Widget cfWidget = XtVaCreateManagedWidget(...xmFormWidgetClass, fmWidget,...);
^^) >   XtRealizeWidget( toplevel );
^^) > 
^^) >   char cmd[512];
^^) >   sprintf( cmd, "%s %d", argv[1], XtWindow(cfWidget) );
^^) >   system( cmd );
^^) >   XtMainLoop();
^^) > 
^^) > And another is the performer-based application which is launched by launcher.
^^) > In my test, I used complex.C.
^^) > I changed it to...
^^) > 
^^) > after Shared->pw = new pfPipeWindow(p);,
^^) >   Window xWin = (Window)atoi( argv[1] );
^^) >   Shared->pw->setWSWindow( XOpenDisplay(0), xWin );
^^) > 
^^) > As I don't use InitXInput(), it works well, however it doesn't accept any events.
^^) > Otherwise when I use InitXInput(), it doesn't work, so I tried to make new Window
^^) > accepting the events, but I couldn't.
^^) > 
^^) > Of course there is a way making the launcher process the events, send some commands
^^) > to the perf-app, and perf-app reads it with no-wait.
^^) > But I want to let the perf-app accept/process the events.
^^) > 
^^) > Could anyone please direct me?
^^) > 
^^) > Any help will be greatly appreciated!!!
^^) > 
^^) > Thanks,
^^) > --
^^) > M.Y.
^^) > =======================================================================
^^) > List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
^^) >             Submissions:  info-performer++at++sgi.com
^^) >         Admin. requests:  info-performer-request++at++sgi.com
^^) =======================================================================
^^) List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
^^)             Submissions:  info-performer++at++sgi.com
^^)         Admin. requests:  info-performer-request++at++sgi.com


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:37 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.