[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

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

1230.0. "Can't save session background pattern across sessions" by ILLUSN::SORNSON (Are all your pets called 'Eric'?) Thu Aug 03 1989 16:46

    The problem I'm having is that I can't seem to save the screen
    background pattern that I choose from the "Customize Window" menu
    associated with the Session Manager window.
    
    For a particular session, my choice of background pattern will remain
    in effect, but if I quit the session and log back in, I get a pattern
    that I didn't choose, even though I previously invoked "Save Current
    Settings."
    
    I've noticed that when I "Save Current Settings", the files
    DECW$SM_COLOR.DAT and DECW$SM_GENERAL.DAT get written to SYS$LOGIN.
    It appears that DECW$SM_COLOR.DAT records the pattern I've chosen (as
    sm.display_pattern), while DECW$SM_GENERAL.DAT writes a fixed value
    (21) for this attribute.
    
    My system is a color GPX (VAXstation II) and is a satellite on a
    cluster running VMS 5.2.  What's even stranger (to me) is that no one
    else on the cluster is having this problem.
    
    Any ideas as to what's wrong would be greatly appreciated.
    
    								-mark.
T.RTitleUserPersonal
Name		DateLines
1230.1MU::PORTERmoderation is for monksThu Aug 03 1989 17:4815
    My impression is that if you ever get a bad resource line in
    some .DAT file, it'll usually stay there forever.  I expect the
    application logic goes: read the whole file and store it
    in some internal format; modify particular entries; when told,
    rewrite whole internal database to file.
    
    On my system (VS3200) I don't have an 'sm.display_pattern' in
    DECW$SM_GENERAL.DAT.  Therefore, I hypothesize that somehow
    you picked up this bogus value, which is now masking
    the real value.  Just edit it away and you should be ok.
    
    Caveat: I am not a DECwindows expert, although I play
    one in notesfiles.
1230.2Yes, delete the resource from decw$sm_generalSTAR::BROUILLETTEFri Aug 04 1989 17:3812
    
    The session manager used to store background pattern in the
    decw$sm_general.dat file.    Sometime before V1 (I think) the resource
    was moved to the color file.    There aren't any easy ways using X to
    delete resources from a resource file.
    
    .1 is correct.   Delete the resource from decw$sm_general.dat
    The color file is read in first, and then the general file is read in
    and merged with the color file.   So, the old value in the general file
    is overriding the one being stored in the color file.
1230.3AITG::DERAMODaniel V. {AITG,ZFC}:: D'EramoFri Aug 04 1989 20:019
>>    The color file is read in first, and then the general file is read in
>>    and merged with the color file.   So, the old value in the general file
>>    is overriding the one being stored in the color file.

	Why were things set up to have the more general settings
	override the specific ones?

	Dan
1230.4The order doesn't always matterHANNAH::MESSENGERBob MessengerSat Aug 05 1989 14:5712
One thing to remember is that when you're merging two resource files, the
resource specified in the second file doesn't always over-ride the resource
specified in the first file.  The rules are given on pages 326 to 327 of
"X Window System" by Scheifler, Gettys and Newman (the maroon book).  Among
other things, a fully specified resource takes precedence over a resource
that includes wild cards, regardless of which resource is applied first.
Even the session manager read decw$sm_general.dat before decw$sm_color.dat,
there could be a fully specified resource definition in decw$sm_general.dat
that would over-ride the definition in decw$sm_color.dat.

				-- Bob