home *** CD-ROM | disk | FTP | other *** search
/ Liren Large Software Subsidy 9 / 09.iso / l / l015 / 1.ddi / UPGRADE.DOC < prev   
Encoding:
Text File  |  1991-03-01  |  10.8 KB  |  253 lines
  1.                        C-Worthy Version 2.0 Upgrade Notes
  2.                               [February 21, 1991]
  3.  
  4. This file contains information on how to upgrade programs created for C-Worthy
  5. version 1.0, 1.1, or 1.2 to version 2.0.
  6.  
  7. It also contains information about new features and changes in old features.
  8.  
  9. Major Features and Enhancements
  10.  
  11.    Resource Management
  12.  
  13.    All application resources other than help are now stored in a single
  14.    resource file.  This file contains forms, menus, strings, and color
  15.    palettes.  All of these resources are managed interactively by cwArchitect.
  16.  
  17.    Enhanced menu API
  18.  
  19.    All menu types are now supported by a single menu API.
  20.  
  21.    Graphics mode support
  22.  
  23.    C-Worthy now works in graphics modes as well as text mode.  PCX files may be
  24.    displayed in a C-Worthy window.
  25.  
  26.    Menu building in cwArchitect
  27.  
  28.    cwArchitect now allows you to build menus as well as forms.  Menu choices
  29.    may optionally invoke other menus or forms.
  30.  
  31.    Palette handling in cwArchitect
  32.  
  33.    cwArchitect now allows you to modify your application's palettes
  34.    interactively.  You see the results of your changes immediately - without
  35.    compiling and linking.
  36.  
  37.    Message handling in cwArchitect
  38.  
  39.    Application messages are now handled within cwArchitect.
  40.  
  41. Converting source code to version 2.0
  42.  
  43. SCONVERT is a tool that helps convert source code from earlier versions of
  44. C-Worthy to version 2.0.  It translates C-Worthy identifiers from the old
  45. C-Worthy naming convention to the new object-action convention.  Where the
  46. translation cannot be made (because a routine is obsolete, or because
  47. parameters have changed), SCONVERT inserts a comment above the line in
  48. question.  The comment is tagged with [CW] to make searching for the comments
  49. easier.  Where you find such a comment, you must make changes to your source
  50. code before it will work with version 2.0.
  51.  
  52. The syntax for sconvert is
  53.  
  54.      SCONVERT input_filespec output_filespec
  55.  
  56. The filespecs may optionally contain wildcards.  The output filespec must be
  57. different from the input filespec; failure to heed this will cause destruction
  58. of your source code.
  59.  
  60. The following notes and restrictions apply:
  61.  
  62. *    SCONVERT.DAT must reside in the directory from which you invoke SCONVERT.
  63.  
  64. *    If you wish to use wildcards, you must give a full path specification.
  65.      For example,
  66.  
  67.           SCONVERT d:\source\*.c e:\source\*.c2
  68.  
  69. *    File extensions are required, and may not contain wildcards.
  70.  
  71. *    If no path is specified for the output file(s), they will be created in
  72.      the source directory (not the current directory).
  73.  
  74. Converting Form and Message files to version 2.0
  75.  
  76. FCONVERT is a utility to convert .FRM library files created with cwArchitect
  77. version 1.2 to the format expected by cwArchitect version 2.0.
  78.  
  79. Usage is:  FCONVERT <old .FRM filename> <old .MLC filename>
  80.  
  81. For example, if your application's forms are in FOO.FRM and your application's
  82. messages are in FOO_MSG.MLC, use the command line
  83.  
  84.      FCONVERT FOO FOO_MSG
  85.  
  86. Don't specify any file extensions.
  87.  
  88. Both the .MLC and the .MLH file for the specified message name must be in the
  89. current directory.  In addition, the system message files SYS$MSG.DTA and
  90. SYS$MSG.MLH must be in the current directory.
  91.  
  92. FCONVERT creates a new, 2.0-compatible .FRM file with the same name as your old
  93. file.  The old file is left intact with the extension BK1.
  94.  
  95. FCONVERT performs nine functions:
  96.  
  97. 1)   Application specific messages are extracted from the message file
  98.      specified and stored within the new FRM.
  99.  
  100. 2)   System messages are extracted from "SYS$MSG.DTA" and "SYS$MSG.MLH" (in the
  101.      current directory) and stored within the new FRM.
  102.  
  103. 3)   A default color table is stored within the new .FRM.
  104.  
  105. 4)   Menu and matrix fields are converted.  In version 1.2 these fields were
  106.      stored as MENU_DATA and MATRIX_DATA respectively.  In version 2.0 both
  107.      these fields now simply contain the menu name of the menu which is
  108.      attached to the field and which is stored within the Menu system.
  109.      FCONVERT must create these menus from the data stored within the
  110.      datafield.  It will use the field's name to name the created menu.
  111.  
  112. 5)   In version 1.2, the <Insert> key was used to invoke field specific insert
  113.      procedures.  In version 2.0, <Grey Plus> is used instead since the
  114.      <Insert> will now toggle insert\overstrike mode.  Button fields to which
  115.      the value I_INSERT had been attached are replaced with I_EXPAND.
  116.  
  117. 6)   A border member has been added to list fields.  FCONVERT sets this to be
  118.      double line.
  119.  
  120. 7)   Forms now contain an entry and an exit procedure.  These are initialized
  121.      to NO_PROCEDURE.  The border type has become border flags.
  122.  
  123. 8)   The format of storage for user specified procedures has been changed.
  124.  
  125. 9)   A preferences structure containing the C-Worthy default application
  126.      preferences is created and stored in the new file.
  127.  
  128. Note:
  129. With the addition of the menu building capabilities of CWA, the internals of
  130. menu and matrix fields have been reworked.  One of FCONVERT's tasks is to map
  131. old menu and matrix fields to be CWA 2.0 menus, this requires that the menu to
  132. be created have a name. FCONVERT uses the field name as the menu's name.  If
  133. your existing library has more than one menu field using the same name,
  134. FCONVERT assumes that it should generate only one "new" MENU and that both
  135. fields ought to use it.  It will generate a warning with regards to menu name
  136. collisions and continue processing. If this is not the desired action you may
  137. either rename the offending fields or break the original library file into
  138. smaller components, convert the components, and re-import into a large library.
  139.  
  140.  
  141. Forms
  142.  
  143. Form Entry Procedures
  144. Forms now have entry procedures as well as exit procedures giving the program
  145. another hook into the application when using form_edit(). The entry procedure
  146. is called after the form window has been created but before the fields have
  147. been displayed and before the form is re-edited after calling the exit
  148. procedure.
  149.  
  150. The calling parameters are:
  151.      entry_proc(FORM *form, int control_code, va_list arg_list);
  152.  
  153. FORM *form       :   form pointer passed to form_edit
  154.  
  155. int control_code :   the first time the entry procedure is called this
  156.                      will be set to CONTINUE_EDIT. On any additional
  157.                      calls it will contain the value returned by
  158.                      form_window_edit() or the exit_procedure.
  159.  
  160. va_list arg_list :   any optional parameters passed to edit_form()
  161.  
  162.    Sub-Form Field Status Values
  163.  
  164.    The interaction between sub-forms and the sub-form field type has been
  165.    modified as follows:
  166.  
  167.    if the sub-form was CHANGED and not CANCELED then the sub-form field's
  168.    status will have FS_CHANGED | FS_ANSWERED bits set.
  169.  
  170.    Action Procedures
  171.  
  172.    Menu exit procedures are called whenever a valid exit event occurs. In a
  173.    Windows Style Menu with sub_menus each sub-menu can have its own action
  174.    procedure as can the main horizontal menu.
  175.  
  176.    If the current object is a menu and it has an action procedure then that
  177.    menu's action procedure is called and is passed the current_node from the
  178.    current menu. If the current object is not a menu then the main horizontal
  179.    menu is called, if present, with the current node from the main horizontal
  180.    menu.
  181.  
  182.    If the current object is a sub-menu but does not have an action procedure
  183.    then the main horizontal menu's action procedure is called and is passed the
  184.    node that was current on the pull-down menu.
  185.  
  186.    If no action procedures are present menu returns the exit event and the
  187.    current_node member of the menu structure contains whatever node was present
  188.    at whatever level you exited from.
  189.  
  190.    MC_COMPLETE_EXIT
  191.  
  192.    If this flag is set the selector will exit all levels of sub-menus retaining
  193.    the current_node. Menu will return the exit_event and the current_node
  194.    member of the menu structure will contain whatever node was current when the
  195.    exit event occurred.
  196.  
  197.    Accessing field specific information
  198.  
  199.    Previous versions of cwArchitect allowed access of field specific
  200.    information as a separate menu option under the field category.  Field
  201.    specific information is accessed from the Field Info form.  This form has a
  202.    new field called Field Specific which contains a subform allowing access to
  203.    the field's specific data.  An exception is made in the case of graphics
  204.    fields, upon selection of Field Info on a graphic field the user will be
  205.    placed within the graphic editor (see below).
  206.  
  207.    cwArchitect Background editor
  208.  
  209.    The graphic editor is now accessed by choosing Field Info from cwArchitect's
  210.    menu.  Functionally the editor remains the same, options have been renamed
  211.    and moved.  Additionally, we intend to refer to this field type as a
  212.    background field and the editor as the background editor.
  213.  
  214.    Flag marking within cwArchitect
  215.  
  216.    In all previous versions of cwArchitect fields requiring bit settings have
  217.    been controlled by list fields on which <Enter> would toggle the current bit
  218.    setting and <Escape> was used to exit the list.  With the introduction of
  219.    this beta, the <Space Bar> will be used to toggle bit setting and either the
  220.    <Escape> or the <Enter> keys will exit list editing.
  221.  
  222.    Removal of the F2 action buttons
  223.  
  224.    In all prior versions of cwArchitect actions generated from a form were
  225.    performed by pressing <F2>, <Escape> or <F7> could be used to cancel the
  226.    action.  Starting with this version of cwArchitect, operation will be
  227.    performed if the form is left via <Enter> and canceled if the form is exited
  228.    via <Escape>.
  229.  
  230.    Window flags
  231.  
  232.    We have added several window flags to allow greater control of the display
  233.    of your windows.
  234.  
  235.       WF_NO_BORDER            /* no border_flags around window */
  236.       WF_SINGLE               /* single line forms border_flags */
  237.       WF_DOUBLE               /* double line forms border_flags */
  238.       WF_SHADOW               /* use a shadow */
  239.       WF_FORCE_SHADOW         /* shadow on regardless of _cw_global.shadow */
  240.       WF_FORCE_NOSHADOW       /* shadow off regardless of
  241.                                * _cw_global.shadow
  242.                                */
  243.       WF_MOVEABLE             /* window is moveable */
  244.       WF_SIZEABLE             /* window is resizeable */
  245.       WF_FORCE_MOVABLE        /* always moveable */
  246.       WF_FORCE_UNMOVABLE      /* never moveable */
  247.       WF_FORCE_SIZABLE        /* always sizeable */
  248.       WF_FORCE_UNSIZABLE      /* never sizeable */
  249.       WF_HEADER_LEFT          /* left justify header */
  250.       WF_HEADER_RIGHT         /* right justify header */
  251.       WF_HEADER_BORDER        /* 1st line of header text starts
  252.                                * within the top border_flags */
  253.