Refreshing Visual appearance of gadgets in a KS 1.3 requester

[Warty]

I'm porting an example app from 68k mac System 6, to Amiga with the 1.3 kickstart. I'm thinking about a series of articles maybe for retro challenge, getting into how to start developing, with C, for 68k mac and Amiga, showing the differences, etc.

Anyway, the mac app I started on uses radio buttons. So this makes a nice example for comparing the differences in programming for the Mac "Toolbox" and for Intuition. In this case, Intuition doesn't have any direct radio button support. So I have the gadgets set up, with SelectRender and GadgetRender pointing to images with a dot, and without. I have the logic working, so that if you click one radio button, the others are flipped to off.

The problem is that I can't get the requester to refresh. The only thing that works is using the size button on the parent window to basically hide the requester, then expand it. In that event, the Amiga redraws the radio buttons with their new status.

I've tried:
- change gadget's flag to not include SELECTED, RefreshGadgets(). This "works", but with the proviso above that it doesn't visually work.
- Same as above, but with doing Remove/Add Gadget before/after the change to the flag. Similar results, but now the unselected buttons don't render. They are still there, and if you click them, they switch to "selected" mode and are visible.
- making the requester slightly bigger, then back to normal size. (hoping that would force a refresh action by the Amiga).
- making requester height 0, then back to normal size. (basically, trying to do whatever the size gadget in the parent window was doing).
- resizing parent window.height to 0 and back.
- rather than changing the SELECT part of the flag, swapping the RenderGadget image to the other one. This "works" but the same way as the above, in that it doesn't show until the requester gets redrawn.
- forgetting the images for the radio gadgets altogether, and using DrawImage. I can't get this to render anything. e.g., DrawImage(theWindow->RPort, &imgRadioOff, x, y);
- Using OnGadget and OffGadget to try and force visual refresh. The disabling/enabling works, but no visual update.

Here is current code:

void TurnOtherRadioButtonsOff(unsigned char chosenRadioBtn, unsigned char numRadioBtns, struct Window *theWindow, struct Requester *theRequester)

{

	unsigned char i;

	

	for(i = 0; i < numRadioBtns; i++)

	{

		if(i == chosenRadioBtn)

		{

			/* radioGadget[i].Flags = GADGIMAGE|GADGHIMAGE|SELECTED; */

		}

		else

		{

			/* RemoveGadget(&radioGadget[i], theWindow); */

			radioGadget[i].Flags = GADGIMAGE|GADGHIMAGE;

			/* AddGadget(&radioGadget[i], theWindow, -1);	 */		

		}

	}

	RefreshGadgets(&btnGadget[0], theWindow, theRequester);	/* starting at the first radio gadget, refresh all subsequent gadgets */

}

Snaps are, in order:

1. The dialog as you see it when it first opens. Second button was opened with the SELECTED flag set.
2. The dialog after clicking the first radio button. Both first and 2nd show as selected, but only first is (under the hood) selected at this point.
3. The dialog after making parent window very small with mouse, and opening it back up again. In this example, I used AddGadget/RemoveGadget. The non-selected gadgets have disappeared. But still are there, and still work.
4. The dialog after making parent window very small with mouse, and opening it back up again. In this example, I commented out AddGadget/RemoveGadget. This is what I want it to look like, but of course, without having to resize the parent window.

Questions:

• What I am doing wrong that the user can still access the gadgets of the parent window? I thought Requester() would act somewhat modally, and block user input on the parent window?
• What I am doing wrong that I don't get the gadget images to refresh visually?
  
  
  And yes, I know there are other ways to solve the selection of these 4 items. (menu items, etc.) That's not the point. I'm trying to A) learn about the differences for my own interest, and B) explain those to others. And I know 2.0 has support for radio buttons. But I view Mac system 4-6.x as a contemporary of Kickstart/WB 1.3, and Mac sys 7 as analogous to 2.0/2.1, and System 7.5 or maybe 8 as 3.0. In any case, Kickstart 1.3 and WB 1.3 were what most amiga users used for several years, when these machines were first out.
  

[bebbo]

I used RefreshGList...

... and in the docs:

"If you wish to do
this and be completely proper, you must RemoveGadget(), change the
GFLG_SELECTED flag, AddGadget(), and RefreshGadgets(), or the
equivalent."

[Warty]

You know, I honestly thought RefreshGList() was a v39+ thing.

It doesn't do anything different though.

[bebbo]

Originally Posted by Warty

You know, I honestly thought RefreshGList() was a v39+ thing.

It doesn't do anything different though.

It's present in kick 1.3.

what I notice in my old wierd code: I manually cleared the gadget's rectangle with the background color, befor calling
RefreshGList(g, w, 0, 1);

and refreshed the unselected too

[Warty]

When you say you cleared the gadget's rectangle, something like this?

SetAPen(theWindow->RPort, 0);

RectFill(theWindow->RPort, theRequester->LeftEdge+radioGadget[i].LeftEdge, theRequester->TopEdge+radioGadget[i].TopEdge, radioGadget[i].Width, radioGadget[i].Height );

I tried various things there, but it doesn't seem to actually get updated at all. It feels like refresh works differently in requesters compared to just a window.

[Warty]

Thanks for help. I did get it working. It was kind of combination of things. In the requester, doing AddGadget/RemoveGadget would never put the gadget back for whatever reason. I mean, it did put it back, but never visually. Taking those out, which is pretty much against everything in the documentation, makes it work.

And of course the other part was I was sloppy and passed the address of the pointer to the window, not the pointer, so the RefreshGList call was not working. <sigh>

[Bruce Abbott]

Originally Posted by Warty

What I am doing wrong that the user can still access the gadgets of the parent window? I thought Requester() would act somewhat modally, and block user input on the parent window?

No, it only blocks input to the window the requester is attached to. If you open a new window for your requester then this is the only window that gets blocked.

The easiest way to block input to any random window is simply open an invisible requester on it, then remove the requester when you want to allow input again. The requester doesn't need to have anything in it, so just initialize the entire structure to zero!

I know there are other ways to solve the selection of these 4 items. (menu items, etc.) That's not the point. I'm trying to A) learn about the differences for my own interest, and B) explain those to others. And I know 2.0 has support for radio buttons. But...

Good policy! Why limit it to requiring a later OS for one little feature, when with just a few lines of code you can get the same effect on older systems?

Standard Intuition gadgets are actually quite powerful and fun to play with, particularly if you think 'outside the box'.