ead@cbnewsd.ATT.COM (eric.a.duesing) (09/19/89)
Hello, first, I would like to thank all the people who answered my
question about screen gadgets, and I have another question (or two).
1) Could someone PLEASE send me a declaration of 2 or more gadgets
that are Mutually Exclusive? I tried it, and it doesn't seem to
work. (Read: What am I doing wrong?)
2) Is there somewhere I missed that says that all of the gadgets of
one type must be grouped in a gadget list? I had a gadget list
with several bool gadgets and some string gadgets. But, they
didn't all work until I grouped them. (Bool gadgets first, String
gadgets next.)
Thanks for the info,
Eric A. Duesing
(P.S. I am working on my first major Amiga project and I am having some
problems with the above)cmcmanis%pepper@Sun.COM (Chuck McManis) (09/21/89)
In article <1849@cbnewsd.ATT.COM> ead@cbnewsd.ATT.COM (eric.a.duesing) writes: >1) Could someone PLEASE send me a declaration of 2 or more gadgets > that are Mutually Exclusive? I tried it, and it doesn't seem to > work. (Read: What am I doing wrong?) These don't "work" either, never did. They have been documented as such in a couple of places. There are several examples on how one can do mutual exclusion of gadgets. My personal favorite is to group excluded gadgets by putting a pointer to a structure in the UserData field, and then using it to point the the gadgets that need to be excluded. For example, say I had a structure like this : struct Gadget *foo_Current; /* "global" that holds the current gadget */ struct ExcludeList { unsigned long ListType; /* Magic number ('M'+'X'+'G'+'D') */ struct Gadget *MX_Gad, /* This gadget */ **MX_Current; /* The one currently selected */ void *MX_Data; /* Further extension possible */ }; A copy of this structure is malloc'd and a pointer to it is stuck in the userdata field. All excluded gadgets in a set will point to a single "current" gadget that is in MX_Current. Let's say it was pointing at &foo_Current. So in the code itself whenever I get a gadget message I process it with : /* * One of many defines that identify the kinds of custom structure I hang * off of gadgets, if UserData is NULL is looks at location 0 but that is * always 0 (:-)) so that is ok too. Of course third party hacks that * diddle with my gadgets will crash the system... */ #define GADGET_MAGIC(g) (*((unsigned long *)((struct Gadget *)(g)->UserData))) case GADGETUP : if (GADGET_MAGIC(msg->IAddress) == MX_GAD) { e = (struct ExcludeList *) ((struct Gadget *)(msg->IAddress))->UserData; DeSelect(*(e->MX_Current)); Select(e->MX_Gad); *(e->MX_Current) = e->MX_Gad; } ... And when ever I want to know which of the possible choices are made I can look at foo_Current. >2) Is there somewhere I missed that says that all of the gadgets of > one type must be grouped in a gadget list? I had a gadget list > with several bool gadgets and some string gadgets. But, they > didn't all work until I grouped them. (Bool gadgets first, String > gadgets next.) No this is not a requirement, but all of the NextGadget pointers had better point to a valid gadget because otherwise the pointer stops there. Gadgets for a window all reside on a single linked list whose head is Window->FirstGadget and the next pointers are Gadget->NextGadget the only way to add or remove gadgets from this list are with the routines AddGadget()/RemoveGadget() and AddGList/RemGList. The list functions expect the pointers to all be correct. If you are setting up your gadgets by pointing NewWindow->FirstGadget at them then they still have to have the link list initialized properly. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "If I were driving a Macintosh, I'd have to stop before I could turn the wheel."
mks@cbmvax.UUCP (Michael Sinz - CATS) (09/21/89)
In article <125013@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: [... Much deleted ...] >/* > * One of many defines that identify the kinds of custom structure I hang > * off of gadgets, if UserData is NULL is looks at location 0 but that is > * always 0 (:-)) so that is ok too. Of course third party hacks that > * diddle with my gadgets will crash the system... > */ Gee, Chuck, you didn't really say that did you? Location 0 is undefined and can contain any value, including ODD values. (In fact, early A590 drives placed an odd value at location 0) ;-) [... Some code deleted ...] (It would have crashed anyway... ;^) >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com >These opinions are my own and no one elses, but you knew that didn't you. >"If I were driving a Macintosh, I'd have to stop before I could turn the wheel." /----------------------------------------------------------------------\ | /// 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. | \----------------------------------------------------------------------/
cmcmanis%pepper@Sun.COM (Chuck McManis) (09/22/89)
In article <7964@cbmvax.UUCP> mks@cbmvax.UUCP (Michael Sinz - CATS) writes: >Gee, Chuck, you didn't really say that did you? Location 0 is undefined >and can contain any value, including ODD values. (In fact, early A590 >drives placed an odd value at location 0) ;-) Actually I did say it, and what's really funny is that Commodore dug the exact same hole that the VAX implementation of UNIX had. *0 == 0. And what is one of the reccommended *diagnostics* of the Amiga ? Hmmm? It's MemWatch trying to guarantee that *nothing* ever writes to low memory. Endorsed by none other than C/A itself. And even your comment above about how the 590 *used* to write to location 0, but doesn't now implies that someone convinced you it was a bug too. #define RATIONAL_PROGRAMMING_FOR_A_LIVING_MODE Depending on implementation peculiarities in any C program (especially that dereferencing a NULL pointer will point at a 0) is a major no-no. #endif (Also, my code would dereference '0' as a pointer, *not* what was stored at 0, so it doesn't matter if the value in 0 is odd, it would just be returned as a long word with an odd value.) The equivalent "safe" define for the GADGET_MAGIC define is something like : #define GADGET_MAGIC(g) (((struct Gadget *)(g)->UserData != NULL) ? \ *(unsigned long *)((struct Gadget *)(g)->UserData) : 0) Your mileage may vary. Or of course you can initialize your gadgets to have the UserData pointer point at a constant 0 in your code and that would fix the problem without generating an additional implicit if-then clause with each testing of the magic number. So in summary, everyone may agree that looking at *0 is a bug but you will have a difficult time justifying breaking programs that might depend on this behaviour in the future given your implicit support in the past. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "If I were driving a Macintosh, I'd have to stop before I could turn the wheel."
mks@cbmvax.UUCP (Michael Sinz - CATS) (09/22/89)
In article <125083@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <7964@cbmvax.UUCP> mks@cbmvax.UUCP (Michael Sinz - CATS) writes: >>Gee, Chuck, you didn't really say that did you? Location 0 is undefined >>and can contain any value, including ODD values. (In fact, early A590 >>drives placed an odd value at location 0) ;-) > >Actually I did say it, and what's really funny is that Commodore dug the >exact same hole that the VAX implementation of UNIX had. *0 == 0. And >what is one of the reccommended *diagnostics* of the Amiga ? Hmmm? It's >MemWatch trying to guarantee that *nothing* ever writes to low memory. >Endorsed by none other than C/A itself. Ah, but C/A also has this wonderful MemMung program that trashes memory that is FreeMem'ed (to find all those uses of memory that has been freed) and also changes *0 to a large ODD value in the hopes that it will cause some error to show up in your program. This *IS* the recommended way to test *ALL* software on the Amiga that runs within the bounds of the system. MemWatch is also important, and endorsed by C/A but not for the protection of *0 but for the protection of *4 (AbsExecBase) and the rest of the interupt and exception vectors. In most any program, the writing to those locations is an error (even writing into *0) and MemWatch helps you find these. > ... And even your comment above >about how the 590 *used* to write to location 0, but doesn't now implies >that someone convinced you it was a bug too. The reason this changed is because the driver that was in the AutoBoot A590 had not be re-assembled without the debugging code, part of which hit location 0 with a special code that our testers could play with. It was more for the fact that we wanted to speed up the code (no more stores into *0) and reduce its size than the fact that *0 != NULL broke people. (Even though that also was a reason :-) > >#define RATIONAL_PROGRAMMING_FOR_A_LIVING_MODE >Depending on implementation peculiarities in any C program >(especially that dereferencing a NULL pointer will point at a 0) is a >major no-no. >#endif > #define WHAT_IS_THE_REAL_RULE \ Read_and_Understand(Chuck,RATIONAL_PROGRAMMING_FOR_A_LIVING_MODE) [... deleted stuff ...] > >So in summary, everyone may agree that looking at *0 is a bug but you will >have a difficult time justifying breaking programs that might depend on >this behaviour in the future given your implicit support in the past. While I will not say that *0 will or will not remain 0, it is *MY* view that we should slowly work to changing it to some large ODD random number. (Installed at BOOT time...) It may not happen in 1.4, but as we continue to push developers to write better code and use the debugging tools such as MemMung and MemWatch > >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com >These opinions are my own and no one elses, but you knew that didn't you. >"If I were driving a Macintosh, I'd have to stop before I could turn the wheel." /----------------------------------------------------------------------\ | /// 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. | \----------------------------------------------------------------------/
ranjit@grad1.cis.upenn.edu (Ranjit Bhatnagar) (09/22/89)
In article <7970@cbmvax.UUCP> mks@cbmvax.UUCP (Michael Sinz - CATS) writes: >While I will not say that *0 will or will not remain 0, it is *MY* view >that we should slowly work to changing it to some large ODD random number. There you have it! The solution to the Random Number problem and the *0 problem all wrapped up into one. Serendipity is wonderful... - ranjit :-) "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... "Such a brute that even his shadow breaks things." (Lorca)
jesup@cbmvax.UUCP (Randell Jesup) (09/23/89)
In article <125083@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <7964@cbmvax.UUCP> mks@cbmvax.UUCP (Michael Sinz - CATS) writes: >>Gee, Chuck, you didn't really say that did you? Location 0 is undefined >>and can contain any value, including ODD values. (In fact, early A590 >>drives placed an odd value at location 0) ;-) > >Actually I did say it, and what's really funny is that Commodore dug the >exact same hole that the VAX implementation of UNIX had. *0 == 0. And >what is one of the reccommended *diagnostics* of the Amiga ? Hmmm? It's >MemWatch trying to guarantee that *nothing* ever writes to low memory. >Endorsed by none other than C/A itself. And even your comment above >about how the 590 *used* to write to location 0, but doesn't now implies >that someone convinced you it was a bug too. Endorsed?? We also put out mungmem, which purposely puts evil values there. Unfortunately, not everyone has an analyzer, or they could also check (as we do) their software for reads of location 0. If "endorsing" consists of not having any way to trap it, well.... Anyone who depends on *0 == 0 is BROKEN. Period, end of sentence. Also, no program should be writing there either (which is why the A590 doesn't anymore). >#define RATIONAL_PROGRAMMING_FOR_A_LIVING_MODE >Depending on implementation peculiarities in any C program >(especially that dereferencing a NULL pointer will point at a 0) is a >major no-no. >#endif Quite. >So in summary, everyone may agree that looking at *0 is a bug but you will >have a difficult time justifying breaking programs that might depend on >this behaviour in the future given your implicit support in the past. Looking at *0? Must we add 0-detect circuits in order to not "support" it? Sorry if I sound testy, I just found some major stuff that was playing evil games and calling internal BCPL routines that shouldn't have been. Grrrr. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
addison@pollux.usc.edu (Richard Addison) (09/24/89)
In article <7980@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > Looking at *0? Must we add 0-detect circuits in order to not >"support" it? Could do this with the MMU (wish I had one). Trap all access to that page of memory, and continue if it is an allowed read (like, oh I don't know, um, maybe location 4?) but complain if it is a read from location 0. Yeah, I know it slows things down, but it's a debugging tool. > Sorry if I sound testy, I just found some major stuff that was playing >evil games and calling internal BCPL routines that shouldn't have been. Grrrr. Gee, I was wondering when you guys would notice. (-; I have a question that is unrelated to the subject line, but this remark reminded me: I've noticed that some of the ROM libraries (at least those routines I've traced to find out what is really going on) push their parameters from the registers onto the stack. Considering that at least one C compiler for the Amiga eliminates the need to have stub routines, wouldn't it be nice if the ROM routines themselves could use the registerized parameters directly? Like maybe in 1.4? Just a thought. Richard Addison
choinski@primerd.prime.com (09/28/89)
[Lineaters...very dangerous...you go first!] >1) Could someone PLEASE send me a declaration of 2 or more gadgets > that are Mutually Exclusive? I tried it, and it doesn't seem to > work. (Read: What am I doing wrong?) Yes, I am having the same problem. Could someone help us? -============================================================================- Burton Choinski choinski@env.prime.com Prime Computer, Inc. (508) 879-2960 x3233 Framingham, Ma. 01701 Disclaimer: Hey, not me man; musta been my evil twin. -============================================================================-
papa@pollux.usc.edu (Marco Papa) (09/30/89)
In article <62300009@primerd> choinski@primerd.prime.com writes: >>1) Could someone PLEASE send me a declaration of 2 or more gadgets >> that are Mutually Exclusive? I tried it, and it doesn't seem to >> work. (Read: What am I doing wrong?) >Yes, I am having the same problem. Could someone help us? MULTUALEXCLUDE gadgets have never been supported, and probably will never be. An alternative way of duplicating them with application code was also included in the 1.2 Enhancer Manual (which nobody has :-), in the "introductory" comp.sys.amiga.tech posting, and by a variety of people on this forum (myselt and Chuck among them). Time to repost the intro again? -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=