zrm@prism.UUCP (08/20/85)
I've noticed that most example programs suffer from having redundant or unneccesary calls to toolbox routines. But one thing that surprised me as I was dyking out pieces of the "grow" program that shows how to use scroll bars and GrowWindow is that the window system blows out if you mouse down in the active window's grow icon and the active window's port is not the current graf port. I can't see any way around this restriction, since it has to do with the "where" field of the event, which is determined well before an application has control. This seems to be a gross violation of modularity! My guess is that the window definition function is using window-relative coordinates to determine if the mouse-down happened in the grow icon. It also seems to apply only to the grow icon since I could still drag the window without blowing out. As an alternative to this behavior the window definition function could temporarily set the graf port, or it could convert coordinates and constrain the application writer to leaving the graf port set to the window manager port if his program isn't drawing. I also can't find this restriction documented except rather indirectly: the window manager manual tells you that inactive windows can't be grown. Anyone else have this rude experience? Anyone know the cause?