Kbase P54078: Custom Super Procedures are Placed into the Stack in a Different Order.
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  10/16/2008 |
|
Status: Unverified
FACT(s) (Environment):
Dynamics
Dynamics 2.1a
SYMPTOM(s):
Custom Super Procedures are Placed into the Stack in a Different Order.
In 2.0 you saw in the super procedure stack of rydyncontw.w:
adm2/custom/containercustom.p
adm2/containr.p
adm2/custom/visualcustom.p
adm2/visual.p
adm2/custom/smartcustom.p
adm2/smart.p
In version 2.1 (Progress 9.1D SP7) we see:
adm2/custom/containercustom.p
adm2/custom/visualcustom.p
adm2/custom/smartcustom.p
adm2/containr.p
adm2/visual.p
adm2/smart.p
CAUSE:
Functionality to run custom super procedures has changed in 2.1a
FIX:
The following manual changes are required for adm2 customizations (custom
includes).
1. All custom super procedures need to be defined in the Repository as new
classes that extends the class they are customizing. These new classes need
to have a SuperProcedure attribute that defines the file-name of the
super-procedure.
Any properties defined in the custom*prop include should also be defined as
attributes under the class.
2. The custom/<classname>custom.i include need to have an additional IF
statement to ensure that they only are started when the object is not loaded
from repository.
-------------
IF NOT {&adm-load-from-repository} THEN
RUN start-super-proc(.....)
-------------
It is currently necessary to define adm2 customization both through the
adm2/custom include and in the Repository in order to enable adm2 procedures
to run interchangably in non-repository environments (including static
containers in Dynamics) and in repository driven dynamic containers.
Objects that only run in dynamic containers do not need the adm2 include
customization. Note that data objects and SBOs currently run statically on
server and in webspeed, so customizations for data objects have to be done
both ways.