Consultor Eletrônico

Bug fixes for the ADM in Progress Version 8.1.

INTRODUCTION
============
This knowledgebase entry is a summary of significant bug fixes
and other small changes between Progress Version 8.0A (as of
the 8.0A04 patch release) and 8.1A. Fixes noted here are those
which are likely to be of interest to a number of users who have
built applications using 8.0 and are moving those applications
to 8.1. Not every single fix is described. Where possible a
brief description of the files changed or the nature of the
change is included. This list is in no particular order.

BUGS
====
1. Initial values not shown for non-fill-ins. Because the CREATE
statement for an Add operation is normally postponed until the
new record is Saved, the ADM code used a mechanism whereby
initial values were retrieved from a Temp-Table record and
displayed using the "ôDISPLAY @"ö syntax and the {&FIELD-PAIRS}
preprocessor values. This worked only for enabled fill-in fields.
This has been changed to use the ô"template" record for Progress
databases, which will show all initial values except fields
whose initial value is TODAY, with the option to have the CREATE
done by the add-record event using the "Create-On-Add"
ADM attribute. See the documentation for more information.
2. Using a Temp-Table in a SmartBrowser causes compile errors.
In particular, the use of the Temp-Table adm-initial-table for
initial values (see #1) caused a compiler error if the Enabled
Table was itself a Temp-Table, because one Temp-Table cannot be
defined LIKE another. This has been removed, which removes one
of the obstacles to building SmartObjects based on Temp-Tables.
3. The check-modified method sometimes needs to check non-db
fields or non-enabled fields. In 8.0, the check-modified method
procedure checks to see whether the current record has been
modified before closing the SmartContainer or moving to another
record. Only enabled database fields are checked. This has
been enhanced in 8.1; if the "ôCheck-Modified-All"ö ADM attribute
is set to ô"Yes"ö, then non-database fields and non-enabled fields
will also be checked.
4. Update with multiple SmartViewers connected by Group-Assign
over-executed. If the SmartViewers were connected one to the next,
instead of all Group-Assign links going from the first SmartViewer
as Group-Assign-Source, the adm-end-update event procedure would
cause assign-record to be dispatched multiple times for each
SmartViewer. This has been fixed, but it is still recommended that
the "Main" SmartViewer in a Group-Assign (the one which is the
TableIO-Target) should be the Group-Assign-Source for all the
others.
5. Display-fields executed multiple times on Add. In this and some
other cases, redundant execution of event procedures has been
eliminated.
6. Insert-Row workaround removed for empty SmartBrowser. In 8.0,
the Progress browse control would not allow an INSERT-ROW method
into an empty browse. This required the ADM code to have a
workaround for the case where an Add operation was being done for
an empty SmartBrowser, creating and saving the new first record in
a single operation. The restriction on the browse control has been
removed, and so has the ADM workaround. Adding the first row to an
empty SmartBrowser now works like adding any other row.
7. "ôadd-only"ö SmartPanel state not always correct. In some cases
running the Update SmartPanel set-buttons procedure with the
"ôadd-only" state did not properly enable the Add button and disable
all others. This has been corrected along with other cases in
which going from the "ôadd-only"ö state when there are currently no
available rows to update, to the "ôinitial"ö state when Add, Update
and Delete are all enabled, did not always work properly.
8. Inappropriate strings in the Translation manager list of
translatable strings. Some strings in the ADM code which should
not be translated were missing the necessary "ô:U"ö suffix to keep them
out of the translatable strings list. Also, some error messages
which will normally be seen only by developers have been removed
from the translatable strings list. In addition, a new ADM attribute
("ôADM-Translatable-Attrs"ö) has been defined tallow Folder-Labels ls
and other attributes to be translated more easily.
9. Update SmartPanel not always enabled for Group-Assign. If
several SmartViewers were connected by the Group-Assign link, the
Update SmartPanel for the group would be enabled only when the "æmain"
Viewer (the TableIO-Target) was viewed, forcing developers to
remove the TableIO link from the list of ô"ADM-deactivate-links".
This has been corrected. The Update SmartPanel will remain enabled
as long as one of the Group-Assign-Targets is viewed.
10. The request method should recurse where necessary. The request
method procedure is used as part of the reposition-query process
of repositioning a query after an Add or other operation, and can
be used by user applications as well to run a procedure which needs
to take the requesterÆs procedure handle as a parameter.If recordss
were being passed through an intermediary SmartContainer without
a pass-through link being created, then a reposition-query would
not work properly because the request method would stop at the
SmartContainer without getting to the actual Record-Source. To
correct this, the request method now will recurse if necessary;
if the SmartObject connected by the requested link type does not
define the requested procedure, then request will see if that object
in turn is connected to another object by the same link type, and
look for the requested procedure there.
11. Update SmartPanels prevent the use of Data-Entry-Return.
Because the Update SmartPanels defined the Save button as the
Default Button (allowing the Enter key to perform a Save), this
would override the specification of the Progress SESSION attribute
Data-Entry-Return, which is used to define the Enter key as a tab
between fields. This has been changed such that the Default Button
definition for the SmartPanels is made at runtime, and is done
only if the Data-Entry-Return attribute is not set.
12. Empty SmartViewer should not be enabled. In some cases, a
SmartViewer which was initially empty (for example, it was a
Record-Target for a SmartBrowser with no records) was enabled,
and an error would result if the user attempted to enter data or
press Save. This has been corrected.
13. Dispatching the same event in another object incorrect. If
application code dispatched, for example, 'æinitialize'Æ in SmartObjtc
B from within local-initialize in SmartObject A, the dispatch
procedure did not see that two different SmartObjects were involved
and would not run local-initialize in SmartObject B, thinking that
it had already been run. This has been corrected.
14. Select-page (0) did not work properly. The select-page procedure
checks to see if the requested page has been created, by looking for
objects with the PAGEn link. Since there is no PAGE0 link (this link
is created only for other pages), select-page would create the
objects on page 0 multiple times. This has been corrected.
Running select-page(0) has no effect other than to hide the current
page if it is not page 0.
15. Select-page did not respect Hide-On-Init. If a SmartObject was
created and first initialized by having its page selected, it would
be enabled and viewed regardless of the setting of the SmartObject
attributes "ôHide-On-Init"ö and "ôDisable-On-Init"ö. This has been corrected.
16. SmartPanel state not correct for Multiple Adds. If the Multiple
Add SmartPanel attribute was set, it was sometimes necessary to
press Cancel twice to get out of Add mode. This has been corrected.
17. adm-create-objects should check for SmartObject creation
errors. In the event a SmartObject was not created successfully by
init-object, or chose to destroy itself because of some application
constraint, this was not properly detected, which could result in an
error later in adm-create-objects when it tried to RUN set-position
for the object or add links for it. The init-object procedure now
returns ERROR if no valid procedure is created by the SmartObject
RUN statement, and the UIB-generated code in adm-create-objects
will check for this.
18. SmartViewers should support "ôExclusive-Lock"ö. Some users have
requested a way of guaranteeing that a record update will not
conflict with another concurrent update. This has been implemented
as a third possible value for the ô"Initial-Lock"ö attribute,
"Exclusive-Lock"ö, which gets a momentary Exclusive-Lock and then
releases it in order to leave the record Share-Locked during data
entry. Note that this technique will work only if all code
potentially accessing that same record observes the same technique
of requesting an Exclusive-Lock when reading the record.
19. Displayed-Objects should be displayed by display-fields. The
adm-display-fields event procedure displays those fields in the
{&DISPLAYED-FIELDS} list. It has been modified to display other
controls in the {&DISPLAYED-OBJECTS} list if there are any. These
would be other fields or controls in the frame which are not
associated with database fields.
20. Users should be discouraged from using the Transaction
SmartPanel. Under most circumstances, applications should be built
using the Standard Update SmartPanel. The Transaction Update
SmartPanel should be used only when the developer specifically
wants an open transaction during data entry. This is not always
clear to developers. The Transaction SmartPanel has been
enhanced to display a warning alert box when it is first used to
make sure that the developer understands its proper use.
21. Lack of feedback in design mode when changing pages. When
placing SmartObjects on various pages of a SmartFolder in the UIB,
the "ôcurrent-page"ö folder tab did not change. This was sometimes
confusing. This has been changed by adding the show-folder-page
method to folder.w and running it from the UIB.
22. ADM-CREATE-FIELDS not disabled on Add error. Fields which
are normally not enabled by which are to be enabled during an Add
operation can be placed in the list ADM-CREATE-FIELDS to make this
occur. In some cases these fields were not properly disabled
following an Add operation which generated an error. This has been
corrected.
23. Deleting the last record did not change SmartPanel state. If
the last record in a dataset was deleted, the state of the Update
SmartPanel would not change to ô"add-only" (all buttons disabled
except Add). This has been corrected.
24. Update-Complete should not always cause row-changed to be
dispatched. The update-complete state code in qstates.i and
bstates.i dispatches row-available to let other dependent objects
know that the current record has been changed. However, this
should not occur if the update was in fact in some other Query
Object, for example, a SmartBrowser which is a Record-Target
of the SmartQuery or SmartBrowser in question. This code has been
changed to check to see if the update-complete came from a
Query-Object (SmartQuery or SmartBrowser), and not to run notify
of æ'row-available' in that case. This elminates unnecessary record
displays and open-query events in other SmartObjects.
25. Error-checking code misplaced in adm-assign-statement. The
placement of the error-checking code in adm-assign-statement is
such that it sometimes can get executed for a SmartBrowser when
NO assign was actually done. The code has been rearranged to
avoid this problem.
26. Reopen/reposition after add-record is visually distracting
and inefficient. When an add-record/update-record operation is
done, the query is reopened in order to add the record to the
dataset, and then the query is repositioned to that record.
Visually the user can see the query being reopened and the
first record being displayed, and then the newly added record
being repositioned to. This has been changed through the use of
a new "Reposition-Pending"" ADM attribute which is set in theh
Query-Object by adm-assign-record prior to dispatching
open-query, and then checked by adm-open-query, which will skip
the normal æ'get-first' event if the query is about to be
repositioned anyway.
27. All Update buttons should be disabled for an empty parent
query. If the current query is empty, then the
no-record-available state is sent out, which causes an Update
panel to disable all but the Add button. However, if this query
is dependent on an external Table, and even that record is not
available (for example, a query on OrderLines of Order when the
current Customer record has no Orders) then all Update Panel
buttons should be disabled, because it is not valid to
attempt, for example, to add the first OrderLine record to the
current Order, when there is no current Order. This has been
accomplished using a new state, no-external-record-available,
which is set by adm-open-query under these conditions, and
checked by pustates.i and pnstates.i.
28. Incorrect focus among windows can cause error code to loop.
Given a main SmartWindow with a SmartBrowser and a button which
launches a second SmartWindow, if a record update error in the
SmartBrowser causes an alert box to come up, dismissing the alert
box can cause focus to be shifted improperly from the
SmartBrowser to the second SmartWindow, which fires the Progress
Leave event for the SmartBrowser, which causes the error again
and brings up the alert box again, leading to an infinite loop.
This has been corrected by changing broker-initialize to set
CURRENT-WINDOW for each SmartObject to its SmartContainer window.
29. Navigation panel states aren'tt right for SmartBrowser
navigation-target. If a SmartBrowser is modified to be a
Navigation-Target by adding this link to its Supported-Links
and including query.i in addition to browser.i, then the associated
Navigation SmartPanel will not always have its buttons in the
correct state. This has been corrected by duplicating all the
state code for the SmartBrowser portion of all the event procedures
in query.i.
30. Navigation SmartPanel states not maintained for multiple
targets. If a Navigation SmartPanel is a Navigation-Source for more
than one SmartQuery (on different pages of a SmartFolder, for
example), then as the user switches between those pages, the state
of the Navigation Panel is not reset correctly for the current
Navigation-Target. This has been corrected by creating a new
"ôQuery-Position"ö attribute which is set in qstates.i to hold the
current navigation state for a SmartQuery, and then is queried by
pnstates.i when a Navigation-Target is activated to reset the
SmartPanel state properly.
31. Deleted record shown in dependent SmartViewer. If the last
record was deleted from a SmartBrowser, it continued to be shown
in a dependent SmartViewer. This has been corrected by running
notify of 'row-available'Æ from delete-record if the last record
is deleted.
32. No way to delete attributes. There was no way in 8.0 to
ôdeleteö ADM attbutes or reset them to their initial Unknown
value (represented as ?). This has been corrected in 8.1 by
setting an attribute value to the Unknown value when it is set to
'?', as in RUN set-attribute-list('my-attr?'). This does not actual
delete the attribute but resets it to the Unknown value, which is
the same value returned for undefined attributes. Note that in 8.0,
setting an attribute to 'æ?'Æ would have returned the character
string '?' Æ as its value.

Progress Software Technical Support Note # 16313