Below is a list of known problems and restrictions in the OpenLook versions of 
SQL*Forms 3.0, SQL*Menu 5.0, and Orakit as of 6/17/91.

------------------------------------------------------------------------------
  Sun specific notes
------------------------------------------------------------------------------

- There is a file, ".xmodmaprc", that is moved to $ORACLE_HOME by the install
  script.  This file enables  "Meta_L", "Meta_R", and "Alt_L" (Meta left,
  Meta right, and Alt left keys, respectively).  It is put into
  use by typing "xmodmap .xmodmaprc" in $ORACLE_HOME.  It is recommended that
  ".xmodmaprc" be put in each user's home directory and the command 
  "xmodmap .xmodmaprc" be put in each user's .login, .profile, or .cshrc file.

  - Font Sizes, Types, and Geometry Management:

  Font sizes (set in OlOrakit and oloraterm.r files) should not exceed 12 
  point.  This is because SQL*Forms V3.0 and SQL*Menu V5.0 does not scale 
  its objects to the font used.  Fonts larger than 12 point will cause text 
  to disappear in text fields and other unpredictable results.

  Font types should also be chosen carefully.  The Normal attribute (both in
  oloraterm.r and OlOrakit) should be left as it is, a fixed length font.  
  SQL*Forms V3.0 and SQL*Menu V5.0 scales everything off of this font.  Using
  a proportional space font will cause problems such as abnormally large 
  windows and non-aligned text.  SQL*Forms V3.0 and SQL*Menu V5.0 assumes 
  fixed width fonts and calculates positions, sizes, locations based on that
  assumption.  Because we are using OLIT widgets, which do their own 
  geometry management, we are able to use proportional spaced fonts in many
  places, but the restrictions outlined here still remain.

   - Mouseless Support/Widget Traversal:

   OpenLook's Mouseless Support/Widget Traversal was designed to allow 
   users to move through widgets and select them with only the keyboard.
   However, at this stage of OpenLook (version 2.5), it is still immature
   and buggy.  Please carefully read the ERRATA file contained in this 
   directory for a list of problems you will encounter.  The following is 
   a list of variances from the OpenLook's Mouseless Support/Widget Traversal
   that were made so that the user would not be confused and that SQL*Forms
   V3.0 and SQL*Menu V5.0 would function correctly and as users of these
   products are used to.

     - The 'tab' key is used for the 'next field function' in SQL*Forms 3.0 and
     SQL*Menu 5.0.  The tab key is normally used to move from widget to widget
     in OpenLook applications.  Where necessary, the widget to widget traversal
     has been disabled, so as not to confuse the user.  Where possible, it 
     has been left intact for the user's convenience.

     - Mouseless support has been turned off in the top menu bars.  The 'tab'
     key, which is the 'next field' function in SQL*Forms, is overridden by 
     OpenLook's mouseless support and if enabled in the top menus, would cause
     the focus to leave the text fields and go up to the top menu.  Thus the 
     user would have to tab forward through all the top menu items to return
     to the screen text fields.  

     - Disabling the mouseless support has the side effect of not being able
     to pop down a menu from the keyboard.  Normally, a user would be able 
     to tab through the widgets until the focus widget (seen in red) would 
     move to a top menu button.  Then the user could pull down the in-focus 
     top menu by pressing "Alt-Spacebar".

     ** This can be turned on again by removing the following 2 lines in the 
	OlOrakit file:
	
	OlOrakit*topmenu*traversalManager:  False
	OlOrakit*topmenu*traversalOn:       False

     *** CAUTION!! Do so with extreme care because now the next field function
         of SQL*Forms will not function as it was meant to!!!!

    - At times, when using mouseless support, the focus may seem to disappear
      for a couple of 'tab' keypresses.  This is because the focus is 
      moving through some "invisible" widgets.

    - In modal dialog boxes, such as the FILE/OPEN window, the user must use
      the "Shift-tab" key to move the focus to the OK and CANCEL buttons.
      This is because, in this case, the 'next field' (tab) is interpreted 
      as an "accept".


  -  The Open Look Clipboard

     SQL*Forms and SQL*Menu designer - The user can use the clipboard to 
     to cut and paste to and from shelltool/commandtool windows amd the 
     designer.  Selecting text and then dragging it with the mouse
     does not work.  Both the clipboard and dragging selected text works 
     within the designer.  An "Edit" top menu item that functions just like
     the Clipboard within SQL*Forms and SQL*Menu is provided.

     Runform - Because Forms must process the data within its fields for
     validation purposes, and must trap events so that triggers may be fired,
     neither the Clipboard nor dragging selected text works. However, an 
     "Edit" top menu item that functions just like the Clipboard within 
     SQL*Forms and SQL*Menu is provided. 


  - There is no National Language support in the version of the OPEN LOOK
    INTERFACE TOOLKIT (OLIT) contained in this release.

