alexr@apple.com (Alexander M. Rosenberg) (05/25/91)
So, I've written code that calls SelectWindow on windows from other apps. It crashes Excel (2.X through 3.0) if I do that. They have some sort of bizarre WindowList. It's like this: FrontWindow (with a bogus rect) blank (presumably these are the editing areas and the icon bar, etc.) blank blank blank FrontWindow (with a different bogus rect) next window (with a similarly bogus rect) .. last window (with a similarly bogus rect) None of the other Microsoft applications have such bizarre windows. (Nor does _any_ other application I've experimented with.) My only other option is to not call SelectWindow, but to use another technique. I would probably call PostEvent for a mouseDown with very illegal co-ordinates, and patch FindWindow to recognize those co-ordinates and return the window I want in front. This has many more problems then just incompatibility with Excel. Any suggestions as to what kind of bizarre drugs they smoke at Microsoft, or a suggestion as to how to force _any_ app to bring a particular window to the front? (Excluding windoids, etc.) --------------------------------------------------------------------------- - 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. - -
pejacoby@mmm.serc.3m.com (Paul E. Jacoby) (05/29/91)
In article <13648@goofy.Apple.COM> alexr@apple.com (Alexander M. Rosenberg) writes: > >So, I've written code that calls SelectWindow on windows from other apps. > >Any suggestions as to what kind of bizarre drugs they smoke at Microsoft, or >a suggestion as to how to force _any_ app to bring a particular window to >the front? (Excluding windoids, etc.) Not that it helps _solve_ the problem at hand, but there is an INIT (old 6.0.x stuff, forgive the terminology :-) called "PopWMenu" which brings up a list of all available windows when you hold down the Control key and click the mouse. It too shows the goofy stuff with Microsoft Excel, but will indeed bring one of the 'phantom' windows to the front! Leaves the user in an odd state, but it apparently CAN be done with MS apps.... As to suggestions on drugs, I think that is more fodder for alt.bizzare or some such group :-) -- | Paul E. Jacoby, 3M Company, 3M Center, 235-3F-27 | | Maplewood, MN 55144-1000 .-----------------------------------| | => pejacoby@3m.com | I am _not_ the editor of | | (612) 737-3211 | the Radio Times. |
alexr@apple.com (Alexander M. Rosenberg) (05/30/91)
In article <1991May29.162514.20304@mmm.serc.3m.com>, pejacoby@mmm.serc.3m.com (Paul E. Jacoby) writes: > > In article <13648@goofy.Apple.COM> alexr@apple.com (Alexander M. Rosenberg) writes: > > > >So, I've written code that calls SelectWindow on windows from other apps. > > > >Any suggestions as to what kind of bizarre drugs they smoke at Microsoft, or > >a suggestion as to how to force _any_ app to bring a particular window to > >the front? (Excluding windoids, etc.) > > Not that it helps _solve_ the problem at hand, but there is an INIT (old > 6.0.x stuff, forgive the terminology :-) called "PopWMenu" which brings > up a list of all available windows when you hold down the Control key > and click the mouse. It too shows the goofy stuff with Microsoft Excel, > but will indeed bring one of the 'phantom' windows to the front! Leaves > the user in an odd state, but it apparently CAN be done with MS apps.... > > As to suggestions on drugs, I think that is more fodder for alt.bizzare > or some such group :-) > -- > | Paul E. Jacoby, 3M Company, 3M Center, 235-3F-27 | > | Maplewood, MN 55144-1000 .-----------------------------------| > | => pejacoby@3m.com | I am _not_ the editor of | > | (612) 737-3211 | the Radio Times. | > 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? --------------------------------------------------------------------------- - 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. - -
benw@microsoft.UUCP (Ben WALDMAN) (06/04/91)
In article <13744@goofy.Apple.COM> alexr@apple.com (Alexander M. Rosenberg) 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 Disclaimer: These are my own thoughts, opinions, and ideas, and in no way reflect those of my employer.
time@ice.com (Tim Endres) (06/05/91)
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. 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". 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. tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
alexr@apple.com (Alexander M. Rosenberg) (06/06/91)
In article <72724@microsoft.UUCP>, benw@microsoft.UUCP (Ben WALDMAN) writes: > > In article <13744@goofy.Apple.COM> alexr@apple.com (Alexander M. Rosenberg) 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. Inside Mac I-286 "Warning: Do not use SendBehind to deactivate a previously active window. Calling SelectWindow to make a window active takes care of deactivating the previously active window." Sounds to me like this means that you should use SelectWindow and find some other way of maintaining floating windows. As far as I can tell, every app that does floating windows does it in a different way. Maybe the world needs a tech note on suggested methods of making floating windows. > > Ben Waldman > Excel Development Team > Microsoft > > > Disclaimer: These are my own thoughts, opinions, and ideas, and in no > way reflect those of my employer. > I very much appreciate somebody from Microsoft answering my question. NetNews is probably the only place where this can happen. (For any major software company.) --------------------------------------------------------------------------- - 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. - -
alexr@apple.com (Alexander M. Rosenberg) (06/06/91)
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. - -