| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
I understand that under the current implementation of the DECwindows
interface a windowing program must have processed through
DECW$LOGINOUT.EXE to get a valid window manager to control the windows
that are created (see note 431.5 in this conference).
I have a customer that wants to have a windowing program run from a
batch file so that all the initialize, manage child, etc. is all done
and is waiting for a user to login (via DECW$LOGINOUT) before it
realizes the top level widget to make the window(s) visable. The
problem is that since the batch job doesn't go through the
DECW$LOGINOUT program there is no <mumble>_WM process to handle the
DECwindow calls (like initialize, for instance... which is the current
traceback location of the bombing program {:^(} ).
Is there a way to have the window manager up and running, *WITHOUT* the
icon box, so that the batch initiated windowing program can run?
I have a very short deadline on this, any pointers/help is most
appreciated!
Aloha,
Richard
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 677.1 | LESLIE::LESLIE | There is no final frontier | Wed Apr 26 1989 02:21 | 8 | |
Include these lines in the batch job.
$
$ set display/node=0/create/transport=local
$
| |||||
| 677.2 | Expansion | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Wed Apr 26 1989 14:45 | 25 |
I think .0 was somewhat confused, but somehow Andy managed to figure out the real problem. I'm impressed. In any case, to expand, a batch job certainly has run loginout. The problem is that it will not have DECW$DISPLAY, and thus the job does not know where to send the display. Andy's solution fixes this. However, if I understand right, there may still be an issue. I think you are saying that you want the batched application just sitting there waiting for the user to log in. That is, if the user is NOT logged in, you want the application to just hang. That will not happen without some programming in the application. The thing is that before the user is logged in, the application will probably not be authorized to display on the workstation in question. This means that once again, XOpenDisplay will bomb. What I do is to have my batch job actually do a SPAWN with my application. Then the batch job looks every minute or so to see if its child is still around. If not, it restarts it. Thus, if the user is not logged in, the application bombs and the batch job restarts it a bit later. The cycle repeats till the user logs in, at which time incoming displays from the batch machine are enabled and the application starts running. Burns | |||||
| 677.3 | Close, but not quite there... | GSRC::WALLACE | I bark, therefore I am. -- Descartes dog. | Wed Apr 26 1989 19:46 | 43 |
Thanks for the quick replies; but .0 is addressing another issue. The
application is run from the following command file.
The command file that is submitted:
$ set display/create/node=0/transport=local
$ run/nodeb menu
$ exit
The log file that results (minus extranious data not associated with error):
%XLIB-F-IOERROR, xlib io error
%TRACE-E-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
00017E26 00017E26
----- above condition handler called with exception 02DB821C:
%XLIB-F-IOERROR, xlib io error
----- end of exception message
0005B562 0005B562
0005BCBC 0005BCBC
000577DF 000577DF
00129443 00129443
00111393 00111393
0010240F 0010240F
MENU MENU 80 000000A3 00009E63
ADA$ELAB_MENU ADA$ELAB_MENU 00000009 00008609
0000A730 0000A730
00017BB2 00017BB2
ADA$ELAB_MENU ADA$ELAB_MENU 0000001B 0000861B
0000A70B 0000A70B
%SYSTEM-F-NOLOGNAM, no logical name match
The application called MENU does a Xt Initialize at line 80 in the code
and this is where it bombs. The application is awaiting input via a
mailbox just prior to the Xt Realize call. Andy's suggestion confirmed
what I was doing, but as can be seen the results are not what I want.
Am I missing something in the many undocumented, not supported .DAT
files that float about in an X-windowing system? Is this a problem
addressing the window server?
Richard
| |||||
| 677.4 | Documentation? Never heard of it! | GSPMO::WALLACE | I bark, therefore I am. -- Descartes dog. | Wed Apr 26 1989 22:53 | 19 |
It seems that a goodly number of things under DECwindows are not WELL
documented in the seven volume doc-set...
LIKE for INSTANCE the DECW$SERVER_ACCESS_TRUSTED logical name that
allows access to the server; and the format of the data in the file
pointed to by the logical.
If someone can tell me where all these *goodies* are WELL documented
and available to DECies (don't say NOTES...), I'll send them a bonus of
$20.00(US); be warned that references will be checked throughly!
Having found note 445 I can see that my system didn't have this logical
or this data file at all (It does now!). My program now works just
fine now
| |||||