-----------------------------------------------------------------------------
  Minor problems and restrictions:
-----------------------------------------------------------------------------

- The "Show Keys" window is no longer a modal window, as in previous versions.
  It now can be brought up and left showing for easy access.  It is also 
  context sensitive, meaning functions that are not enabled in the context of
  what you are doing, are greyed out (but still visible).  This is still not
  done dynamically, however.  So when the user switches contexts, for 
  example, calling the "Trigger Definition" window from the "Screen Painter" 
  window, he or she will have to press Ctrl-K to update the window.  The 
  context sensitivity is also sometimes not correct.  For instance, after
  hitting Ctrl-K in the Field->Modify window, Zoom Out is not highlighted in
  the Show Keys window, although the function key works.

- When a modal window pops up, navigation in the help system is disabled, e.g.
  when both the Help System and New Menu Application windows are on the screen,
  the scroll bars and buttons in the Help System window do not function.

  Workaround:  Dismiss the modal window before using the Help System.

- When a modal window is invoked from another modal window, navigation in 
  second modal window is disabled.  If you invoke Show Keys in the Menu 
  Admin -> Security window, the scroll bars and buttons in the Show Keys 
  window will not function.

  Workaround:  Dismiss the Grant Role window before using the Show Keys
  	       window, or dismiss the Show Keys window before bringing up the
	       Grant Role window.

- In SQL*Forms Designer, the form (as opposed to the spread table) version of
  the Field/Modify window, the "List of Values SQL Text" window is a 
  multiline text edit widget.  For any multi-line text edit widgets like 
  this one, the up and down arrow keys are taken from the widget by 
  SQL*Forms and used for "Previous record" and "Next record".  The user must 
  use either the mouse or the "Scoll Up" and "Scroll Down" keys to navigate
  vertically in that window.

- The <List> message does not appear at the bottom right of the main window
  in SQL*Forms Designer when the File/Open option is chosen, even though 
  the ListValues key functions properly.

- In the Screen painter of SQL*Forms Designer, during a cut and paste 
  operation, the screen is not updated if the operation is undone or aborted.
  If you place at least one of your select points on the edge of a field box
  and then press the undo key, the select marks will go away, but a hole is 
  left where the select point used to be.

  Workaround:  Scroll this point out of view and then back into view.  We 
  	       recommend not placing your select points on existing text or 
               objects.

- When creating a form using default blocks, the field lengths displayed in
  Runform do not match the display lengths specified in SQL*Forms Designer.
  For example, a default form based on the emp table has Sal specified as a
  9-digit field in SQL*Forms Designer.  However, when you execute the form,
  you can enter more than 9 numbers in the Sal field, but when you tab to the
  next field, the number you entered is erased.

- If you pull down menu items, and go down each item slowly with the cursor, 
  an item may appear selected even after being passed over.  This is due to a
  bug in the OpenLook MenuButton widget.  It has no effect except its 
  appearance.

- In SQL*Forms Designer, the X label in the Field->Modify, Editor Attributes
  window is too far away from its corresponding field.  This is because, as 
  explained in the README file, in the Notes section, SQL*Forms V3.0 and 
  SQL*Menu V5.0 assumes fixed width fonts and calculates positions, sizes,
  locations based on that assumption.  Since we are using a proportional 
  spaced font (in a static text widget), the width is far less than a fixed
  width font would be.

- Long form/block names overwrite block/field labels in main SQL*Forms Designer
  window.  For example, if you enter ThisIsAVeryLongFormName in the File->New
  window, and click OK, the new form name overwrites the Blk: label in the
  SQL*Forms window.

- Trigger Style column in the Designer in the Code/Trigger spread table window
  shows only one character ("V").  It should be wide enough to show both 
  characters (either "V3" or "V2").  To see the second character, hit the right
  arrow key twice or toggle to the "form" view of the current row.

-----------------------------------------------------------------------------
  Items deferred to the next release:
-----------------------------------------------------------------------------

- [Possibly] Allow Show Keys window to be dismissed by hitting the Cancel 
  or Exit key as well as unpinning the window. 

