What's the best way...

[Maclary, David]

This can also be done without condition compiles if needed.  The approach
could be something like...

A "readonly" version:
   ACTIVITIES FIND
   USE TheRest

A "do everything" version:
   don't specify activities
   USE TheRest

Where TheRest is all of the code needed to create the screen, excluding the
SCREEN statement.

Then, create a "ghost" screen to check the ASC (or whatever) and call the
appropriate screen.

Regards,
David

> ----------
> From: 	Paul Howard[SMTP:paul@synergy.co.za]
> Sent: 	Thursday, March 18, 1999 4:58 AM
> To: 	powerh-l@lists.swau.edu
> Subject: 	RE: What's the best way...
> 
> Building on what has been previously said how about using a conditional
> compile to compile a single source twice automatically to create two
> objects
> which get run conditionally depending on the user.
> eg.
> 
> @if READONLY
> screen P100RO &
>   activities FIND
> @else
> screen P100
> @endif
> 
> file COMPANIES
> generate
> 
> build
> @if not READONLY
> !qdesign auto=P100 nolist cc=[READONLY]
> @endif
> exit
> 
> -------------------------------------------
> 
> And then in the calling screen:
> 
> define SCREEN_NAME character size 6 = &
>        'P100' if matchuser('BOSS') else &
>        'P100RO'
> 
> subscreen item SCREEN_NAME
> 
> 
> Regards Paul
> 
> -----Original Message-----
> From: Chris Sharman [mailto:Chris.Sharman@ccagroup.co.uk]
> Sent: Thursday, March 18, 1999 11:13 AM
> To: mao@krifapost.dk
> Cc: Chris.Sharman@ccagroup.co.uk; powerh-l@lists.swau.edu
> Subject: Re: What's the best way...
> 
> 
> >>What's the best way to have a single screen serve two sets of users
> (based
> >>on user class) where one user class can do everything (enter, update,
> >>delete) and the other user class can only inquire on existing records?
> 
> It's a very good question. I've never found a very good answer. It seems
> like
> the sort of thing application security ought to do, but I've never seen it
> work. Also the 'readonly' users will need write access to the files to run
> the
> common Quick screen: it would be nice if Quick just 'fell back' to a
> readonly
> mode when it couldn't get write access to the data: perhaps a screen
> "allowreadonly" clause or something.
> 
> >What about having two sets of keys in your program - One for those who
> can
> >do everything
> >(The default keys, level 1) and one for those who only can search and
> watch
> >the data (level 2),
> >and then check in your INIT and POSTFIND procedures:
> 
> Wouldn't work on VMS, unless you disabled all the standard keys. Don't you
> have
> them on other platforms ?
> 
> We make sure find-only users start in find mode, and put a catch in the
> pre-update to stop them. It's imperfect, but it does the job.
> If I wanted perfection, I suppose I'd go for one source, two .qkc's:
> 
> @if readonly
> screen myread activities find ..
> @else
> screen myfull ...
> @endif
> ...
> You could also put (conditional) "open read" on all the files.
> 
> $ qdesign auto=myscreen [cc=readonly]
> 
> A similar effect could be achieved with use statements, if you wanted to
> avoid
> cc for the sake of autobuilds: 2 * 2 line files + one main source.
> 
> screen myread activities find ...
> use therest
> 
> screen myfull ...
> use therest
> 
> <therest>
> 
> ______________________________________________________________________
> Chris Sharman			Chris.Sharman@CCAgroup.co.uk
> CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancashire, PR2 9WS.
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> =
> 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.
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> =
> 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.
> 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.