Release Notes Addendum for InfoMaker [TM] Version 6.0. (c) 1991-1998
Sybase, Inc. and its subsidiaries. All rights reserved.

Updated March 2, 1998
=====================

This is a listing of some of the improvements to the InfoMaker 6.0
development and runtime environment. Not all this information is in the
on-line or printed documentation. We were unable to get this into the
release notes at the time the CD's were cut.

Things like deployed executable query governor, print dialog for
reports, deployment of pipelines, better dialogs and many improvements
to ease of use for forms were some of the changes. The executable is
also now more professional looking.

Stephen Dupre
Product Support Engineering

Changes to existing behavior
============================

Printing
========
1. Runtime executable print dialog for reports now allows specification
of pages, number of copies, etc similar to the development environment.
Freeform and Grid forms also have this support. InfoMaker 5.0 did not
have this feature and you had to print the entire report.

2. One-to-Many printing now prints all master rows in one print job and
all rows of the detail related to the visible master row in another
print job - the same as 5.0. It should just print one master row with
all the detail rows associated with the master ON ONE PRINT JOB. This
might be considered for a maintenance release.
NOTE: This is a deficiency that has not been fixed in 6.0 Gold. For
forms in 6.0, users can use the Filter_master action and the expression
currentrow() = getrow() to filter the master down to one row before
printing or use "Specify Criteria" and "=<value>" in the appropriate
master column to show only ONE master row.

3. Freeform, One-to-Many and Many-to-one also print a blank page after
each row from the freeform part of the form (the master in most cases)
due to the internal size of the bands being larger than a page height.
This has been fixed in 5.0.04 and 6.0.00 Users must re-save their forms
using the new version(s) to pick up the change. Migration of 5.0 forms
alone won't fix it. New 6.0 forms will be created correctly.

Forms changes
=============

1. When users make changes to one-to-many forms and clicked on the
Retrieve icon on the toolbar, the logic now correctly refreshes the
entire form for the one-to-many style without performing an update. In
4.0 and 5.0, the update was performed unconditionally before the
re-retrieval - very bad behavior. The new behavior in 6.0 now asked
the question "Do you want to save changes before re-retrieve?" if the
user has made changes, inserts or deletes to the form.

2. If a particular 12many or many21 form has one or more sections that
are not updateable, the INSERT, DELETE and UPDATE icons on the toolbar
and the menus (if applicable) will be disabled. (5.0 had them always
enabled) Prevents users from accidentally getting "Cannot insert due to
required fields missing" type of errors. In 5.0, although the form were
read-only when not updateable, the user could still insert and delete
rows and click on the update icon. This has been fixed in both
one-to-many and many-to-one.

3. One-to-many and many-to-one forms now correctly insert the primary
key(s) into the detail part of the form automatically when an insert is
performed on the detail. Users migrating 5.0 forms should re-confirm
they have a correct mapping by using the "Select Master/Detail
relationship" dialog in order for this to work correctly. 5.0 did not
have this functionality.

4. One-to-many forms. In Infomaker 5.0, when focus is on the master
datawindow and the user clicks delete, the master row and all associated
rows were immediately deleted. We now query the user...'Do you want to
delete ALL detail rows...?". The user now has control over this.

5. One-to-many forms. If the master row has no detail rows and focus
is on master, in the past a new row was inserted in both the master and
detail. Users could never insert (for example) new employees into a
department that currently had no employees. The user will now get
prompted "No rows in detail, would you like to insert some records?".
If the user answers "yes" insert and focus will be directed toward the
detail. If the user answers "no", the original behavior will occur.
There is also a Cancel "no action" button.

6. One-to-many and many-to-one. Actions didn't always work the same
way from a command button as from the menu. Good example were
inserts. 6.0 fixes this behavior and you will now get the same
behavior on both the toolbar and command button for a particular action.

7. One-to-many form. When in Specify Criteria mode and the user
inadvertently uses a query that returns 0 master rows (dept_id >
1000000), the user was stuck in a mode where no other data could be
returned and had to exit the form. This was because the WHERE clause
was permanently modified at this point to the criteria (dept_id >
1000000) that would not return rows. Eventually, users would get errors
on re-retrieve, insert or update if they chose these from the toolbar or
a command button. The fixes separate Specify/Apply Criteria from
Insert. The old behavior was to insert a row - presumably for input -
if the query returned no rows. Now the user gets control back still in
Specify Criteria mode.

