bruss@sdcsvax.UUCP (07/13/86)
I have constructed a requester with several boolean, TOGGLESELECT gadgets. I would like to be able to have one gadget cancel the rest (if the user selects one to be ON, the rest should automatically be turned OFF). Is there any way to do this? The Intuition manual mentions a MutualExclude flag, but it says it's not implemented!? There must be some way of doing this since applications like TextCraft do this sort of thing all the time. Help! Also, is there any way to changes the window colors from within a C program? In particular, I'm using a WBENCHSCREEN window and would like to use more than four colors as well as possibly change the original four. (Do I use SetPrefs() for this?). Brian Russ EECS Department UC San Diego ...!sdcsvax!bruss
jimm@amiga.UUCP (07/15/86)
In article <1925@sdcsvax.UUCP> bruss@sdcsvax.UUCP (Brian Russ) writes: > > I have constructed a requester with several boolean, >TOGGLESELECT gadgets. I would like to be able to have one >gadget cancel the rest (if the user selects one to be ON, the >rest should automatically be turned OFF). Is there any way >to do this? The Intuition manual mentions a MutualExclude >flag, but it says it's not implemented!? There must be some >way of doing this since applications like TextCraft do this >sort of thing all the time. Help! MutualExclude is best done by your program as follows: RemoveGadget() (or RemoveGList()) gadgets whose state you want to change (save the 'position' returned by these calls) Set or reset the SELECTED flag on each gadget to suit AddGadget() (or AddGList()) using the 'position' above RefreshGList() to refresh the gadgets imagery. This all seems to work only with GADGIMAGE and GADGHCOMP or GADGHIMAGE, BOOLEAN gadgets only. > Also, is there any way to changes the window colors >from within a C program? In particular, I'm using a >WBENCHSCREEN window and would like to use more than four colors >as well as possibly change the original four. (Do I use >SetPrefs() for this?). Hardly. The number of colors available is based on the depth of the screen's bitmap, and is not variable between windows on the same screen. Changing the original four is possible via SetPrefs, but changing the workbench colors without the user's input must be considered a Bad Thing To Do, from a user-interface perspective. Using one's own custom screen opens up more possibilities, though. > > Brian Russ > EECS Department > UC San Diego > ...!sdcsvax!bruss Welcome aboard. Your questions indicate a creative, if not actually deranged, mind.
rj@amiga.UUCP (07/15/86)
In article <1408@amiga.amiga.UUCP> jimm@homer.UUCP (Jim Mackraz) writes
about three functions that aren't in the 1.1 release of Intuition:
RemoveGList(), AddGList(), and RefreshGList(). Designers who use 1.1
must get around the absence of these routines by using the
Intuition functions RemoveGadget() and AddGadget(). Here's a question
for jimm: does AddGadget() cause the gadget's imagery to be drawn
under 1.2, or is the designer required to call RefreshGadgets()?
RJ >:-{)*jimm@amiga.UUCP (07/15/86)
In article <1409@amiga.amiga.UUCP> rj@amiga.UUCP (Robert J. Mical) writes: >In article <1408@amiga.amiga.UUCP> jimm@homer.UUCP (Jim Mackraz) writes >about three functions that aren't in the 1.1 release of Intuition: >RemoveGList(), AddGList(), and RefreshGList(). Designers who use 1.1 >must get around the absence of these routines by using the >Intuition functions RemoveGadget() and AddGadget(). Good point. I am in the 1.2 zone these days. All of the things described can be done speaking 1.1. >Here's a question >for jimm: does AddGadget() cause the gadget's imagery to be drawn >under 1.2, or is the designer required to call RefreshGadgets()? > >RJ >:-{)* You still have to call RefreshGadgets(). It is probably nicer just to refresh the gadgets you recently added, using the RefreshGList() version of the call. jimm- ;^`
lucas@amiga.UUCP (David M. Lucas) (07/16/86)
Keywords: TOGGLESELECT GADGETS
POSTED FOR ROB PECK........
Jim Mackraz had suggested that the RemoveGadget(), deselect, then AddGadget()
would work properly under 1.1 to autodeselect a gadget based on the
selection of another one (followed by a RefreshGadgets()...) to rerender
things correctly.
(note... not a critique of what he said, just additional
info re 1.1 gadget rendering)
Unfortunately, under 1.1 the rendering of a gadget
under 1.1 sometimes causes problems. For example, if a gadget is highlighted
(GADGHCOMP), calling RefreshGadgets can cause the highlighted gadget to
disappear since 1.1 does not realize that the gadget has already been
drawn.... it first draws the gadget in its unhighlighted state, then
complements the select box. In the case of a text only gadget, already
selected, means that it draws the text in (effectively creating a blank
highlighted box) then with the final step complements the select box
(effectively erasing the gadget completely). On receiving a REFRESHWINDOW
event, my own workaround (1.1 only) is to ReadPixel on a pair of gadgets,
one of which is selected. If, for the one selected, there is no
highlighting visible to ReadPixel (upper lefthand corner of the select box)
then I issue RefreshGadgets again.
Re the deselecting under 1.1, I've found a reasonable approach for
me is:
if a gadget is not selected, then set its toggleselect flag.
if a gadget gets selected, reset its toggleselect flag.
(lets the system do the highlighting for you,
resetting the flag prevents system from
deselecting the same gadget on a second
click)
on GADGETDOWN, if selected, for all other gadgets that
are associated with this one that should auto
deselect:
i = RemoveGadget each item in turn, then:
set its toggleselect flag as noted above,
if SELECTED, then reset SELECTED flag
and complement the select box
myself. I believe its ok to
do this because I removed the
gadget and now own it for the
moment... the system doesn't have
it back until I give it back.
AddGadget( gadget, i , window) this gadget
then there is no need for refresh gadgets while handling
the gadget list.
The only time that RefreshGadgets would be needed then would be on a
RefreshWindow event, watching out for the accidental (1.1 only)
derendering as noted at the top of this message. (This doesn't happen
under 1.2).
Hope this helps.
robp.
Disclaimer... it worked for me... what can I say.
Reply address: (dont know exactly how, but I am at the WELL, userid: robp)
I just come in here sometimes to marvel at the new
software releases and say hello.