OS4 Reaction programming question (beginner)

Let's say we have a gadget like following:

if((gb_StringGad = (struct Gadget *) IIntuition->NewObject(IString->STRING_GetClass(),NULL,
GA_ID, GAD_ID_String,
GA_RelVerify, TRUE,
GA_TabCycle, TRUE,
STRINGA_MaxChars, 6,
STRINGA_MinVisible, 6,
STRINGA_TextVal, pcbtempstring,
TAG_DONE)))

How can I change some attributes (e.g. text value)

IIntuition->SetGadgetAttrs(gb_StringGad, gb_WindowObj,STRINGA_TextVal, "changed");

Above code does not work, what am I missing ?

Thanks

I think you're missing the requester parameter, which can be NULL, and the TAG_DONE as the final argument, try:

@SinanSam460

Your SetGadgetAttrs() call is wrong:


1) gb_WindowObj seems to be a window object pointer but for this particular call you need a struct Window pointer. The two point to a completely different type of thing!

2) The Window pointer must be followed by a NULL requester pointer.

3) The last parameter must be a closing TAG_DONE.

This is what it should look like:

IIntuition->SetGadgetAttrs(gb_StringGad, myWindow, NULL, STRINGA_TextVal, "changed", TAG_DONE);


You can obtain the struct Window pointer when opening the window (it's the actual result of the WM_OPEN method call), or at any time later by querying the WINDOW_Window attribute through GetAttr().

It's worth noting that if the window has not yet been opened then the window argument should be NULL too.

Wouldn't it be better if the window's state was separate from whether it was open or not, such that it could be closed and opened (for example after a screenmode reset) without needing to be destroyed and reinitialised? I appreciate intuition doesn't do that but it'd be nice if the window class abstracted it.

Quote:
As broadblues says. Or use SetAttrs() instead of SetGadgetAttrs() in such a case.

@NinjaCyborg

window.class objects do not need to be destroyed or reinsitialised from scrtach when closing the (workbench) screen. they can also jump from screen to screem

In fact the window.class object will send a WMHI_ICONIFY and WMHI_UNICONIFY message to the application, which should then close and reopen the window in response. Or a WMHI_JUMPSCREEN

This is how AmigaOS4 avoids (or at least reduces the frequency of) the annoying can't close workbench screen messages when change prefs settings. Most apps will close automatically.

Some restup may be required if your gadgets needed certain pen colours or other screen specific attributes as the previous data will now be invalid.

SetGadgetAttrs() needs the window pointer and very rarely the requester pointer ( very few modern amiga programs use requesters in the original sense, most modern requesters are actually windows) to provide rendering context to the gadgets. These gadgets are often but need not be associated with a window.class object.

@trixie

Thanks for suggestion and corrections:

Now I use this, I want to change the value of string when I click close gadget.

case WMHI_CLOSEWINDOW:
IDOS->Delay(50);
printf("...");
IIntuition->GetAttr(STRINGA_TextVal,(Object*)gb_StringGad,(ULONG*)&val);
IIntuition->SetAttrs(gb_StringGad, gb_WindowObj, NULL, STRINGA_TextVal, "change", TAG_DONE);

/*laufen = FALSE;*/
break;

But nothing changes in the window...Window is already opened.

@SinanSam460

@billyfish

Thanks, now I get it :) and it is working now...

@SinanSam460

The difference between the two BOOPSI setter functions is that SetGadgetAttrs() also triggers the GM_RENDER method to update the gadget imagery, while SetAttrs() simply sets the new value without the redraw. Typically, you'll use SetGadgetAttrs() in a live window to get immediate visual response, and SetAttrs() before the window opens (or when it's iconified).

@trixie

sorry for offtiopic, but diffs between RefreshSetGadgetAttrs() and SetGadgetAttrs()?


SetGadgetAttrs autodoc:
---
Typically, the gadgets will refresh their visuals to reflect..


RefreshSetGadgetAttrs autodoc:
...
Same as SetGadgetAttrs() but refreshes the object ..

@trixie

Quote:

That's not actually true.

The difference is that SetGadgetAttrs() populates the GadgetInfo entry in the opSet message (OM_SET)



In reponse to the values of some attributes some but not all gadgets may trigger a GM_RENDER . A very rough rule of thumb is that simple gadgets will render straight away, more complex ones may not. (but might still perform setup based on the GadgetInfo)

@Jabirulo

The difference with RefreshSetGadgetAttrs() is that it will *always* force a render of the gadget if SetGadgetAttrs() would have returned a non zero value.

It's equivelent of

if(SetGadgetAttrs()) RefreshGList() .

[edit]markdown and adding that the refresh only occurs if SetGadgetAttrs() would return non zero

@broadblues

True, I have oversimplified things a little. Nevertheless, SetGadgetAttrs() and RefreshSetGadgetAttrs() often produce the same result, depending on gadget implementation.

@Jabirulo

As Andy says. RefreshSetGadgetAttrs() is a belt-and-braces call that ensures the refresh takes place after changing the attribute(s).