8. File/Exit and File/Close menu items were added to all form styles.
Due to architectural limitations, in the development environment, we
don’t expose these menu picks. This makes a more professional looking
executable.

9. All form styles. Vertical and horizontal scrollbars have been
enabled as a customer requested enhancement. This has the behavior of
scrolling the entire form EXCEPT for buttons used for actions. If you
have columns or static text beyond the initial form height,in 6.0 you
will now be able to scroll to them but the buttons will stay in the same
place. This is a small known deficiency.

Executable Creation
===============
There are many changes in the executable creation.

1. dropdowndatawindows are automatically copied to the executable if
used in a report that’s selected in the environment painter. They are
also automatically hidden from the Objects menu and the report dialog
(if any). The user had remember to select these in the past while
building the executable. This is not true for forms. Users must
select the appropriate dropdowndatawindow edit styles used in forms when
including forms in the executable. This is a known deficiency in
forms.
NOTE: Anytime you have a dropdowndatawindow column editstyle with an
arrow that doesn’t "drop", it’s because the edit style
dropdowndatawindow "report" object is not in the InfoMaker 6.0 PBL and
was not copied into the executable.

2. See Infomaker documentation for information on the Executable Items
dialog of the environment painter. There were many changes to this
dialog including the ability to Deploy Pipelines and to hide nested
reports and datawindows for use as edit styles. In 4.0 and 5.0, all
reports would be shown to the user - including dropdowndatawindows and
nested reports - reports that should not be ‘seen’ or run individually.
The new "hide report" option allows you the ability to hide these in
your runtime executable.

3. 6.0 Feature. The environment painter now correctly detects all the
object types selected for deployment. The user will only see toolbar
items ( Open Forms/Open Pipelines ) menu picks in the deployed
executable related to the object types selected. Example: An
executable with only reports will show only an Open Reports menu pick
and toolbar icon in the executable. This prevents confusion as in the
past, where, in 4.0 and 5.0, the end user would see an "Open Forms"
icon, click on it and see an empty dialog (no forms) if no forms were
deployed.

Enhancements to Infomaker for 6.0
=================================
1. For project libraries with PBLs with a large number of objects, the
200 object limit for the environment painter has been eliminated.
(5.0.04 is fixed too)

2. The MDI frame for the deployed executable now has a toolbar dialog
to allow the user to adjust the settings of their toolbar (left, right,
top, bottom, floating). This was not available in 4.0 or 5.0 and the
user could lose the frame toolbar at times without the ability to get it
back by using the rightmouse and hiding the toolbar. Saved settings is
not supported yet.

3. File/Close and File/Exit menus were added to all forms for a more
professional looking executable. In 4.0 and 5.0, users saw File/Print
and File/Print Setup only.

4. The Help/About now has provisions for the following:
Developer name
Company logo
Developer Phone number
Developer Email address
Developer web site address (url)

This allows for a more professional looking final executable. See the
documentation for how to access these new features.

6. Query Governor in the runtime executable. This was originally
available in the development environment only. Same features as
development - by time or by # of rows.

7. Rows Retrieved indicator added to microhelp in deployed executable
for reports. This mirrors the development environment behavior. In
4.0 and 5.0, when the red hand shows up on long queries, users running
the executable didn’t have any indication of how many rows had been
retrieved (so they could make a judgement of when to cancel). In 6.0,
you now have more information to decide when to cancel a query.

Selecting Tables
=============
All the painters using the Select Tables dialog have been modified to
include horizontal scrollbars for long table names that are likely in
mainframe databases or when joins are used. This feature overlaps the
form painter for SQL Select and Quick Select dialogs - these dialogs
also have horizontal scrollbars. This is also in 5.0.04 maintenance.

Forms and SQL Select and Quick Select dialogs
==============================================
These dialogs have been enhanced to support horizontal scrollbars if the
table names overflow the dialog.

Filter Dialog on Forms
======================
Built-in action filter dialog is provided on forms so users don’t need
custom styles to access this feature. Filter_dialog is available for
freeform or grid. filter_master_dialog/filter_detail_dialog are
available for 12many and many21. The 6.0 filter dialog has been
modified to allow longer column names for ease of use in development and
deployed runtime executables for end users. There are also actions for
clearing filters (clear_master_filter and clear_detail_filter or
clear_filter) where applicable.
NOTE: These actions are supported off buttons only. They are not
included on menus.

