SOME WORKBENCH 2.0 HINTS  

					 by Chris Hussey


   Ed: Please send in any hints you have, including WB2 stuff, since it's now
  finally released in kit form, and people will be wondering how to make it
  dance.


   (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 ))



   IPREFS and ENVARC:

   Version 2.0 allows changing of some system parameters not possible under
  1.3, for example window background patterns.  The nature of these
  particular changes seems to require writing to the same area used by the
  'Use' function of Preferences; therefore to enable Preferences 'Use' for
  these parameters, the changes must be stored in some sort of 'hard copy'
  form.  This may be achieved by saving 'Use' preferences to disk, flushing
  out the old changes and then reading from disk the new parameters required,
  but this is not so desirable.  This is more or less the function of
  IPrefs, which looks for changes in files in the ENV: system directory.
  The files in question are generated by Preferences 'Use' selections.  Since
  the above mentioned 'flush' leaves alone actual files in RAM:, with
  suitable 'assign's IPrefs can be made to look in RAM: for the required
  files, far better than writing to a disk for what are only temporary or
  test situations anyway.

   The lines in the startup-sequence which do the trick are those which copy
  the 'saved' preferences from their 'permanent store' (ENVARC:, defaulting
  to Preferences/Env-Archive) to RAM:ENV (after creating that directory) and
  then assign ENV: to RAM:ENV.

   Using 1.3's System-Configuration File

   You can use the old 1.3 Preferences to generate a
  devs/system-configuration file and use it under 2.0, just like before; you
  just won't have access to those setting changes exclusive to 2.0.  And you
  could transfer those 1.3 settings across disks as before just by copying
  the system.configuration file, and even delete the lines from the
  startup-sequence referring to ENV:, etc as above and the entire ENVARC:
  directory.  Useful if floppy space is REALLY at a premium.

   Alternatively, if you wish to take a middle road and use settings
  available only under 2.0 Preferences but still find disk space a problem,
  you can compromise by retaining the ENVARC: directory and its files, amend
  the startup-sequence by assigning ENV: to sys:devs/env-arc.  You can then
  copy the entire env-arc drawer instead of just the system-configuration
  file to transfer your system preferences, requiring a bit more disk space
  but allowing deletion of at least c:makedir and copy from an original 2.0
  disk (and presumeably the entire Prefs directory, since you are trying to
  minimise disc space).



No-CLI Startups with 'Setmap'

   As Nic Wilson indicates, a 2.0 startup is significantly quicker if it
  doesn't generate a CLI at all.  Note, though, that including a 'SetMap'
  command as part of the startup will generate a CLI even though there is no
  obvious output, and even directing 'SetMap > NIL:' is not enough.  Go the
  whole hog and try 'Run >NIL: <NIL: SetMap >NIL: <NIL: ...'.  This is what
  some of the old 'Runback' commands used to do, and works just as well with
  2.0; and since 'Run' is an internal command, there is little time lost from
  accessing it.

   (The disk must have a v2.0 bootblock as well, since a v1.3 bootblock will
  generate a CLI window as soon as it is read, regardless of startup-sequence
  fiddling.  One of the uses of a 2.0 bootblock ... see 'Bootblocks' below.)



2.0 'Read/Write error's

   If you get persistent 'Read/Write error - block 880' (or similar number)
  while doing a large number of file copies, try copying first to RAM: or
  similar virtual disk then onto the destination disk.  Reason for original
  problem (or this solution working) unknown; maybe a system bug?



Bootblocks

   Note that there exist two cross-categories of bootblocks.  File system
  (FastFileSystem or OldFileSystem, determined by 'Format') and operating
  system version (1.2/1.3 or 2.0, determined by 'Install').  Some differences
  and effects are known, but some of them just seem to be changes recognised
  by the system with no obvious associated effects.



LEFT-OUT ICONS


   Having occasional trouble with 'Left Out' icons that won't stay where you
  snapshot them after a reboot?  Does the problem appear to be associated
  with one (or more) icons with names wider than the graphical part?

   Maybe the problem occurs because they ARE left out, and treated rather
  like disk icons instead of 'normal' icons in a 'normal' window.  When the
  machine is booted and the backdrop file is read, the system may try and
  place the left-out icons like it would disk icons, and therefore not
  allowed to overlap; if they have been snapshotted too close together, at
  least one of the icons will be shifted to the default positions at the left
  of the screen.  And since the system allows for the widest part of the
  'total' icon (ie. including the name), it is easy to get icons too close
  together in this situation.

   The answer is obvious; move the icons further apart horizontally.  To get
  an idea of how far apart to put them, try copying (just) the icons to
  another blank window (for example, an empty RAM: disk).  Make the window
  too shallow to stack icons on top of one another, but well and truly wide
  enough to fit them in horizontally.  Then ask the system to 'Clean Up' the
  window.  Note how far apart it puts the icons - this is about as close as
  the system will allow them.  Allow this distance plus a few more pixels,
  five or so, between the recalcitrant icons, and the problem goes away.





   (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 )) (( 27 ))