Conference bulova::decw_jan-89_to_nov-90

3406.0. "Application problem with dual-headed system" by BUSHIE::TAN () Fri Sep 28 1990 04:52

Hello,
    
    	A customer submitted the following problem descriptions for his
    dual-headed decwindow workstation (believed to be the first in this
    country), I have very little experience with DECwindow programing,
    not to mention with dual-headed system, so could some body comment
    on it?  Thanks.
    
    
      "	We have VAXstation 3100 system 40 with dual monitor adaptor cable.  
Screen 0 is a VR299 color display, screen 1 is a VR262 monochrome display.
We are currently using VMS 5.3-1, the session manager always starts on screen 0.

	We wish to run a decwindow application written by us, on the color 
display, and all other applications on the monochrome display, by setting the
session manager screen number to "force screen 1", I get all standard
applications (decterms etc) on the monochrom, except for the iconised session
manager.

	Then I wish to start my application.  A simple application written
in low level calls (X$Open_display) can do this easily.  However, I already
have a largish application (several thousand lines of pascal) which uses
UIL/DRM.  Just using the code as it is results in the window appearing on
the monochrom screen.

	The top widget in the UIL is the main_window widget.  Despite the
main_window widget having a SCREEN attribute, this does not seem to be
supported by UIL.  Even if it was, I'm still not sure how to specify in
the UIL the screen that I want, by string value?

	Having Xt$initialized, and fetched the main_window, I tried changing
the DWT$c_nscreen attribute of the main_window before managing or realizing
it.  The screen was obtained by doing a X$open_display, and X$screen_of_display
previously.  This code worked, but a few calls on at the 'realize" ... has 
failed with an error about lack of 'per display' information.  Upon further
reading I found that most children will inherit their screen attribute from
their parent, so I assum that this failed because the main_window wa on the
screen and it's children were on another, maybe, anyway.

	Similarly tried this attribute change on the top_level widget given by
the Xt$initialize call before the fetch of the main_window but this failed
similarly.

	Also tried passing an override argument list containing the arguments
of dwt$c_nscreen, and the screen value to the fetch_widget call which first 
retrieved the main_window but this failed in the same way.

	From reading the docs for Xt$initialize, I see that it call 
display_initialize.  this discusses an URLIST argument set which sounds like a
likely method of passing parameters, but I could find no description of what 
those parameters might be.

	I believe that if I could set up the appropriate resource in on of
decw$system_defaults, decw$user_defaults etc such as is done by decterm
etc, however, I can't find any docs on how to select the filename etc, or what 
name I should be using for the resource.  This is all, of course, assuming
that SCREEN is a resource that I can set in this way.

	All of this could be because I am not passing the screen in the
right way, or I am not doing some other thing right.  Fine, but I haven't
got a clue what to try next, and the docs are not leading me anywhere.  
Further confusion results from the fact that almost all of the parameters in
the VAX binding - NOT the C binding - still pass parameters by C conventions.
This is great if you know what they are, but much of the time I have to
guess.  I fight with the odd parameters that have been coded into the pascal
library definitions for decwindows.  So I could just be passing things by the
wrong mechanism. "
    
    -dave

Set up your machine the way you have it, such that all windows display on the
monochrome display (1).  You will always get an icon box on each display with
the XUI window manager.

Then write a command file to execute the customers program, only before you invoke the
.exe, switch displays:

$ ! command for to execute foo.exe
$
$	set display/screen= (the other one, in this case 0)
$
$	run foo.exe
$	exit

this will then display the application on either the color(0) or b/w(1) monitor.

that's it, it's that simple.  What you were trying to do with the returned values from
XtInitialize and/or XOpenDisplay is violently illegal.

						.dave.

    
    
    
    I did a help set display on my 5.3-1 system (same as customer's
    version), and there was no /screen  qualifier, there was /screen
    qualifier in the 5.4 VMS, but the help file indicates: "currently
    the screen number value must be zero".
    
    Can someone please clarify the above before I talk to the customer.
    Thanks.
    
    -Dave

I memory serves (where did I hear that before?) Dual headed configurations where not
officially supported until v5.3-2.  But that didn't stop it from working.

For that matter, even the v5.4 help says that it must be 0...

						.dave.

Perhaps Burns, Jackie, or Jake could give some 'official' statement?

This is as official a statement as I ever make:

It works in VMS V5.4.  If help implies otherwise, help is wrong.

2-head support started in (I think) V5.3 or so, but the cable was not available,
so it was not very much of a deal.  SET DISP/SCREEN has always worked, although
has not been supported till V5.3 or whatever.

After the SET DISP, if you still have problems you will need to check the code.
We found frequently that people would explicitly code screen 0 rather than
DefaultScreenOfMumble.  Other than that, there should be no problem.

Burns

	Yes, set display/screen=n  worked fine with V5.3-1; so the customer
is happy to set display to the desired screen before running his application.
We came across another problem when his application also open a DECterm
window with the decterm_port routine, and he want this decterm window
to be on a different screen from his application;  after much mucking
about (due to poor documentation), we managed to pass the screen number
via the first argument to the routine, and now the windows go to their
correct screen!

	To round up this discussion, is there a lexical function to find
out what the screen number the current display is direct to? if not, other
than extracting the screen information from show display, any other way?

	Thanks...
	dave
                              

Albion> set display/nod=mulp/screen=1/cre
Albion> sho display/sym

    Device:    WSA1:  [super]
    Node:      MULP
    Transport: DECNET
    Server:    0
    Screen:    1

Albion> sho sym/gl/all
...

  DECW$DISPLAY_NODE == "MULP"
  DECW$DISPLAY_SCREEN == "1"
  DECW$DISPLAY_SERVER == "0"
  DECW$DISPLAY_TRANSPORT == "DECNET"
...