Double duty screens

[Steve Heaslip]

This is a multi-part message in MIME format.
--------------80E8AA329D0A28001D88C456
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

Personally I like the idea of trapping the users at the preupdate stage. Not
only is there a lot less coding to do and maintain, but it allows the users to
get down to things like scrollable fields or lookups and calculations and allow
them to see the results of any edit & process procedures, etc.

However, so that users know their limitations before they begin keying in reams
of data and expect it to be updated, add a display only field at the bottom of
the screen (with hilighting so it stands out) that displays a message like
"Your security class will not allow you to update on this screen". This field
is based on a temp item that you set in the postfind procedure depending on the
users security class. Alternatively, you can just display a warning message
at the end of the postfind procedure - but this message will be cleared as soon
as the user does anything.


Steve Heaslip

-----------------
John Pearce wrote:

> I'm doing maintenance on a system written about 1990.  To provide certain
> users the ability to view data but not to change it,  a dozen or so screens
> were duplicated then all the procedure code deleted and the activities
> statement changed to only allow find mode.  I need some ideas on making one
> version of these screens perform double duty.  For certain user classes,
> the screen should allow retrieval without update and allow other user
> classes to enter and update, too.
>
> It seems like the only solution is to write a preupdate procedure that
> checks the user's class and issues an error if update is not allowed.
> While this approach will work, I'd prefer to issue an error message when
> the user tries to update a field.   I don't want to write an input
> procedure for each field on the screen either.  Is there an easy solution
> for this?  Any other ideas beside the preupdate or input procedures?  FWIW,
> this is PH8.19C4 on MPE/ix 5.5 PP 6.
>
> Thanks.
>
> ------------------------------------------------------------------
> John Pearce  <jpearce@rmi.net>       | Bethesda Management Company
> Speaking for only myself             | Colorado Springs, CO  USA
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
> powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
> This list is closed, thus to post to the list, you must be a subscriber.

--------------80E8AA329D0A28001D88C456
Content-Type: text/x-vcard; charset=us-ascii;
 name="heaslips.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Steve Heaslip
Content-Disposition: attachment;
 filename="heaslips.vcf"

begin:vcard 
n:Heaslip;Steve
tel;cell:0417 656 864
tel;work:02 9936 5804
x-mozilla-html:TRUE
org:Hexagon Computer Systems
adr:;;;;;;Australia
version:2.1
email;internet:heaslips@ozemail.com.au
title:Senior Consultant
x-mozilla-cpt:;-8272
fn:Steve Heaslip
end:vcard

--------------80E8AA329D0A28001D88C456--

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