Re: Customization of SQL*Forms.

+------------+
| STOP PRESS | YOUR INP FILES ARE NOT GOING AWAY IN FORMS4!!

+------------+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

   We will offer a human readable (say, "human revisable") version    of the form definition just like we did in Forms 2.0, 2.3, and    3.0. We will provide forwards/backwards conversion between the    ASCII form definition and the portable, compressed, binary form    definition which Forms4 will generate/read by default.

   We will provide an upgrade utility to read Forms 2.0, 2.3, or 3.0    form definitions ("INP files") and write out upgraded form    definitions in the new format. This will, in fact, *be* the    required conversion step to upgrade an existing application to    Forms4.

   The ASCII version of the form definition may likely have a    different format than the Forms 3.0 INP file, but the information    contained within will be virtually identical. The ASCII version can    be used in your existing change/version-control systems, can be used    to easily identify differences between versions using standard    operating system utilities, can be used to perform global    search/replace, and (albeit still officially unsupported) to make    modifications.

   We do not make changes in format of this type without good    reason, you can be sure. This modification allows Forms4 to    leverage work done within the Oracle Tools and Multimedia    Products Group to support a common document reading and writing    mechanism for all of the new Oracle Tools, known internally as    the "Resource Object Store" (or ROS for short).

   We know very well how designers work with form definitions from    within their favorite editor, and while there will be no method    from within the Forms4 Designer to make global text substitutions    on an *ENTIRE* form definition at once -- changing PART_ID to    PART_NUMBER in every SELECT statement for example -- we have made    a conscious effort to allow the Forms4 designer to escape to    his/her favorite system editor wherever multi-line text input is    expected in the Designer interface.

   The editing of INP files will continue to be unsupported because    in general, a lot of damage can be done to your form definition    by careless editing. Anyone who edits INP files *now* can    understand this official position. But we will leave the option    open for the knowledgeable, careful, advanced developer to    manipulate the ASCII version of the form definition in whatever    manner he/she sees fit.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _   Steve Muench Email: smuench_at_oracle.com   SQL*Forms Development
  Product Manager Received on Thu Sep 03 1992 - 10:24:09 CEST