Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!alexr@apple.com
From: alexr@apple.com (Alexander M. Rosenberg)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Excel 3.0 and the WindowList
Message-ID: <13898@goofy.Apple.COM>
Date: 6 Jun 91 16:45:44 GMT
References: <1CE00001.he2hp6@tbomb.ice.com>
Sender: usenet@Apple.COM
Organization: Hackers Anonymous
Lines: 69

In article <1CE00001.he2hp6@tbomb.ice.com>, time@ice.com (Tim Endres) writes:
> 
> In article <72724@microsoft.UUCP>, benw@microsoft.UUCP (Ben WALDMAN) writes:
> > >I'm trying to do something similar to what "PopWMenu" does (programatically).
> > >
> > >However, "goofy stuff" isn't an acceptable result of user actions in this
> > >case. The 'phantom' windows found in Excel can be filtered out because they
> > >have no title. (Only real strings belong in a text list anyway.) My problem
> > >is that the "regular" windows in Excel aren't "regular" at all. Calling
> > >_SelectWindow on them screws things all up (read: Bus Error). "PopWMenu" and
> > >other similar things just call _SelectWindow, as I would have liked to do.
> > >
> > >Anybody from Microsoft who would care to explain their "windows" to me?
> > 
> > There's nothing unusual about the regular Excel windows.  The "weirdness"
> > that is going on here is that we maintain the several floating windows
> > by using SendBehind rather than SelectWindow (that is, to bring a window
> > to the front, it is sent behind the rear-most floating window).  If you
> > do this, your program should work (there are 4 floating windows).  Also,
> > I'm not sure that it's a good idea to check for title strings, since the
> > frontmost floating window will get a title when printing, in order to get
> > this name to appear in various print manager dialogs.
> > 
> > Ben Waldman
> > Excel Development Team
> > Microsoft
> 
> The current stream of conciousness appears to believe that the best
> means of dealing with Floating windows in Applications in general
> is to start at the *end* of the WindowList and work backwards until
> you find a window that is active (visible && hilited). This window
> is considered the "active document" and if it is not the FrontWindow(),
> then the remaining windows are considered floating.
> 

All the "brain-children" here at Apple, and _nobody_ suggested this. Sounds
like a really good idea to me.

> I am not sure how well this works with various apps, but investigation
> has shown it will work with many. The "SendBehind()" should work if
> you send the window behind the "Back Floating Window", or the first
> floating window in the list above the "active document".
> 

I'd still prefer to use SelectWindow. I think that if the windowlist does
appear "wierd" then I'll use SendBehind, otherwise use SelectWindow. (For
example, HyperCard works perfectly if you call SelectWindow (its floaters
aren't in the windowlist), MacPaint does not.)

> The biggest catch is when an application is maintaining some list
> about the order of their windows in another array, and get "caught"
> when you change the order in the WindowList, but their array does
> not change.
> 

I haven't found any problems in this area yet. Just about all apps I've
tried had problems with their floaters going behind regular app windows,
or worked fine. Then there was Excel. For unknown reasons, Excel crashed
when played with (leading to all these questions).

Now I have the real question du jour: What about movable-modals? Does
everybody follow the rule and use variant 5 for movable-modals only?

---------------------------------------------------------------------------
-  Alexander M. Rosenberg  - INTERNET: alexr@apple.com      - Yoyodyne    -
-  330 1/2 Waverley St.    - UUCP:ucbvax!apple!alexr        - Propulsion  -
-  Palo Alto, CA 94301     -                                - Systems     -
-  (415) 329-8463          - Nobody is my employer so       - :-)         -
-  (408) 974-3110          - nobody cares what I say.       -             -