earleh@eleazar.dartmouth.edu (Earle R. Horton) (07/19/88)
I've been using Steve Brecher's TrackPopUp.a routine for some time now
to put up a small popup menu in one of my programs (I have modified it
slightly to be a C function rather than Pascal, but that's all). This
routine uses the PopUpMenuSelect trap if that is available on a Mac II,
otherwise draws the menu itself. It has performed flawlessly for me since
I got it, but no longer works correctly on a Mac II with System Tools 6.0
installed.
This routine does not use a PopUp box, but rather allows the user to
pop the menu up anywhere on the screen using for example an option
mouse-click. The routine then calculates the best place to pop up the
menu based on the mouse position and the size of the menu as found in
(*theMenu)->menuWidth, where theMenu is a MenuHandle. Previous to
System Tools 6.0, calling CalcMenuSize once at the beginning of the
program was enough to ensure that (*theMenu)->menuWidth had the
correct information in it for all calls to the TrackPopUp routine.
After installation of System Tools 6.0, sometime after the first call
to PopUpMenuSelect and before the second call, somebody puts a minus
1 (long) into (*theMenu)->menuWidth! Needless to say, all of Steve's
carefully hand-coded instructions in this routine come to naught, and
the PopUp menu generally gets drawn as far away from where you want it
as possible. I tried to determine where the menuWidth was being
changed using MacsBug's "SS" command on the field after locking the
MenuHandle. MacsBug broke in GetMCEntry a couple of times, and once
in an MDEF, before I got bored with this experiment.
The problem is fixed by calling CalcMenuSize every time before calling
TrackPopUp if ((*theMenu)->menuWidth == -1), but this is not the
point. The point is this: Why is (*theMenu)->menuWidth now being
changed to -1, even though the contents of the menu are not changed in
any way, and why is this new behavior not documented anywhere? Oh,
yeah, and one other question:
What other surprises await the unwary Macintosh programmer?
Earle R. Horton. H.B. 8000, Dartmouth College, Hanover, NH 03755tecot@Apple.COM (Ed Tecot) (07/24/88)
In article <9365@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >The problem is fixed by calling CalcMenuSize every time before calling >TrackPopUp if ((*theMenu)->menuWidth == -1), but this is not the >point. The point is this: Why is (*theMenu)->menuWidth now being >changed to -1, even though the contents of the menu are not changed in >any way, and why is this new behavior not documented anywhere? That was part of the change that permitted pop-up menus to appear on any screen, not just the main monitor on the Mac II. In general, if your menu is going to come up on a different screen, which may not be the same size, you want any menu which may come up to be recalculated. Setting menuWidth to -1 informs the Menu Manager to call CalcMenuSize again. The standard MDEF checks for this and calls CalcMenuSize if needed. Since there were relatively few applications which use custom pop-ups, this problem was not discovered until too late. It is not documented, and as such is considered antisocial behavior by this programmer. It has been fixed in 6.0.1. _emt
earleh@eleazar.dartmouth.edu (Earle R. Horton) (07/27/88)
In article <14581@apple.Apple.COM> tecot@apple.apple.com.UUCP (Ed Tecot) writes: >In article <9365@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >>..., and why is this new behavior not documented anywhere? > >... Since there were >relatively few applications which use custom pop-ups, this problem was not >discovered until too late. It is not documented, and as such is considered >antisocial behavior by this programmer. It has been fixed in 6.0.1. Thank you, Ed, for an honest explanation. There are many, many structure members and parameters which are used by "relatively few applications," but which appear in Inside Macintosh to be "public" and therefore subject to consistent handling across operating system releases. The effects of such actions are in a sense permanent, too. Even though the problem may be fixed in 6.0.1, one has no guarantees that his customers will not be using 6.0 at some future time. The programmer therefore must assume worst case, i.e. that the operating system WILL change the value of menuWidth to -1 at ALL times. Otherwise he cannot assure consistent program behavior if he is using pop-ups and needs to know their size. I asked a question in my original posting which someone at Apple may care to answer: How many other undocumented cases are there where the system modifies shared variables or variables which actually "belong" to the application, and not to the system? Is Apple in the habit of making such behavior public when they discover it, or only where they get caught? Do persons in authority at Apple frown on such behavior, or is it an established technique there? I am not banging on Apple here, but the degree of complication of the Macintosh programmer interface seems to demand some extra degree of assurance that things will not change unless they are well documented, perhaps even beforehand. If too many things like this happen, and there is too little official explanation, then programming for the Macintosh could become even more of a guessing game than it is now, hardly a cheery prospect. Earle R. Horton. H.B. 8000, Dartmouth College, Hanover, NH 03755
tecot@Apple.COM (Ed Tecot) (08/11/88)
In article <9549@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >Thank you, Ed, for an honest explanation. You're welcome. >I asked a question in my original posting which someone at Apple may >care to answer: How many other undocumented cases are there where the >system modifies shared variables or variables which actually "belong" >to the application, and not to the system? Is Apple in the habit of >making such behavior public when they discover it, or only where they >get caught? Do persons in authority at Apple frown on such behavior, >or is it an established technique there? It is hardly an established technique. When these sort of things happen, they are always honest mistakes. It is impossible for me or anyone else for that matter to know every micron of text in the five volumes of Inside Macintosh and simultaneously actually get any work done. When such discrepencies come to our attention, we do anything we can to correct it. Of couse, the most embarrasing of these always seem to surface at the least opportune moment (like the day after the disks appear in stores). >I am not banging on Apple here, but the degree of complication of the >Macintosh programmer interface seems to demand some extra degree of >assurance that things will not change unless they are well documented, >perhaps even beforehand. If too many things like this happen, and >there is too little official explanation, then programming for the >Macintosh could become even more of a guessing game than it is now, >hardly a cheery prospect. This is a reasonable expectation. But please keep in mind that we are all human here (no guarantee of this at other computer companies :-) ) and do occasionally make mistakes. Please bear with us. _emt