lippin@spam.berkeley.edu (The Apathist) (05/24/88)
I started working on a custom MBDF yesterday, and so for the first time closely examined that part of IM V's menu manager chapter. The MBDF is to be declared as returning a LONGINT, but one of the messages, GetRect (or just Rect, depending on where you look) would have it return a Rect. Now, last I heard, Pascal doesn't have provisions for returning record types, but I can ignore that, because I'm writing in C. But I still can't cram a Rect into a LONGINT; it's just too big. I also thought of returning a pointer to the Rect, but then where would I put the Rect? In the MBDF's copious global storage? Or on the heap, where it might never be disposed of? Anyone know what the deal is here? --Tom Lippincott ..ucbvax!math!lippin "We DEMAND solid facts!" --Vroomfondel
dorourke@polyslo.UUCP (David O'Rourke) (05/24/88)
In article <10241@agate.BERKELEY.EDU> lippin@math.berkeley.edu writes: >have it return a Rect. Now, last I heard, Pascal doesn't have >provisions for returning record types, but I can ignore that, because Standard Pascal can't return a Rect, but MPW pascal and LS Pascal don't seem to have any problem with returning a record type. The only pascal compiler I know of that can't return a record type is Turbo Pascal. But then you can just move it into a "var" parameter anyways. -- David M. O'Rourke Disclaimer: I don't represent the school. All opinions are mine!
elcond@garnet.berkeley.edu (Gregory Dow) (05/24/88)
In article <10241@agate.BERKELEY.EDU> lippin@math.berkeley.edu writes: >I started working on a custom MBDF yesterday, and so for the first >time closely examined that part of IM V's menu manager chapter. The >MBDF is to be declared as returning a LONGINT, but one of the >messages, GetRect (or just Rect, depending on where you look) would >have it return a Rect. Now, last I heard, Pascal doesn't have >provisions for returning record types, but I can ignore that, because >I'm writing in C. But I still can't cram a Rect into a LONGINT; it's >just too big. I also thought of returning a pointer to the Rect, but >then where would I put the Rect? In the MBDF's copious global >storage? Or on the heap, where it might never be disposed of? > >Anyone know what the deal is here? > > --Tom Lippincott > ..ucbvax!math!lippin > > "We DEMAND solid facts!" --Vroomfondel You must pass back a pointer to a Rect in response to the GetRect message. The system MBDF stores this Rect in a low-memory global. It uses the Scratch8 global at address $9FA. The system MBDF also allocates space for itself in the system heap. For my own custom MBDF, I use a custom resource of type myMB with the same ID as the MBDF to hold my data. This myMB resource is pre-loaded and locked in the application heap. I can then use this space to store all the variables my MBDF needs. I have an 8 byte section in this block where I store the Rect whose address is returned for a GetRect message. The use of the Scratch8 global by the system MBDF is undocumented, so I didn't want to rely on that method. Of course, if you want to use your MBDF for more than just your own application (such as replacing the system's MBDF), you'll have to carve out some space for yourself in the system heap and find a place to store a pointer to it (the system MBDF uses the low-memory location $B5C -- also undocumented). I got this information by looking at the assembly language source code for the system MBDF which is available on AppleLink, and by stepping through the MDBF in ROM using TMON. Writing an MBDF is not a pleasant or easy task. Good Luck. Gregory Dow ARPA: elcond@garnet.berkeley.edu Chemical Engineering Dept. UUCP: {uwvax, decvax, ihnp4, ...}!ucbvax University of California !elcond%garnet.berkeley.edu Berkeley, CA 94720 BITNET: POLYDOW@UCBCMSA
lippin@sizzlean.berkeley.edu (The Apathist) (05/24/88)
More problems: The Init message to a MBDF should cause it to allocate a structure in the system heap. But there's scant information on what that structure is. Presumably, it would contain the menu rects and some identification of open menus. Plus a mysterious field lastMBSave, which apparently does nothing but get cleared. Is this structure to be of some specific form? If so, what form? If not, what is the meaning of clearing its lastMBSave field? In fact, what *is* the lastMBSave field? Also, although the MBDF is supposed to allocate this thing, it doesn't return a reference to it. Should the pointer/handle (which one, anyway?) be stuck in some unmentioned global spot? As this thing is sitting in the system heap, I'd like to see it disposed of sometime. What takes care of that? (The dispose message isn't described as doing so.) Finally, the MBDF is supposed to try to align the top of a hierarchical menu with the item its associated with in the parent menu. How does it know where the item in the parent menu is? The MDEF doesn't have a code for telling it. Why is the MBDF handling this anyway? It has little to do with how the menu bar works. Inquiring minds want to know! --Tom Lippincott ..ucbvax!math!lippin "We demand rigidly defined areas of doubt and uncertainty" --Vroomfondel
tecot@Apple.COM (Ed Tecot) (06/01/88)
In article <10241@agate.BERKELEY.EDU> lippin@math.berkeley.edu writes: >I started working on a custom MBDF yesterday, and so for the first Don't do it! I strongly recommend that no one attempt to write a custom MBDF. Since IM 5 was published, the standard MBDF has been changed significantly; a new message has been added, and another one has been expanded. I expect it to continue to change in the future. It is very unlikely that any MBDF written will be able to deal with future system software, including the one we currently ship. It will have to evolve. Hopefully, in the future, this will change; but for now, please do not write your own menu bar definition functions. _emt