CURSES sub-windows bugs - correction to Mike Laman article

[Mike Laman]

In article <8713 at watmath.UUCP> idallen at watmath.UUCP writes:
>> From: laman at sdcsvax.UUCP (Mike Laman)
>> First of all let me point out that when sub windows are
>> created, the window's text is SEPARATE from original window.
>
>This is not true with the 4.2bsd curses dated June/July 1983.
>Sub windows are merely edge vectors into their parent windows.
>A change in either is reflected in both, since they are the same.

He is correct.  I am embarrassed as to how I could have fooled myself.  Sigh.

>> As I mentioned earlier, the real killer is that EACH routine would be
>> responsible for adding the information to each associated window.
>> I suggest the correct solution be to have sub windows SHARE the window text
>> with the information in the WINDOW header telling what part of the lines it
>> "owns".
>
>4.2 curses already does share window text.  The line-change flags are
>not shared, and are not updated correctly by any of the erase or
>clearing functions.
>
>> As for the problem at hand, I guess you'll have to be happy with
>> "overwrite()" (and "overlay()"), until you get a System V.2 to use.
>
>I would be surprised if even V.2 got sub-windows right.  The fix to
>making clear and erase affect all related window change flags is easy. 
>CLEAR already calls ERASE.  Make ERASE and CLRTOBOT call CLRTOEOL for all
>appropriate lines.  Make CLRTOEOL set change flags in all affected windows.
>	:
>	:
>	:
>        -IAN!  (Ian! D. Allen)      University of Waterloo

5.2 didn't get sub windows right either.  There are two problems with them:
Three routines shuffle pointer that are unique to EACH window, so the shuffling
doesn't have the right effect on related windows.  The problem of adding a
character to one window and having the "_firstch" fields show the change in
other related windows exist too.  I still say that making every routine that
changes a window be responsible to show those changes to all the related
windows is NOT the way to go!  I have the fixes for SVR3 curses and sent them
to Mark Horton.  The changes should be that same for SVR2 and the code should
be portable to 4.2 with few changes.  I'm awaiting Mark's reply.
[ There are just TOO many routines that change windows.  You would have a
BIG problem with duplication of code => the work is being done at too deep of a
level. ]  My solution was to first modify winsterln, wdeleteln, and scroll to
use memcpy() instead of shuffling pointers.  This should be optimized to
do the shuffling when there are NO related windows to the given window, as I
mentioned to Mark.  The second thing I did was to write a couple of routines
that get called just before the updating goes on. These routines pull all the
changes up to the called window leaving the "_firstch" fields at "_NOCHNAGE"
since the change is now seen elsewhere.  And then pull all the changes from
all the parent windows (and their children expect this given window) down
to the given window.  These routines seem to do the trick!  I have a program
that has about 5 levels of subwindows many of which have children (and they
may have children). I add characters to each window and can selectively
refresh any window.

I'm sorry again about my misconception... I don't know how I got confused.
Luckily though, since SVR3 shares text, but not the other fields.  Therefore,
my fixes for SVR3 (we're a beta test site) will work for 4.2 with no changes to
the algorithm of propagating related window changes.  But there is one problem
area in the porting to 4.2.  I added a pointer to the immediate parent and an
array of pointers to the window's children.  This will have to change some
and I don't know exactly what would have to be done to get my routines to work
with 4.2.

I will keep y'all posted, if Mark doesn't.

		Mike Laman
		UUCP: {ucbvax,philabs,sdcsla}!sdcsvax!laman