Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site sdcsvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!mcnc!akgua!sdcsvax!laman From: laman@sdcsvax.UUCP (Mike Laman) Newsgroups: net.unix-wizards,net.bugs Subject: Re: CURSES sub-windows bugs - correction to Mike Laman article Message-ID: <81@sdcsvax.UUCP> Date: Sun, 23-Sep-84 13:19:39 EDT Article-I.D.: sdcsvax.81 Posted: Sun Sep 23 13:19:39 1984 Date-Received: Thu, 27-Sep-84 05:56:43 EDT References: <8657@watmath.UUCP> <1137@sdcsvax.UUCP> <8713@watmath.UUCP> Reply-To: laman@sdcsvax.UUCP (Mike Laman) Organization: EECS Dept. U.C. San Diego Lines: 70 Xref: 9621 446 In article <8713@watmath.UUCP> idallen@watmath.UUCP writes: >> From: laman@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