Scrolling fields (was: RE: Desperate plea to FP Tech...)

[Lerebours, Jose]

Bill posted:

> >John mentioned scrolling fields.  Not having them is, I think, one of
> >the key reasons why more screen space is needed.  For example, if I
> >simply want to add an e-mail-contact field to a customer 
> screen I have
> >to take up quite a bit of screen space to accommodate how 
> long an e-mail
> >address MIGHT be even though most of them don't even come close.  But
> >most people don't need to see the whole e-mail address and even those
> >that do rarely have to.
> 
> The main reason I've never implemented scrolling fields in my
> accounting system's window handling routines is that I prefer
> to have the cursor jump to the next field when the last character
> of the previous field is entered.  This is particularly true
> where one might have a number of 1-character yes/no fields in
> which case scrolling fields would double the number of keystrokes.
> 

Bill, you mean to say you know how to do this?  Could you please
share this technique with us ???  

I have thought about it but it required so much programming work
that I figured the work load did not justify the benefit.

Using show+inkey throughout the screen is one way I figured might
be possible ... but the inkey itself is so resource hungry that
the application would feel overly bloated.

The mechanism I thought of involved:

1. Using a table where the screen format and content was
   defined
2. Loading table from (1) to arrays and displaying content and
   layout using show commands
3. Use a loop/while routine to manipulate cursor path and field
   editing

Sounds simple if stepped as above 1, 2 and 3 but in practice, it
could be a bowl of soup or spaghetti (depending on your diet) 8-)

If you think of this logic, it might be possible but again, not
worth the effort.  This approach would require that screens be
defined in a table, not as we know it now; in essence, screens
will be blank - not a thing on them (I like to have a rookie
programmer trying to figure out cursor path and data control on
something like this).  Besides, there may be the need to constantly
redraw the screen as you use other features such as popup, browse,
input, show, ... that overlay screen content.

In other words, I felt that this would take programming in filePro
back another generation instead of moving it forward.

Regards;


Jose Lerebours