pa2027@sdcc13.ucsd.edu (Stupendous Man) (12/21/89)
Could someone please explain (perhaps with a bit of Lattice C) how to use the mutual exclude flag in the Gadget structure? The Sybex books I have give VERY brief explanations and I'm fairly new to software development. Thanks alot, -Brad -- Michael Butler - "Water, water everywhere nor any drop to drink"- S.T. Coleridge and Iron Maiden//// Brad McQuaid - When reality obscures your dreams, mind becomes a graveyard of memories, that wander like the lonely breeze... -Fates Warning, No Exit
guineau@wjg.enet.dec.com (12/21/89)
Eat This in article pa2027@sdcc13.ucsd.edu (Stupendous Man) <Michael Butler> writes: > Could someone please explain (perhaps with a bit of Lattice C) how > to use the mutual exclude flag in the Gadget structure? The Sybex > books I have give VERY brief explanations and I'm fairly new to > software development. Thanks alot, I don't believe Mutual Exclude was ever implemented in Intuition, so you have to do it yourself. Mutual Exclude just means only 1 of a set of n gadgets can be "on" at a time. Clicking on a gadget in this set enables it and disables the rest. To implement Mutual Exclude, you can still use the data structures provided by Intuition. When you get an event (IntuiMessage) for a gadget with the MutualExclude bit set, just go through it's exclusion mask and "generate events" for the gadgets it excludes. By "generate events" I mean do whatever necessary to make the other gadgets think they're "off". John
mmaston@portia.Stanford.EDU (Michael Maston) (12/21/89)
In article <5802@sdcc6.ucsd.edu> pa2027@sdcc13.ucsd.edu (Stupendous Man) writes: > >Could someone please explain (perhaps with a bit of Lattice C) how >to use the mutual exclude flag in the Gadget structure? The Sybex >books I have give VERY brief explanations and I'm fairly new to >software development. Thanks alot, > Sorry Brad but I don't believe 1.3 supports mutual exclusion in Gadgets yet. Works fine in menus, but according to my docs (Intuition Reference manual) it is just ignored if you try to use it with the gadgets. Still have to do it by hand in your coding. Have fun! >-Brad Michael Mason "Every man has to believe in something....I believe I'll have another beer."
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/27/89)
In <9147@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes: >In article <7052@shlump.nac.dec.com> guineau@wjg.enet.dec.com () writes: >>To implement Mutual Exclude, you can still use the data structures provided > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>by Intuition. When you get an event (IntuiMessage) for a gadget with the > ^^^^^^^^^^^^ >>MutualExclude bit set, just go through it's exclusion mask and >>"generate events" for the gadgets it excludes. By "generate events" I mean do >>whatever necessary to make the other gadgets think they're "off". >> >>John > >And MARKV@kuhub.cc.ukans.edu (MARK GOODERUM - UNIV. OF KANSAS ACS - MARKV@UKANVAX) >writes: > >>Although you are free to use the field on your own to track things manually > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>I have no idea if this would break in the future if this field did begin to >>get used. > >>Mark Gooderum Only... \ Merry Christmas !!! > >WRONG! Under no circumstances should you help yourself to a field that >the system reserves for possible future use. If we were to implement >mutual exclusion using this field, yet you were using the field for >your own implementation, how well do you think the two would co-exist? > >Not very well at all. Whoa! That field is specified, in the latest includes I have, as being the proper place to specify gadget mutual exclude. It is most definitely NOT specified as being reserved, nor are there any warnings against using it as a gadget mutual exclude field. While I fully realize that gadget mutual exclude does not work in the current release, that is completely beside the point. >The rule is simple: Make sure all unused or reserved fields are properly >initialized (normally to all zeros). 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. >You have plenty of other places to store your own data. We generally don't. > >In summary, we reserve the right to use the MutualExclude field of gadgets >for anything we please, which may not even be Mutual Exclusion. Correctly >written programs leave these fields NULL. We can't guarantee compatibility >of incorrectly written programs with future revisions of the Amiga hardware >and software. Do you reserve the right to make GRELBOTTOM suddenly mean GRELRIGHT, or to change the call to OpenLibrary() to DoIO()? Correctly written operating systems do what the documentation says they do. It is an unfortunate fact of life that bugs can happen. The proper thing to do in the case of this particular bug is to either implement this field for its originally intended purpose, leave it alone and let the authors use it for their own mutual exclude routines, or to document it as being reserved, and wait a reasonable length of time (a few releases perhaps), before using it for something else. If CBM decides to use this field for something other than gadget mutual exclude, you can expect to have to defend your actions against a flood of protest, and to my mind, your position will be indefensible. >There is a fairly long history of such violations (using MOVESR instead >of GetCC(), not putting image data into chip memory, etc.). Please learn >from these kinds of mistakes instead of attempting to create new ones >or worse, encourage them. These are entirely different matters, and not even close to being analogous. 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. This is not a flame... yet. It is a vehement plea for sanity. There are enough programs out there already that purposely or inadvertently violate the rules. The last thing we need is for CBM to pull the rug out from under us by changing the rules in mid-stream. Please reconsider your position on this matter. > Peter Cherna, Software Engineer, Commodore-Amiga, Inc. > {uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com >My opinions do not necessarily represent the opinions of my employer. -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 | +-----------------------------------------------------------------------+
peter@cbmvax.commodore.com (Peter Cherna) (12/28/89)
In article <7052@shlump.nac.dec.com> guineau@wjg.enet.dec.com () writes: > >Mutual Exclude just means only 1 of a set of n gadgets can be "on" at a time. >Clicking on a gadget in this set enables it and disables the rest. > >To implement Mutual Exclude, you can still use the data structures provided ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >by Intuition. When you get an event (IntuiMessage) for a gadget with the ^^^^^^^^^^^^ >MutualExclude bit set, just go through it's exclusion mask and >"generate events" for the gadgets it excludes. By "generate events" I mean do >whatever necessary to make the other gadgets think they're "off". > >John And MARKV@kuhub.cc.ukans.edu (MARK GOODERUM - UNIV. OF KANSAS ACS - MARKV@UKANVAX) writes: >Although you are free to use the field on your own to track things manually ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >I have no idea if this would break in the future if this field did begin to >get used. >Mark Gooderum Only... \ Merry Christmas !!! WRONG! Under no circumstances should you help yourself to a field that the system reserves for possible future use. If we were to implement mutual exclusion using this field, yet you were using the field for your own implementation, how well do you think the two would co-exist? Not very well at all. The rule is simple: Make sure all unused or reserved fields are properly initialized (normally to all zeros). You have plenty of other places to store your own data. We generally don't. In summary, we reserve the right to use the MutualExclude field of gadgets for anything we please, which may not even be Mutual Exclusion. Correctly written programs leave these fields NULL. We can't guarantee compatibility of incorrectly written programs with future revisions of the Amiga hardware and software. There is a fairly long history of such violations (using MOVESR instead of GetCC(), not putting image data into chip memory, etc.). Please learn from these kinds of mistakes instead of attempting to create new ones or worse, encourage them. -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com My opinions do not necessarily represent the opinions of my employer. "A friend of mine is into Voodoo Acupuncture. You don't have to go. You'll just be walking down the street and ..... oooohhh, that's much better..." - Steven Wright
bevis@EE.ECN.PURDUE.EDU (Jeff Bevis) (12/28/89)
In article <5802@sdcc6.ucsd.edu>, pa2027@sdcc13.ucsd.edu (Stupendous Man) writes: > >Could someone please explain (perhaps with a bit of Lattice C) how >to use the mutual exclude flag in the Gadget structure? The Sybex It doesn't function! (ie, it's not implemented) That's a shame, too, because writing exclusion code over and over is a real nuisance. By the way, how does one preset and adjust TOGGLESELECT GADGHCOMP type gadgets? I always get weird results with them... Any suggestions, like RefreshGList()'ing in some creative fashion? +--------------------------------+--------------------------------------------+ | Jeff Bevis | "But I don't like spam!" | | bevis@en.ecn.purdue.edu | Give me Amiga or nothing at all. | +--------------------------------+--------------------------------------------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/29/89)
Warning: long article ahead In <22023@usc.edu>, papa@pollux.usc.edu (Marco Papa) writes: >In article <947@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>In <9147@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes: >>>WRONG! Under no circumstances should you help yourself to a field that >>>the system reserves for possible future use. If we were to implement >>>mutual exclusion using this field, yet you were using the field for >>>your own implementation, how well do you think the two would co-exist? >>> >>>Not very well at all. >> >>Whoa! That field is specified, in the latest includes I have, as being the >>proper place to specify gadget mutual exclude. It is most definitely NOT >>specified as being reserved, nor are there any warnings against using it as a >>gadget mutual exclude field. While I fully realize that gadget mutual exclude >>does not work in the current release, that is completely beside the point. > >Sorry, Larry, but here I have to agree with CBM. That field has been documented >as "NOT IMPLEMENTED" from the first release of the AutoDocs, to the last one >I have (the ones for 1.3). Marco, that field has been documented as _not YET implemented_. From the very beginning, the wording of the statements regarding it ahve varied between 'it doesn't work in this release' to 'still not provided'. (para. 4.6.1, Readmes for Intuituion on the ReadMe1.3 disk that is part of the 'Native Developer Update disk set). The clear implication is that it was to be implemented in some future release. > It has NEVER been listed for "private application >use" as you (and the other guy) seem to imply it is. The fact that it is >not implemented, means that if you set it, that won't have any result >with this release. Oh, I see, you think I want to use it for something other than mutual exclusion of gadgets, perhaps for storing phone numbers or something. I assure you that what I want to do is to use it for its intended purpose, and to provide its intended functionality within my own programs until such time as it is implemented in the OS. I _know_ there is no result. That's the whole point. The field has been provided, and it doesn't do what it should do. When any other system function of structure flag doesn't do what I want it to do, I supply my own code to make it do what I want. Is that A Bad Thing? I know it can be, but it need not be. It all depends on the routine itself. If you think it is automatically A Bad Thing to look at documented fields that are not marked 'private' or 'reserved' in a struct and to perform actions based upon the contents, then I would ask you how you manage to write anything non-trivial at all. >>>The rule is simple: Make sure all unused or reserved fields are properly >>>initialized (normally to all zeros). >> >>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. > >CBM has always documented it as "reserved" for toggling gadgets at the >"system" level, if and when they'll be implemented. The fact that currently >the use of the field is NOT imeplemented, does not give YOU the freedom >to fool with it at will, and then expect that future releases will always >work the same. I don't see the word 'reserved' anywhere in the definition of MutualExclude. Perhaps we are talking about two different things here. I see 'reserved' as being "This field should be set to NULL, and not used for anything at all, because we have put it here for future use, said use being undetermined at this time'. Please feel free to correct me if I'm wrong on this. The latest includes still say: /* by using the MutualExclude word, the appliprog can describe * which gadgets mutually-exclude which other ones. The bits * in MutualExclude correspond to the gadgets in object containing * the gadget list. If this gadget is selected and a bit is set * in this gadget's MutualExclude and the gadget corresponding to * that bit is currently selected (e.g. bit 2 set and gadget 2 * is currently selected) that gadget must be unselected. * Intuition does the visual unselecting (with checkmarks) and * leaves it up to the program to unselect internally */ LONG MutualExclude; /* set bits mean this gadget excludes that gadget */ Now, I am not asking anyone to allow me to use this field as something arbitrary. I am asking that CBM either implement the functionality as documented, or to allow the user to do his own MutualExclude based upon the contents of this DOCUMENTED field. Can you not see that user implemented MuEx can be written in a perfectly transparent manner that will not interfere with the system function should it ever be implemented? If CBM in fact decides not to implement MuEx of gadgets, the very least they could do is change the docs to say "if you see bits on in this field, your program should unselect the corrsponding gadgets". If they do implement MuEx, the least they can do is to leave this field alone so that those who are using it _FOR ITS INTENDED PURPOSE_ will not end up with broken programs. > Most data structures (including Gadgets) have "user defined" >fields at the end of them. That's where you can fool with. In any case it is >very easy to build "custom user gadgets", with whatever additional fields >you want by creating your own modified structure: Yes, all things are possible. It is not a matter of how many ways there are to do it. It is a matter of what is being, or has been done, and the fact that at least two other programmers have assumed that it is OK to use these bits in a manner consistent with the documentation tells me that it is not altogether unreasonable to think that there are more, and that they came to this conclusion because of the documentation supplied by CBM. >>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. > >using the MutualExclude field according to "your own specification", since >"no" specification from CBM exists (at the moment) is suicidal. Especially >when you've been warned. I refer you (again) to the excerpt from the include file above, and restate that the field does not do as I expect, that I wish to provide the functionality in my own program, and that I wish to do so in a manner both transparent and non-harmful to the system. Where have I been warned? I have seen the 'not yet' and 'still not' implemented statements. I have _NOT_ seen any warnings, dire or otherwise, saying that the field might someday be changed to mean something else. >>Do you reserve the right to make GRELBOTTOM suddenly mean GRELRIGHT, or to >>change the call to OpenLibrary() to DoIO()? Correctly written operating >>systems do what the documentation says they do. > >C'mon, larry. Give us a break. GRELBOTTOM and OpenLibrary ARE documented. >MutualExclude is not and has been reserved for future use. Sorry, MutualExclude _IS_ documented. It is _ADDITIONALLY_ documented as 'not yet implemented'. It is not documented as 'reserved', 'private', or 'do not use'. >>The proper thing to do in the case of this >>particular bug is to either implement this field for its originally intended >>purpose, leave it alone and let the authors use it for their own mutual exclude >>routines, or to document it as being reserved, and wait a reasonable length of > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>time (a few releases perhaps), before using it for something else. > >If you were doing "serious" Amiga programming (i.e. if you had gotten the >AutoDocs from CBM as a certified or commercial developer), you would know >that it IS reserved. You were doing pretty good up until now. I resent your implication that my programming is any less 'serious' than anyone else's. I AM a certified developer. I DO have the autodocs from CBM. It is NOT documented as reserved. >>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. > >Using a "system field" for user-defined operations is NOT a "legitimate" >use of that field. A comment like the one above really makes me wonder >what kind of programmer you are. You probably need a system liker MS-Windows, >where you CAN'T see almost any system fields, so that you can't mess with them >directly. Oh? I suppose you are going to tell me I can't look at NextGadget to see if there are any more in the list, and perform some perfectly valid, supported, and documented function based upon the contents of that field? And Marco, we can do without the ad hominem attacks and insults, thank you. Please keep it on the level of a discussion of the pertinent points, or take it to email. >>This is not a flame... yet. It is a vehement plea for sanity. There are enough >>programs out there already that purposely or inadvertently violate the rules. > >Really? You're message promotes "insanity", IMHO. Programs that either >purposely or inadvertently violate the "rules" should be BASHED as much as >one can. No prisoners taken :-) No.. insanity is telling the programmer that something is not yet implemented, implying that it will someday be implemented, and providing a perfectly good place to allow an application program to transparently provide the service, then decalring the function obsolete and changing the meaning of the field. >-- Marco Papa 'Doc' >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >"Xerox sues somebody for copying?" -- David Letterman >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -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 | +-----------------------------------------------------------------------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/29/89)
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. > How will the system, once (if) mutual exclude is implemented, know what to do > with that field? Is it a pointer, a magic value, junk? Ahh... well, that's the whole point of my objections, isn't it? The clear implication in everything I have read is that CBM had planned on implementing mutual exclude, and had planned on doing so via this field, and in the way documented in every include since before 1.0. > This is a *SYSTEM* field and that in itself says that if you don't use the > system function (and, right now there is none) you *MUST* respect the fact that > the field is unavailable to you. Good point, and I _can_ see the rationale. I did not interpret anything in any of the warnings in the documentation to include this. I did make some assumptions that seemed perfectly reasonable, based upon the nature of this particular circumstance, and the 'YET' in 'not yet implemented'. It makes me wonder though, how many others have made the same assumptions, and how many programs will break. Worth thinking about. >>Do you reserve the right to make GRELBOTTOM suddenly mean GRELRIGHT, or to >>change the call to OpenLibrary() to DoIO()? Correctly written operating >>systems do what the documentation says they do. It is an unfortunate fact of >>life that bugs can happen. The proper thing to do in the case of this >>particular bug is to either implement this field for its originally intended >>purpose, leave it alone and let the authors use it for their own mutual exclude >>routines, or to document it as being reserved, and wait a reasonable length of >>time (a few releases perhaps), before using it for something else. > >No, we don't change things that are defined to work. Mutual Exclude field >could be seen as a reserved field for future work. 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. > That is, we may, at one point, have hoped to add mutual exclude via that >field but have now noticed that that would not be the best way to handle that >so we change it so that the field is something more important. (Maybe even >mutual exclude) But, since there is no current mutual exclude using that field, >there is no way you can know what type of value needs to be in that field. Right. I do see that, now that you mention it, but the way it reads, and has always read to me is that it is a function that will someday be imnplemented in a well defined (and already defined) way. My mistake. I think it's a natural mistake though, and one that others could easily make. > In that way, the field is just an empty that you need to keep that way until >you know what type of values will do things. This is much like the bits in the >gadget flags. You don't set bets that are not defined yet. It may not change >the way it works now, but when that bit gets used, what will you do then? What >will the gadget do? I see these as completely different. Undefined bits are inviolate in my book too, and I do leave them alone. What bothers me is that the MutualExclude bits are defined, in both the assembler and C includes. >>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. -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 | +-----------------------------------------------------------------------+
peter@cbmvax.commodore.com (Peter Cherna) (12/29/89)
In article <8912272145.AA23577@en.ecn.purdue.edu> bevis@EE.ECN.PURDUE.EDU (Jeff Bevis) writes: >In article <5802@sdcc6.ucsd.edu>, pa2027@sdcc13.ucsd.edu (Stupendous Man) writes: >> >>Could someone please explain (perhaps with a bit of Lattice C) how >>to use the mutual exclude flag in the Gadget structure? The Sybex > >It doesn't function! (ie, it's not implemented) >That's a shame, too, because writing exclusion code over and over is a >real nuisance. The latest AmigaMail has an article on the correct supportable way of handling mutual exclusion of gadgets. AmigaMail is available by subscription and to our registered developers. For information on AmigaMail or on becoming a registered developer, send a stamped (45 cents) self-addressed envelope to: CATS - Information 1200 Wilson Drive West Chester, PA 19380 >By the way, how does one preset and adjust TOGGLESELECT GADGHCOMP type >gadgets? I always get weird results with them... Any suggestions, like >RefreshGList()'ing in some creative fashion? To quote from the Enhancer 1.2 Manual, which some (not all) of you have: "Understand that Boolean gadget rendered with Borders (instead of Images) or highlighted with surrounding boxes (GADGHBOX) are handled very simply by Intuition, and that complicated transitions done by your program (and in some cases the user's own actions) can get the rendering out of phase." To summarize, if you want to preset and adjust TOGGLESELECT gadgets they should be rendered with Images (that exactly match the select box in size and position) and highlighted by complementing (GADGHCOMP) or by an alternate image of the same size and position. As well, the gadgets must be GADGIMMEDIATE. In other words, you cannot do proper programmatic control of gadgets rendered with borders and text, and highlighted by complementing. If you should happen to find some combination of steps that appears to work, heed this warning: ***You may be counting on side-effects that we don't promise to maintain in future releases of the operating system***. >+--------------------------------+--------------------------------------------+ >| Jeff Bevis | "But I don't like spam!" | >| bevis@en.ecn.purdue.edu | Give me Amiga or nothing at all. | >+--------------------------------+--------------------------------------------+ -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com My opinions do not necessarily represent the opinions of my employer. "A friend of mine is into Voodoo Acupuncture. You don't have to go. You'll just be walking down the street and ..... oooohhh, that's much better..." - Steven Wright
a464@mindlink.UUCP (Bruce Dawson) (12/29/89)
Hmmm. If I were an Amiga programmer (and I am) and I bought Lattice C 5.0
(and I did) and I read the intuition.h include file (and I did) I would get the
impression that the mutual exclude field is there, works, and should be used.
The include file spends ten lines explaining exactly how mutual exclude works,
in excruciating detail, without ever mentioning that the function doesn't work
at all.
I suppose this might be Lattice's fault, but I doubt it.
Basically, this is ridiculous. Ignoring for a moment the issue of what
the developer can do after he finds out (somehow) that MutualExclude doesn't
work, there is a separate issue here of extremely misleading documentation.
Unless you want to make it a requirement that anybody who wants to do any Amiga
programming at all must read every single manual, autodocs, AmigaMail etc.
before writing the first line of code, you should get rid of that misleading
description. Over the years I have heard a great number of people ask 'Why
can't I get MutualExclude to work' and I'm really surprised that it's _still_
documented as working!
Back to the main issue: Given the documentation in the include files
(there may be more, but you're crazy if you think that all programmers read all
of the documentation) it would seem to me that a significant percentage of
programmers will use this field to implement there own mutual exclusion.
Perhaps we could get a professor of semantics to decide whether this is correct
or not, but the bitter reality is that there MUST already be enough programs
out there using that field that you can not safely start using it yourself in
an incompatible way without breaking more innocent programs than you have any
right to.
I agree with Larry. Until the include files have been changed to
specifically say that the field is reserved and announcements have been made in
as many places as possible (since not everybody is going to read the include
files and look for changes) and a couple of years have been waited, you're
risking a lot of very ugly gadgets if you implement that field in an
incompatible way.
.Bruce.papa@pollux.usc.edu (Marco Papa) (12/29/89)
In article <947@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <9147@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes: >>WRONG! Under no circumstances should you help yourself to a field that >>the system reserves for possible future use. If we were to implement >>mutual exclusion using this field, yet you were using the field for >>your own implementation, how well do you think the two would co-exist? >> >>Not very well at all. > >Whoa! That field is specified, in the latest includes I have, as being the >proper place to specify gadget mutual exclude. It is most definitely NOT >specified as being reserved, nor are there any warnings against using it as a >gadget mutual exclude field. While I fully realize that gadget mutual exclude >does not work in the current release, that is completely beside the point. Sorry, Larry, but here I have to agree with CBM. That field has been documented as "NOT IMPLEMENTED" from the first release of the AutoDocs, to the last one I have (the ones for 1.3). It has NEVER been listed for "private application use" as you (and the other guy) seem to imply it is. The fact that it is not implemented, means that if you set it, that won't have any result with this release. >>The rule is simple: Make sure all unused or reserved fields are properly >>initialized (normally to all zeros). > >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. CBM has always documented it as "reserved" for toggling gadgets at the "system" level, if and when they'll be implemented. The fact that currently the use of the field is NOT imeplemented, does not give YOU the freedom to fool with it at will, and then expect that future releases will always work the same. Most data structures (including Gadgets) have "user defined" fields at the end of them. That's where you can fool with. In any case it is very easy to build "custom user gadgets", with whatever additional fields you want by creating your own modified structure: struct MyGadget { struct Gadget gad; long extension1; char *extension2; BOOL togglegad; } This is portable, and will work with future releases as well. >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. using the MutualExclude field according to "your own specification", since "no" specification from CBM exists (at the moment) is suicidal. Especially when you've been warned. >Do you reserve the right to make GRELBOTTOM suddenly mean GRELRIGHT, or to >change the call to OpenLibrary() to DoIO()? Correctly written operating >systems do what the documentation says they do. C'mon, larry. Give us a break. GRELBOTTOM and OpenLibrary ARE documented. MutualExclude is not and has been reserved for future use. >The proper thing to do in the case of this >particular bug is to either implement this field for its originally intended >purpose, leave it alone and let the authors use it for their own mutual exclude >routines, or to document it as being reserved, and wait a reasonable length of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >time (a few releases perhaps), before using it for something else. If you were doing "serious" Amiga programming (i.e. if you had gotten the AutoDocs from CBM as a certified or commercial developer), you would know that it IS reserved. >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. Using a "system field" for user-defined operations is NOT a "legitimate" use of that field. A comment like the one above really makes me wonder what kind of programmer you are. You probably need a system liker MS-Windows, where you CAN'T see almost any system fields, so that you can't mess with them directly. >This is not a flame... yet. It is a vehement plea for sanity. There are enough >programs out there already that purposely or inadvertently violate the rules. Really? You're message promotes "insanity", IMHO. Programs that either purposely or inadvertently violate the "rules" should be BASHED as much as one can. No prisoners taken :-) -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/29/89)
In <22034@usc.edu>, news@usc.edu (USENET News) writes: >From: papa@pollux.usc.edu (Marco Papa) >Path: pollux.usc.edu!papa > >Only one comment, and then I'm on to another subject. Fine by me. I've pretty much said my piece, except to comemnt on this. > The following is >quoted verbatim from an article in Amigamail (which all developers get as >part of the developer's fee), by Peter Cherna of Commodore: > >"Even in the latest release of the system, V1.3, mutual exclusion of gadgets >has not been implemented. In fact, if Commodore-Amiga ever does provide >system support for the mutual exclusion of gadgets, the method used may well >be different from the method outlined in the Intuition Reference Manual". > >So, you've been warned. If you read that as "I can use MutualExclude for >my own purposes", be my guest. I can bet, your program will likely break. No, I wouldn't read it that way. I would read it as being a warning to not use the field. Unfortunately, my 'complete set' of Amigamails goes up to #14 (lead article, 'The Amiga Virus', by Bill Koester). I have not received further issues as yet. The article in question is not included. This brings up the following comments: 1. Not everyone who programs, gets Amigamail, or is even aware of it. 2. It's a little late in the game to say it might be changed in 1.4 -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 | +-----------------------------------------------------------------------+
mks@cbmvax.commodore.com (Michael Sinz - CATS) (12/29/89)
In article <947@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <9147@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes: [stuff deleted...] >> >>And MARKV@kuhub.cc.ukans.edu (MARK GOODERUM - UNIV. OF KANSAS ACS - MARKV@UKANVAX) >>writes: >> >>>Although you are free to use the field on your own to track things manually >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>I have no idea if this would break in the future if this field did begin to >>>get used. >> >>>Mark Gooderum Only... \ Merry Christmas !!! >> >>WRONG! Under no circumstances should you help yourself to a field that >>the system reserves for possible future use. If we were to implement >>mutual exclusion using this field, yet you were using the field for >>your own implementation, how well do you think the two would co-exist? >> >>Not very well at all. > >Whoa! That field is specified, in the latest includes I have, as being the >proper place to specify gadget mutual exclude. It is most definitely NOT >specified as being reserved, nor are there any warnings against using it as a >gadget mutual exclude field. While I fully realize that gadget mutual exclude >does not work in the current release, that is completely beside the point. > >>The rule is simple: Make sure all unused or reserved fields are properly >>initialized (normally to all zeros). > >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. How will the system, once (if) mutual exclude is implemented, know what to do with that field? Is it a pointer, a magic value, junk? This is a *SYSTEM* field and that in itself says that if you don't use the system function (and, right now there is none) you *MUST* respect the fact that the field is unavailable to you. > >>You have plenty of other places to store your own data. We generally don't. >> >>In summary, we reserve the right to use the MutualExclude field of gadgets >>for anything we please, which may not even be Mutual Exclusion. Correctly >>written programs leave these fields NULL. We can't guarantee compatibility >>of incorrectly written programs with future revisions of the Amiga hardware >>and software. > >Do you reserve the right to make GRELBOTTOM suddenly mean GRELRIGHT, or to >change the call to OpenLibrary() to DoIO()? Correctly written operating >systems do what the documentation says they do. It is an unfortunate fact of >life that bugs can happen. The proper thing to do in the case of this >particular bug is to either implement this field for its originally intended >purpose, leave it alone and let the authors use it for their own mutual exclude >routines, or to document it as being reserved, and wait a reasonable length of >time (a few releases perhaps), before using it for something else. No, we don't change things that are defined to work. Mutual Exclude field could be seen as a reserved field for future work. That is, we may, at one point, have hoped to add mutual exclude via that field but have now noticed that that would not be the best way to handle that so we change it so that the field is something more important. (Maybe even mutual exclude) But, since there is no current mutual exclude using that field, there is no way you can know what type of value needs to be in that field. In that way, the field is just an empty that you need to keep that way until you know what type of values will do things. This is much like the bits in the gadget flags. You don't set bets that are not defined yet. It may not change the way it works now, but when that bit gets used, what will you do then? What will the gadget do? > >If CBM decides to use this field for something other than gadget mutual >exclude, you can expect to have to defend your actions against a flood of >protest, and to my mind, your position will be indefensible. > >>There is a fairly long history of such violations (using MOVESR instead >>of GetCC(), not putting image data into chip memory, etc.). Please learn >>from these kinds of mistakes instead of attempting to create new ones >>or worse, encourage them. > >These are entirely different matters, and not even close to being analogous. > >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. > >This is not a flame... yet. It is a vehement plea for sanity. There are enough >programs out there already that purposely or inadvertently violate the rules. >The last thing we need is for CBM to pull the rug out from under us by changing >the rules in mid-stream. Please reconsider your position on this matter. > >> Peter Cherna, Software Engineer, Commodore-Amiga, Inc. >> {uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com >>My opinions do not necessarily represent the opinions of my employer. > >-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. | \----------------------------------------------------------------------/
ridder@elvira.enet.dec.com (Hans Ridder) (12/30/89)
In article <22023@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >Most data structures (including Gadgets) have "user defined" fields at >the end of them. That's where you can fool with. In any case it is >very easy to build "custom user gadgets", with whatever additional >fields you want by creating your own modified structure: > >struct MyGadget { > struct Gadget gad; > long extension1; > char *extension2; > BOOL togglegad; >} > >This is portable, and will work with future releases as well. ^^^^^^^^^^^^^^^ Just one question. What if Commodore adds some stuff to the Gadget structure making it larger? You'd have to re-compile your code with new includes, or else their new larger Gadget structure would overlay your "extensions". So really, the *binary* code could possibly not work with future releases. No? I think your first sentence above was right on the mark though. I would suggest using the "User" field directly, or as a pointer to your extension structure. Then future changes to the size of a structure would not affect you, and your *binary* would be compatible. >-- Marco Papa 'Doc' -hans ======================================================================== Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
a464@mindlink.UUCP (Bruce Dawson) (12/30/89)
If Commodore-Amiga is saying in Amigamail that mutualexclusion may never
be implemented, or may be implemented differently, why do the include files
still (after more than four years) still say differently?
And, does Commodore care about the hundreds (thousands?) of programmers,
professional and amateur, that are not registered developers?
Not all programmers read AmigaMail. It should be possible to program the
Amiga without having to be a registered developer. If you implement
MutualExclude in a way contradictory to the way it has been documented for four
years in the includes, don't be surprised if you break a lot of programs, and
be prepared to take some of the blame.
.Bruce.ridder@elvira.enet.dec.com (Hans Ridder) (12/30/89)
I'm not interested in adding fuel to the debate over what is and what is not proper for developers and Commodore to do with various defined/undefined used/unused fields in varous structures, but I think it's possible for Commodore end the discussion about MutualExclude rather simply. I think it's clear to anyone writing programs using Intuition that mutual exclusion is a Good Thing (or a Necessary Thing even.) So we know we need it, the great debate seems to be, how are we going to get it. I think I have a suggestion which might work. If Commodore were to say that it's OK for developers to use the MutualExclude field for mutual exclusion (within defined guidelines), then we could use it now. When Commodore decides to implment it in Intuition, it wouldn't hurt a thing. In other words, I think it's possible for both Intuition *and* your program to do mutual exclusion using the MutualExclude field as long as we (developers and Commodore) agree on how to use it. All we need is some guidance from Commodore on *how* to properly use it. So, is it workable? Am I totally wedged? Just trying to chill out the discussion a bit.... -hans ======================================================================== Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
news@usc.edu (USENET News) (12/30/89)
>I don't see the word 'reserved' anywhere in the definition of MutualExclude. >Perhaps we are talking about two different things here. I see 'reserved' as >being "This field should be set to NULL, and not used for anything at all, >because we have put it here for future use, said use being undetermined at this >time'. Please feel free to correct me if I'm wrong on this. From: papa@pollux.usc.edu (Marco Papa) Path: pollux.usc.edu!papa Only one comment, and then I'm on to another subject. The following is quoted verbatim from an article in Amigamail (which all developers get as part of the developer's fee), by Peter Cherna of Commodore: "Even in the latest release of the system, V1.3, mutual exclusion of gadgets has not been implemented. In fact, if Commodore-Amiga ever does provide system support for the mutual exclusion of gadgets, the method used may well be different from the method outlined in the Intuition Reference Manual". So, you've been warned. If you read that as "I can use MutualExclude for my own purposes", be my guest. I can bet, your program will likely break. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
papa@pollux.usc.edu (Marco Papa) (12/30/89)
In article <555@shodha.dec.com> ridder@elvira.enet.dec.com (Hans Ridder) writes: >In article <22023@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >>Most data structures (including Gadgets) have "user defined" fields at >>the end of them. That's where you can fool with. >I think your first sentence above was right on the mark though. >I would suggest using the "User" field directly, or as a pointer to >your extension structure. Then future changes to the size of a >structure would not affect you, and your *binary* would be compatible. Absolutely. That's in fact how I recall Commodore implemented the tag structure Extensions to support the VGA and Viking monitors. Make the user-defined field as pointer to a user-defined "struct" with whatever fields you want, and all should be cool for future releases (i.e. nobody should be able to fool with YOUR OWN extension). -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/31/89)
In <9173@cbmvax.commodore.com>, mks@cbmvax.commodore.com (Michael Sinz - CATS) writes: >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: >>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? > >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. That would be the general idea, a non-harmful procedure, should the methodology be implemented in the manner described in the docs. This would have the advantage of being easily patched on existing binaries should the system start doing it for us. > [ much deleted ... ] Please note that I am not fanatic about actually having the use of this field. I can see a lot of other ways of doing it, and _I_ certainly won't use the field. My only concern at this point is that others have used it, and that their code will break in a future release. I sincerely hope this is minimal, and that most programmers did not use the field. >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) Thanks. > [ talk of where the blame lies deleted ... ] I am less interested in assigning blame than I am in seeing as smooth and painless a transition to the new release as possible. I care about this machine, a lot, as I'm sure many folks reading this are aware. I may be off base sometimes, and I have been on some points I raised in this discussion, but I do care, and want to see things done right. Thanks for the rational discussion Michael. -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 | +-----------------------------------------------------------------------+
phorgan@cup.portal.com (Patrick John Horgan) (12/31/89)
Have to agree with C= on this one...it seemed obvious to me at first reading...The system owns system fields and that's it.:) BTW, please try to minimize the size of the stuff you're includeing from previous postings...most editors will delete...it's frustrating when this all hits our node at once and we read the same stuff over and over and over and...you get the idea...Just a hint to give us context, or some careful summarizing is nice:) In this thread some of the articles have gotten completely unreadable...I can hardly find the 10 or 20 new lines in the hundreds of included lines...I'd like to point out Matt Dillon as someone who is an example of how to do it quite well...(Sorry you're leaving the net Matt:( ) Thanks, Patrick Horgan phorgan@cup.portal.com
a464@mindlink.UUCP (Bruce Dawson) (12/31/89)
The documented procedure can quite easily work. Since all system gadgets go at the very beginning of the list, you simply have to start the counting from the first user gadget. Should be no problem. Aren't the system gadgets ignored in a similar way when you AddGadget() already? .Bruce.
mks@cbmvax.commodore.com (Michael Sinz - CATS) (12/31/89)
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. | \----------------------------------------------------------------------/
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (12/31/89)
[for some reason, I just don't believe in email today...] In article <555@shodha.dec.com> ridder@elvira.enet.dec.com (Hans Ridder) writes: >Just one question. What if Commodore adds some stuff to the Gadget >structure making it larger? You'd have to re-compile your code with >new includes, or else their new larger Gadget structure would overlay >your "extensions". So really, the *binary* code could possibly not >work with future releases. No? If Commodore changed the size of the Gadget structure, it would break *every*single*program* which declares its own gadgets. How many programs have you seen with initialization expressions like struct Gadget gidget = { gidget gadget stuff }; hmm? If Commodore did change the size of the Gadget structure, they would have to use one of the currently undefined flag bits to indicate whether this was a fat or skinny gadget structure, and handle skinny gadget structures like they used to. Enclosing a gadget structure inside a structure of your own adds no new constraints or potential incompatibilities. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
hcobb@walt.cc.utexas.edu (Henry J. Cobb) (12/31/89)
Mr Sinz is right, the documented procedure would not work. Why not use the field as a bit-map, whenever a gadget becomes selected any other gadgets with which it has a matching bit set, is deselected. Example: Gadget A has bits 2 & 3 set Gadget B has bits 4 & 6 set Gadget C has bits 3 & 6 set A and B will not deactivate each other but C will exclude both. If a gadget has no bits set it neither excludes nor is excluded by any other gadget. Henry J. Cobb hcobb@walt.cc.utexas.edu
jms@doctor.Tymnet.COM (Joe Smith) (12/31/89)
In article <22900@ut-emx.UUCP> hcobb@walt.cc.utexas.edu (Henry J. Cobb) writes: > Mr Sinz is right, the documented procedure would not work. Why not use >the field as a bit-map, whenever a gadget becomes selected any other gadgets >with which it has a matching bit set, is deselected. Before adding suggestions to "fixing" the mutual exclude "problem", you must first answer the question "Why doesn't mutual exclude work with gadgets?". To get some insight to the problem, one must first answer the question "Which bit is assigned to my first gadget?", since without this information there is no way to set the proper bit in the bitmask. Right now, it appears that the number assigned to the first user gadget is the first one after the numbers assigned to the system gadgets, and that number can (and probably will) change in the next release. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
ridder@elvira.enet.dec.com (Hans Ridder) (01/01/90)
In article <22900@ut-emx.UUCP> hcobb@walt.cc.utexas.edu (Henry J. Cobb) writes: > [Henry describes a method where the position of bits in the mutual > exclude field *is not* related to the position of a gadget in the > list] It's a great idea. I can see one problem though. You can't have a gadget "X" which excludes "Y", but "Y" doesn't exclude "X". In other words, with your suggestion, exclusion must be a two-way association. I think most uses of exclusion could live with this though. Are there any usefull reasons why you would need one-way exclusion? Although I hate to use a "limited" solution to a problem which might restrict future funtionality, this could be an answer. Let's keep the productive discussion up! -hans ======================================================================== Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
ridder@elvira.enet.dec.com (Hans Ridder) (01/01/90)
In article <897@doctor.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >In article <22900@ut-emx.UUCP> hcobb@walt.cc.utexas.edu (Henry J. Cobb) writes: >> Mr Sinz is right, the documented procedure would not work. Why not use >>the field as a bit-map, whenever a gadget becomes selected any other gadgets >>with which it has a matching bit set, is deselected. > >"Which bit is assigned to my first gadget?", since without this information >there is no way to set the proper bit in the bitmask. No, you missed it. His idea was to remove the "positional" meaning of the bits altogether. Go back and re-read his posting, it's a good idea (with one limitation I already posted about). -hans ======================================================================== Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
jms@tardis.Tymnet.COM (Joe Smith) (01/03/90)
In article <22900@ut-emx.UUCP> hcobb@walt.cc.utexas.edu (Henry J. Cobb) writes: > Mr Sinz is right, the documented procedure would not work. Why not use >the field as a bit-map, whenever a gadget becomes selected any other gadgets >with which it has a matching bit set, is deselected. > Example: >Gadget A has bits 2 & 3 set >Gadget B has bits 4 & 6 set >Gadget C has bits 3 & 6 set > A and B will not deactivate each other but C will exclude both. If a >gadget has no bits set it neither excludes nor is excluded by any other gadget. After reading the follow-up postings and email from Henry, I am still missing something. In the example above, who decides that bit 2 is available for use by gadget A? If it's decided by the programmer at compile time, then the code won't work if bit 2 is one of the bits assigned to a system gadget. (It will exclude the system gadget when that was not what is desired.) If it's determined at run time, then how is this information passed back to the program? I like the idea, but how is it implemented? -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
doug@voodoo.ucsb.edu (01/03/90)
-Message-Text-Follows- In article <899@tardis.Tymnet.COM>, jms@tardis.Tymnet.COM (Joe Smith) writes... >After reading the follow-up postings and email from Henry, I am still missing >something. In the example above, who decides that bit 2 is available for use >by gadget A? If it's decided by the programmer at compile time, then the >code won't work if bit 2 is one of the bits assigned to a system gadget. >(It will exclude the system gadget when that was not what is desired.) >If it's determined at run time, then how is this information passed back to >the program? I like the idea, but how is it implemented? There are currently no system gadgets which use or need mutual exclusion Mutual exclusion would be local to a window so only the window gadgets matter as system gadgets in this discusion. System gadgets just wouldn't have any bits set. In the future, someone may actualy come up with some system gadgets which need to use mutual exclusion, but this could be handled by either alocating system mutual exclude bits from the top, and user bits from the bottom (liest significant), or by adding a new ulong for system mutual exclude bits. Most likely it will be the users responsibility to choose the bits to use. The only thing I don't like about this solution, is that it requires searching the entire list of gadgets every time a gadget with a mutual exclude bit set is selected. Douglas Peale
farren@well.UUCP (Mike Farren) (01/04/90)
In article <861@mindlink.UUCP> a464@mindlink.UUCP (Bruce Dawson) writes: > > Hmmm. If I were an Amiga programmer (and I am) and I bought Lattice C 5.0 >(and I did) and I read the intuition.h include file (and I did) I would get the >impression that the mutual exclude field is there, works, and should be used. The impression would last only until you actually tried to run your program, at which point the hard truth would make itself known. >The include file spends ten lines explaining exactly how mutual exclude works, >in excruciating detail, without ever mentioning that the function doesn't work >at all. Did you notice that the comment documentation for MutualExclude is simply in the wrong place? First - the comment immediately following the definition in the Gadget structure is character-for-character IDENTICAL with that following the definition of MutualExclude in the MenuItem structure. Second, the following line appears in the "explanation" comment: "Intuition does the visual unselecting (with checkmarks) and leaves it up to the program to unselect internally" Doesn't sound much like a Gadget MutualExclude, does it, now? More like a MenuItem MutualExclude, in which case it works perfectly. Seems to me that the screwup here was much more likely to have been a editor screwup - "block move" instead of "block copy", followed by some very simplistic editing, changing "menuitems" to "gadgets" throughout. It seems pretty clear that this is exactly what happened, since "MenuItems" has no explanatory text, and also since, if you substitute "menuitems" back in, the spacing after periods becomes much more like what one would expect... Besides - did any of you think to check the Intuition manual, which very clearly states "Currently, Intuition ignores this field"? Didn't that give you cause to check the REAL situation with MutualExclude? > Back to the main issue: Given the documentation in the include files >(there may be more, but you're crazy if you think that all programmers read all >of the documentation) it would seem to me that a significant percentage of >programmers will use this field to implement there own mutual exclusion. Only if they are incredibly dumb. The point of structures defined in a system file is that they are SYSTEM structures, used by the SYSTEM to do SYSTEM-type things. There is no license to use those structures in ANY WAY except as specifically allowed by the system. And if you use those fields as the documentation demands, and things break, then ragging on C/A to get them fixed is appropriate, but redefining the field to suit your own purpose is not. Using the field exactly as defined, but building your own routines to handle the error is more appropriate, but damn stupid programming practice - if it's broken, how do YOU know what it will take to fix it? And that DEFINITELY includes redefining the field, if necessary. MOST especially in an area where the comment, as given and applied to Gadgets, could never have been correct in the first place, as several people have eloquently pointed out. No, one doesn't have to read all of the documentation. But knowing the general state of documentation quality (these comments were, after all, written by engineers, who are notoriously variable in their language skills :-), one _does_ have to read what documentation one does read with care, and enough thought to be able to discover when things are simply wrong. And a programmer has a duty, having found a pit, to step lightly around it until clarification is at hand. -- Mike Farren farren@well.sf.ca.usa
BAXTER_A@wehi.dn.mu.oz (01/08/90)
Why not copy that which has gone before? I forget the origins - acknowleged in the source - but I used something from an early PD code example disk. You can see how I mangled it in PLOT fish 231, or Multiplot fish 293. Regards Alan
bittner@walt.cc.utexas.edu (George A. Bittner) (01/13/90)
Here's how to do it. I hope that C= will code this for us. AllocGroup(); returns a 32bit magic cookie used internally to track groups. You just use this pointer to add gadgets to groups. Returns NULL when out of space. AddToGroup(GadgetA , GroupB); Adds A to the group. Only one gadget in B can be active at a time. RemoveFromGroup(GadgetA, GroupB); A no longer excludes the gadgets in B, unless it is in another Group with them. DelleteGroup(GroupB); Returns the adminstrative space used to handle B. Internally the functions keep a list of who's in each group and only munge the gadgets that conflict, so searching takes no extra time. If I was going to do this as an add-on I would position my program high up in the input stream and produce gadget deselections that I trap after Intuition has finished with them. Henry J Cobb hcobb@ccwf.cc.utexas.edu