6600pete@ucsbuxa.ucsb.edu (02/07/90)
Page I-277 of Inside Mac says: "NextWindow is a pointer to the next window in the window list, that is, the window behind this window. If this window is the farthest back (with no windows between it and the desktop), nextWindow is NIL." But it ain't necessarily so. In the midst of throwing together a quick FKEY, I needed to see if there were at least two windows open. So I checked FrontWindow and if it wasn't NIL I checked WindowPeek(FrontWindow)^.nextWindow to see if IT was NIL. Turns out that NewWindow doesn't cap the end of the window list with NIL like I would have expected it to. Lots of existing apps don't know about this and don't care. So who's supposed to cap the window list and why doesn't NewWindow do it? How can I check for two windows open without creating cosmetic ruination? ------------------------------------------------------------------------------ Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills
rcfische@polyslo.CalPoly.EDU (Raymond C. Fischer) (02/08/90)
In article <3858@hub.UUCP> 6600pete@ucsbuxa.ucsb.edu writes: >In the midst of throwing together a quick FKEY, I needed to see if there >were at least two windows open. So I checked FrontWindow and if it wasn't >NIL I checked WindowPeek(FrontWindow)^.nextWindow to see if IT was NIL. > >Turns out that NewWindow doesn't cap the end of the window list with NIL >like I would have expected it to. Lots of existing apps don't know about >this and don't care. I think you're mis-interpreting the results your seeing from this test. It is not uncommon to see 0-1 windows on the screen, and yet find that FrontWindow points to another WindowRecord, which then points to another WindowRecord. What's the explanation? To check for more than one _visible_ window, not only do you need to follow the links, but you also need to make sure each window is visible. The list _is_ capped with a NIL, but not all windows on the list are visible. Ray Fischer rcfische@polyslo.calpoly.edu
6600pete@ucsbuxa.ucsb.edu (GurgleKat [Pete Gontier]) (02/08/90)
From article <25d0a2fa.7177@polyslo.CalPoly.EDU>, by rcfische@polyslo.CalPoly.EDU (Raymond C. Fischer): > To check for more than one _visible_ window, not only do you need to > follow the links, but you also need to make sure each window is visible. > The list _is_ capped with a NIL, but not all windows on the list are visible. Apparently, you're right, but in a strange way. I wrote a simple program to make "absolutely" (heh heh) sure that the window list wasn't getting capped. I set a breakpoint after the call to NewWindow and took a look at the window record with the debugger. Strangely, even though I KNEW I had made only one call to NewWindow, the list wasn't capped. I took this as "proof." Users of THINK Pascal, of course, already see the problem. THINK Pascal does screwy things with the window list so that the "last" window in the user's app has a nextWindow field that points to the "first" THINK Pascal environment window! One would have thought (another assumption gone wrong...) that if THINK Pascal were going to go to all the trouble it does go to to create an environment for the user app that it would also give the user app its own window list. Perhaps Rich Siegel is reading this and can say why this wasn't done... or that I'm totally wrong and THINK Pascal DOES in fact make a new window list for the user app. Now, I haven't been home to the Mac yet today, so I don't know if this is exactly what's happening in this case. But I remember having run into it before, so it makes a sort of crazy sense. I'll post something in confirmation or denial some time tonight. ------------------------------------------------------------------------------ Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills
6600pete@ucsbuxa.ucsb.edu (GurgleKat [Pete Gontier]) (02/08/90)
From article <3872@hub.UUCP>, by 6600pete@ucsbuxa.ucsb.edu (GurgleKat [Pete Gontier]): > THINK Pascal does screwy things with the window list so that the "last" > window in the user's app has a nextWindow field that points to the "first" > THINK Pascal environment window! It's true! It's true! OK, let's amend that. I've looked at the situation with the debugger now, so I can say "It appears to be true! It appears to be true!" ------------------------------------------------------------------------------ Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills
jackiw@cs.swarthmore.edu (Nick Jackiw) (02/10/90)
> One would have thought (another assumption gone wrong...) that if THINK Pascal > were going to go to all the trouble it does go to to create an environment for > the user app that it would also give the user app its own window list. > Perhaps Rich Siegel is reading this and can say why this wasn't done... > or that I'm totally wrong and THINK Pascal DOES in fact make a new window list > for the user app. > Disclaimer: "Senatah, ah'm no Rich Siegel." The window list is used by Multifinder and the Window Manager, and THINK Pascal therefore can *not* tamper with it. Remember that the list is accessed by variables (you walk through actual window records), not traps. There's no way some third part (like THINK Pascal) could intervene between your application's attempts to walk that list (which must be defined to include all windows, yours and THINKS', for OS compatibility) and fob you off with some surrogate. THINK Pascal *does* however patch FrontWindow to guarantee that your program never sees a Pascal window (like Observe or Text) on *top*. This it can do without interferring with the OS' requirements of the user list. This was documented in the pre-2.0 Lightspeed manual (the Big Gray Book) someplace. > Now, I haven't been home to the Mac yet today, so I don't know if this is > exactly what's happening in this case. But I remember having run into it > before, so it makes a sort of crazy sense. I'll post something in confirmation > or denial some time tonight. > > ------------------------------------------------------------------------------ > Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa > Editor, Macker | Online Macintosh Programming Journal; mail for subscription > Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills -- _ _|\____ Nick Jackiw | Visual Geometry Project | Math Department / /_/ O> \ ------------+-------------------------+ Swarthmore College | O> | 215-328-8225| jackiw@cs.swarthmore.edu| Swarthmore PA 19081 \_Guernica_/ ------------+-------------------------+ USA