Slave Screens - Altering data prior to display

[Carol Kaffenberger]

I'm having a problem with a slave screen.  There is a field
which contains a date that must be changed from CCYYMMDD to
MMDDCCYY before displaying it on the screen.  (It is not
defined as a DATE field because our data may contain '99' in
any portion of the date to represent an 'unknown' MM or DD
or CC or YY).

I've tried putting the logic in a POSTFIND procedure (which
doesn't get executed because the FIND procedure is disabled)
and in an OUTPUT procedure (which just redisplays the
original value from the file over and over again no matter
what I change it to).

Then I tried putting the logic in an INTERNAL procedure
called by an INITIALIZE procedure which is the best so far
with 1 minor shortcoming.  Each time I invoke the slave
screen, the date is displayed properly.  However, if I
change the date, return to the master screen without
updating, and then return to the slave screen, the original
value of the date is displayed.   This is in direct contrast
with all of the other fields on the screen--they retain the
modified values even if not updated on the slave screen.  If
there were some way to force the user to update prior to
leaving the slave screen there wouldn't be a problem.

I even tried to get rid of the slave screen altogether and
made 2 regular screens and ended up with 'Record has been
changed since you found it'.

I am totally unfamiliar with slave screen processing.  This
is our 1 and only application that uses slave screens so I
don't have any good examples to follow.  If anyone has any
suggestions, they will be greatly appreciated.  Thanks.

--
Carol Kaffenberger
Karmanos Cancer Institute
Detroit, Michigan


= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.