DEAD area on screen

[Richard Kreiss]

I did some experiments on this issue and found that unless the field in question is a dummy field, everything else both real fields from the map or a system field will display on line 20 up[ to the length of the field. i.e. a (10,*) will display at column 70 but not 71.  The issue with dummy fields is that *clerk does not know the size of the field until auto processing is run; by then ;*clerk would need to know prior to displaying the screen, whet the field size is and is doesn't as the field has not be defined yet.  I am speculating as to how *clerk handles dummy fields as they can't be resolved by pressing F5 but will be displayed properly once *clerk has run and the program has the ability to wrap a field to the next line.  That is most likely the reason for the \ option to limit the display area and not have to wrap the field. I would suggest that everyone experiment with using the \ on a field to limit the area taken up on a screen.   Using the \ will allow the use of more screen area to be used for displaying information.


Richard Kreiss
GCC Consulting



> -----Original Message-----
> From: Filepro-list <filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com>
> On Behalf Of Richard Kreiss via Filepro-list
> Sent: Thursday, February 18, 2021 4:06 PM
> To: Fairlight <fairlite at fairlite.com>
> Cc: filepro-list at lists.celestial.com
> Subject: Re: DEAD area on screen
> 
> I was informed that the issue is that the screen at line 20 can’t wrap a line. I
> would then line to know why I can place @vr at line 20 column 1. And gave it
> display properly.
> 
> I need to test at what point the ability to wrap affects the display.
> 
> Richard
> Sent from my iPhone
> 
> > On Feb 18, 2021, at 2:18 PM, Fairlight via Filepro-list <filepro-
> list at lists.celestial.com> wrote:
> >
> > On Thu, Feb 18, 2021 at 07:04:58PM +0000, Richard Kreiss via
> > Filepro-list thus spoke:
> >>
> >> Yes, I presented this to FP support.  I am sure that others have
> >> noted this to support at all of the companies who have owned filePro.
> >> Or at least they may have noted this issue when the company was purchased.
> >> Apparently this is not a "major issue".
> >
> > The way some fP Tech customers (my clients and some other friends)
> > have explained it to me, nothing is a 'major issue' unless it affects
> > Bud's personal (as opposed to fP Tech's) clients.
> >
> > So I was told, anyway.  That may or may not reflect reality, but let's
> > just anecdotally contemplate the fucking spell checker and add 2 + 2, shall we?
> >
> > m->
> > --
> > Audio panton, cogito singularis.
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > Subscribe/Unsubscribe/Subscription Changes
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 14588 bytes
Desc: not available
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20210218/8fa309c4/attachment.bin>