Sort Dialog on Forms
====================
Built-in action sort dialog is provided on forms so users don’t need
custom styles to access this feature. Sort_dialog is available on
freeform and grid forms. Sort_master_dialog/sort_detail_Dialog are
available on one-to-many and many-to-one forms.
NOTE: These actions are supported off buttons only. They are not
included on menus.

Specify Criteria on Non-updateable forms
=========================================
All form styles. "Update Characteristics" dialog, "Allow Updates" OFF.
In 4.0 and 5.0, users were not allowed to enter "Specify Criteria"
parameters if the grid, freeform (or master datawindow in 12many,
many21) was not updateable since the form became read only and although
the "Specify Criteria" would open up a row for input, the user could not
type into it. In 6.0, users running read-only forms can use "Specify
Criteria", (the form will open for input ), they can enter criteria,
click "Apply Criteria" and the form will retrieve rows and go back into
read-only mode. INSERT/DELETE/UPDATE toolbar buttons will
automatically be disabled on read-only forms.

One-to-Many. When the criteria is applied (Apply_Criteria action), the
master section, if not updateable, will go back into read-only mode and
also the INSERT/DELETE/UPDATE menu items and toolbar icons will stay
disabled when focus is on the master. This makes the form much more
useful for developers wanting either the master or just the detail part
of their form to be "read-only" but still allowing their end users the
ability to use "Specify_Criteria/Apply Criteria" - a powerful query
tool.


General
======
1. All Open Forms, Reports, Pipeline dialogs in the deployed executable
use listviews. Each object will be shown along with the comments
entered in the environment painter. The end user running the
executable will have the description of the object along with the name
to help them choose the correct form/report/pipeline. This makes the
dialog much better for the end user.

The listing for the Open Report dialog would look something like:

Report list
Name Description
d_employee Employee list for deparment 100
d_employee_all Employee listing for entire division minus
department 100

InfoMaker 5.0 only showed the object name.

Pipeline Deployment
===================
New Feature. Pipelines can now be deployed in the IM 6.0 execuatable.
Before, they were only allowed in development. This allows users to
run against a local database (after running the pipeline) or any
database supported by InfoMaker 6.0 (Infomaker 6.0 includes all native
drivers to Oracle, Sybase, Informix, etc).

Benefits: Example is a deployed pipeline source = DB2 to destination =
SQL Anywhere, reports all run against SQL Anywhere. When the DBA
changes a database configuration (renames tables, changes column
datatypes or lengths ), if the pipeline is from DB2 to SQL Anywhere, all
the developer has to do is change the PIPELINE object and redeploy the
executable instead of re-doing all the reports. With the use of forms
and the pipeline, it’s also possible to "upload" user input data from a
local database to a corporate one.

Restrictions allow only one version of a specific pipeline to run at a
time in a runtime executable. (More than one pipeline can run in manual
or delayed mode but they must be different pipelines) There are some
considerations for runtime licensing SQL Anywhere if you're using Create
Table / Drop Add Table pipelines. These contain statements not
supported in the normal deployment runtime engine rt32.exe. You must
have a license to run Data Definition Language in the runtime
environment.

As always, client software is required for all pipeline source and
destination database interaction to work correctly.

General Notes for Standard Form Styles & Custom Form Styles
===========================================================

1. The standard styles are now contained in a system PBL called
IMSTYLE6.PBL that ships with Infomaker 6.0. Users are cautioned not to
open this PBL in the Infomaker 6.0 development environment. If
developers have problems, the file can be copied from the original CD.
It will be archived in an un-compressed state. Powerbuilder users
wishing to create custom styles can copy this pbl into a customstyle.pbl
and use the objects as templates or modify the existing IMSTYLE6.PBL for
their own needs. An example might be to add querymode functionality to
the window used for displaying reports - w_pbstyle_report.

IMSTYLE6.PBL is not required for deployment.

2. Custom styles are supported as they always have been since PowerMaker
3.0. ShowStandardStyles=0 in the IM.INI is also supported to suppress
the built-in styles and show only "custom styles" from the "style
library list". The manual that used to be "Building InfoMaker styles
and actions" in Powerbuilder 5.0 now in 6.0 has been rolled into a
manual called "Application Techniques".

3. OLE 2.0 is now support fully both as a report style and for
inserting controls on forms for a deployed executable.