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

[Bruce Easton]

Bruce Easton just wrote:
> 
> Kenneth Brody wrote Thursday, May 24, 2007 12:06 PM:
> 
> > Quoting Bruce Easton (Thu, 24 May 2007 11:57:05 -0400):
> >
> > > Kenneth Brody wrote Thursday, May 24, 2007 11:25 AM:
> > [...]
> > > > Screens 0 through 9 are made available without any programming.
> > > > Lettered and named screens (ie: all but 0 through 9) are only
> > > > available if the developer programs access to them.
> > > >
> > >
> > > I've always wondered why filepro's clerk's default dialog 
> excluded named
> > > screens, but accepted that a "design decision" must have been made
> > > early on.  Was there ever a time when only single character screens
> > > were allowed?  If so, then the dual syntax (quotes/no quotes) for the
> > > screen/display commands makes more sense.
> >
> > filePro 16 version 1.0 had only screens 0 through 9 and A through Z.
> > The syntax for the SCREEN command did not require quotes around the
> > screen number/letter.  For compatibility, you can still leave off
> > the quotes for 0-9 and A-Z if you so desire.  (Though it's always
> > possible that this may be deprecated somewhere along the line, so
> > you should use quotes on any new code with a literal screen name.)
> >
> > > It would be nice to have the built-in dialog for clerk bring up
> > > all the screens on file - I know it is easy to code this
> > > functionality, but requiring processing to be in place for that
> > > basic function is limiting of filepro's otherwise pretty good
> > > out-of-the-boxness.  Of course, for backward compatibility, if such
> > > a feature was ever added, define screens should allow any screen
> > > to be marked to not appear by default (which would give more
> > > flexibility) AND a global env to make things work entirely the
> > > current way.
> >
> > Of course, adding a "don't display this screen" flag would require
> > that filePro open/read/close every screen for the file before it
> > could display the list.  See my recent note regarding PFDIRFILTER,
> > and that slowdown was caused by a mere stat() call.
> >
> > (And the same applies to a "don't display the output format" flag.)
> >
> 
> Then regarding potential slow-down, I'm guessing even without a
> "don't display this screen" feature, but only a env flag for current
> behavior, showing the whole list of screens for a file would still
> require you to open each screen to check for passwording, for
> instance?
> 
Bad example - I wouldn't think you would need to read the file 
for password until it was selected, would you need to open them 
for anything else?

Bruce

Bruce Easton
STN, Inc.