Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!mips!apple!oliveb!amiga!cbmvax!mks From: mks@cbmvax.commodore.com (Michael Sinz - CATS) Newsgroups: comp.sys.amiga.tech Subject: Re: Mutual Exclude Gadgets Keywords: Gadgets Message-ID: <9173@cbmvax.commodore.com> Date: 30 Dec 89 22:47:33 GMT References: <953@lpami.wimsey.bc.ca> Reply-To: mks@cbmvax.commodore.com (Michael Sinz - CATS) Organization: Commodore, West Chester, PA Lines: 147 In article <953@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <9166@cbmvax.commodore.com>, mks@cbmvax.commodore.com (Michael Sinz - CATS) writes: >>In article <947@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > >>>Yes, the rule _is_ simple, but that field is NOT specified as unused or >>>reserved. For the rule to work, it must work both ways. You cannot reasonably >>>expect to leave fields lying around that are not marked as untouchable and just >>>sort of hope that nobody will use them. Worse, you cannot reasonably specify a >>>field as being for a particular purpose and hope to defend yourself when >>>someone uses it for that purpose. >> >>Ahh, but you must understand that the field is for SYSTEM use for that purpose. >>Lets say you do it via a pointer to a special field that you invent. > >But I don't want to use it as a pointer to anything. I want to use it as it was >intended to be used, as bit significant indicators to gadgets to be unselected. Ok, even *IF* they could work, what will your program do once the system handles the task? Will your program also look at all of the gadgets and unselect and refresh them? Since this is a system field and may, at one point, be used by the system, you could not use it. For example, I at one point needed a way to send messages to my own windows that looked like Intuition messages. This was for timing. Since the way the system was set up, I never knew how many windows there were or if they wanted the ticks, I had to make a special list. However, under your thinking, I could have defined a new IDCMP bit (unused) and used that as a way to signal that the program wants that message. Then the normal ModifyIDCMP() would work just like for all other messages. I also have seen programs that say they need all of the IDCMP messages and set the port to (-1) which is ALL bits. What a surprize the will get when a new message class that they can't handle correctly comes down the pipe-line now that 1.4 (or 1.5) is out. There is, however, another item. Back a few years ago (for those of you who don't know me, I am rather new at C=. I was (and still am) a commercial developer for the Amiga since Launch, 1985) there was talk about the Mutual exclude field. This was after 1.1 (which was 1.0 with bug fixes) and as work was starting in 1.2. When you look at the old definition (which, to my surprize, still is in the include files! That is an error...) you notice almost at once that the method discribed will _NOT_ work. Why? Well, as a bit-field, things would have to stay in the correct locations. However, system gadgets (of which you have limited control) are placed before user gadgets by default. You can dynamically add and remove gadgets and thus change the position of the gadgets in the list. You could have more than 32 gadgets, with the MutualExclude gadgets too far down on the list. (They would be right place, but after the system gadgets were put in, your gadgets got moved). The whole idea, as outlined briefly in the include files and in the 1.0 intuition manual (I think 1.1 was the same) was broken. Even so, that should not change the fact that you are using a system field and doing your own work with it. Even if you did it the exact same way as the version of the OS that does Mutual Exclude, what is going to happen at that point? If your program does it in its own way, it will still continue to do that in future version of the OS. Then, you can convert the program to use the new way, using the system field to replace the field you invented and *poof* you are done. The reason we keep talking about it this way is that *WE* can not add a field to the structures anymore. Unfortunately the structures have been defined as USER (programmer) allocated and not as BLACK-BOX type of items. Thus, when we want to make enhancements, we need to do strange things such as the extended structures pointed to by this structure from that structure b*llsh*t. Or we sneak in a bit that, if set, makes the structure something else. However, you, as the programmer of the application, can expand the structure at any time. You know that the current "struct Gadget" is not going to change as otherwise current binary files would not work. I have a feeling that as things progress, there will be new classes of Intuition objects that are 100% Black-Box and then you will not be playing with our fields and we will be able to add new fields at any time. Until then, we just hope that programmers do not play with things that belong to the system. [stuff deleted... This was getting too long...] > >I think you might want to consider putting that warning in the includes, and >associate it with anything that doesn't currently work. When I write code, I >try to follow the rules. If and when I go outside the rules, I expect that my >code will break. When I go outside the rules inadvertently, I tend to be >surprised that it doesn't work. The more explicit the rules are, the more it is >explained why, the less problem there will be with broken software. It is in >CBM's best interests to promote good software in any way they can. Like I said above, I was *VERY* surprized to see this still in the include files. There will be something done about it. (as I make a note to myself) >>>All through the includes, one can find reserved and private fields. ROM >>>Stompers and Structure Twiddlers have been duly warned about the consequences >>>of messing with them. 'Proper Programmers' do not mess with them, but they >>>might be using a field DEFINED BY CBM to do what they see as perfectly >> ^^^^^^^^^^^^^^ >>>legitimate operations, fully within the letter and spirit of the documented >>>guidelines. >> >>Again, we have not yet defined HOW, so you can not define it youself unless >>you really wish to BREAK when we do define it. If the definition comes out >>be a "Pointer to the Mutual Exclude function that gets passed, in D0 the >>gadget ID and A0 the gadget address" and you used it as a pointer to a >>MX data array or a bit field, POOF, your program goes and executes random >>data at stange addresses. YOU blow up, and it would have been YOUR fault. > >Well, again, I took those bits as being defined, and the HOW as being defined. >The only thing I saw as undefined was the WHEN, which could have even been >'never'. Changing the meaning of the field is changing the meaning of the >field, regardless of whether it is being used as MutualExclude or as something >else entirely, and what the meaning is changed to has no bearing on the matter. >I figured that in the interim, we could provide our own functionality, in a >manner that would not break if the MutualExclude was implemented. > >I think you will break more than a few programs in 1.4, and some will be broken >because of this particular field. Yes, you can blame the programmer, there is >nothing to prevent you from doing that, but I see CBM as sharing that blame in >this case. Maybe something will break if we do a Mutual Exclude. And if so, I would think that we (CBM) will say that the field was a system field and should have been treated as such. However, I (as myself, not CBM) feel that the fact that the field was documented so much could have led to some confusion. I (not CBM) feel that if a program breaks because the programmer left the bit field in the Mutual exclude field that it would be the include file's fault. However, if the programmer had USED that field to do the work (even if he used the bit-field method) that was his fault. I don't see any reasonable way to defend the use of a system field in a self-implemented function. I just hope there are very few programmers that had tried the mutual exclude field, found that it did not work, and did their own but forgot to remove the values from the mutual exclude field. > >-larry > >-- >" All I ask of my body is that it carry around my head." > - Thomas Alva Edison - >+-----------------------------------------------------------------------+ >| // Larry Phillips | >| \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | >| COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | >+-----------------------------------------------------------------------+ /----------------------------------------------------------------------\ | /// Michael Sinz -- CATS/Amiga Software Engineer | | /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | | /// | |\\\/// When people are free to do as they please, | | \XX/ they usually imitate each other. | \----------------------------------------------------------------------/