screens other than 0-9 (was: Re: Windows 2003/IIS6issues...newandimproved ones.)

[GCC Consulting]

> -----Original Message-----
> From: 
> filepro-list-bounces+gccconsulting=comcast.net at lists.celestial
> .com 
> [mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.c
> elestial.com] On Behalf Of Brian K. White
> Sent: Thursday, May 24, 2007 1:28 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: screens other than 0-9 (was: Re: Windows 
> 2003/IIS6issues...newandimproved ones.)
> 
> Mark has one point actually about inconsistency, define 
> screens lets you browse all screens, but of course define 
> screens is not a comparison since it's a developer-only util.
> 
> Users can however browse full lists of forms and browses and 
> selection sets.
> By rights those should all be limited.
> There are ways to hide or limit some of those now but by 
> default, if they show at all, they all show.
> 
> I think you should think about it like this Mark:
> Just as no one worries that if you don't specify a file, you 
> get to select from among all files, which is bad in a real app.
> In the simple early do-it-yourself quasi-apps where filepro 
> was born, that was fine.
> But now that we write ostensibly real apps in fp, you simply 
> always specify a file in an end user's interface to an app.
> So it is with screens. The 0-9 popup menu is just an old 
> interface that these days no one should use much any more, 
> but, there is also no special reason to take it out.
> 
> Hmm... now that I say that... I just argued Marks point and 
> now I agree with him.
> If the screens popup should be thought of and treated like 
> the file list, a developer only thing, then it's back to 
> Marks point making more sense, and all screens should show.
> 
> That was interesting.
> 
> Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!


Again, we run to the point of controlling what screen are available.

I control the output list in my apps by having @keyf set to end or to a
listbox of the form(s) I want them to have access to.  This has the
advantage of being able, in some cases, to present a more meaningful output
name the output really has.

There is little sense to giving access to everything when writing a custom
application especially when various programs either input or output may need
to use different processing table to run properly.

Take an output that uses a sort/select process to pick the records and sort
them.  I have one that selects records by date and then does a lookup to the
customer file and sorts the report by address.  Someone could select this
report from a list of outputs, but it would sort incorrectly.  I am sure
there are many instances where this is true for other apps.

I have one application where I have blocked access to all screens but the
one named screen.  When this group of user login to the system the run a
very specific input process and all of the number keys are blocked using
@key.  They are further restricted as to the records they can see by locking
them into a specific demand index.  As they can't change the data on the
screen they are looking at, all changes to the record are done using @key
functions and input statements.  

If I want someone to have access to most of the outputs available, I would
write this using fp's programming tools and then filter out those outputs I
don't want them to have access to. 

You can almost duplicate fp's own format. I did this with my laptops single
user development 5.6 so I could open a second processing table in a text
editor with at the same time as one open in rcabe.  The program prompts for
a file name, pressing enter or F6 brings up a file list, select a file and
the a processing table list appears.  Select a processing table and it is
opened in WordPad.

Mark, many times you complain about security or lack there of.  Here is an
instance where fp has added an additional level of security to their
interface.  Screens can have a password.  So it is possible to have screens
which are not accessible to the general user base.  Processing can control
who has access to these non-numbered screens and they could have a password
to further protect access.

Richard Kreiss
GCC Consulting