Reaction Macro party thread

I'm quite new on reaction macros and how to use them so I'll ask quetions about it in this thread.

First problem:

I'm trying to make part of a gui dynamic. I need to add a layout gadget to an existing layout gadget.

In other words I need to call AddChild on one struct Gadget * by supplying another struct Gadget *. Is that possible?

Gadget 1:
gadlist[GID_MYLAYOUT]

Gadget 2:
gadlist[GID_DYNLAYOUT] = LayoutObject, GA_ID, GID_DYNLAYOUT,..,..,..,..,End;

How do I add gadget 2 to gadget 1 as a child?


(later I will need to add button gadgets to the second layout gadget, but I figure that has the same solution)


Second, is there a reaction macro for removing gadgets for a layout as well?

@orgin

Although the macros are gradually being phased out, I find them easier to use to manage the way interfaces are built.

In order to change a layout gadgets children, LAYOUT_ModifyChild, LAYOUT_AddChild and LAYOUT_RemoveChild can be used.

These are set as attributes just like any other, and are vararg, so a tag list can follow to specify what is being changed.

Lets assume you want to add a button to a layout called layout1:

RefreshSetGadgetAttrs( layout1, win, NULL, LAYOUT_AddChild,
mynewbutton = ButtonObject, GA_ID, BUT1, GA_Text, "Boo!", ButtonEnd, TAG_DONE );

The button is added to the layout by tags in a similar way to the way it would be created in the usual tag array when creating an interface from scratch. Removal is easy:

RefreshSetGadgetAttrs( layout1, win, NULL, LAYOUT_RemoveChild, but1, TAG_DONE );

All BOOPSI objects are handled by setting attributes via methods. The macros used above expand to the methods described in the layout_gc.doc.

Simon

@All

LAYOUT_AddChild and LAYOUT_RemoveChild work but can cause lockups if the layout is already attached to a window.

Instead use LM_ADDCHILD and LM_REMOVECHILD.

No idea why the OS team added these methods rather than fix the existing methods.

@all

Okey these are my results.

Stating both parent gadget and window makes the new gadgets attach themselves to both the upper left corner of teh window as well as the parent layout gadget.

That is, I had to do this to not get rendering corruption:

IIntuition->RefreshSetGadgetAttrs(mommy, NULL, NULL, LAYOUT_AddChild, child,TAG_DONE);

Using LM_ADDCHILD doesn't do anything at all. But then again, I'm probably using it the wrong way.

This is what I tested:

IIntuition->RefreshSetGadgetAttrs(mommy, NULL or window, NULL, LM_ADDCHILD, child,TAG_DONE);

Question 3:

How do I refresh the window after adding some gadgets to it? The new gadgets doesn't show up until I resize the window.

@orgin

Quote:

LM_ADDCHILD is a method of the layout.gadget, not a TAG or macro, see layout_gc.doc:


Quote:

If you are using the window.class, see window_cl.doc:

@orgin

LM_ADDCHILD is a method not an attribute so you have to use DoMethod

struct TagItem NoDisposeTags[] = {CHILD_NoDispose, TRUE, TAG_DONE} ;

if (DoMethod(ParentObj, LM_ADDCHILD, MyWin, ChildObj, NoDisposeTags))
{
// Either call RethinkLayout on ParentObj or DoMethod(WinObj, WM_RETHINK) depends on the type of change
}
else
{
// Ooops object couldn't be added
}

Reason for the NoDisposeTags is so that the object can be added and removed multiple times.

According to the latest SDK for LAYOUT_AddChild -

Do not use this tag to add gadget objects while the layout is in an active Window. An intuition deadlock could result. Use the LM_ADDCHILD method instead.

@madmonkey&Gazelle

Okey thank you, I'll look at LM_ADDCHILD tomorrow.

Anyway, what I'm working on can be seen in this picture. It's the button rows(s) at the bottom of the Filer windows.

@orgin

Looks good, keep it coming :)

Just an information: LM_ADDCHILD is V53 -> Amiga OS4.1

BTW: Have you considered using application.library/prefsobjects/-prefsobjects- for your configuration?

@Gazelle

Although the SDK docs state V53 i.e. OS4.1, LM_ADDCHILD works under OS4.0 as well.

@Gazelle

"BTW: Have you considered using application.library/prefsobjects/-prefsobjects- for your configuration?"

Yepp, but most likey not for all configuration.

For some strange reason, LM_ADDCHILD does not return true even if the child is added.

@madmonkey
Quote:
Because it is impossible to fix the existing attributes which use the OM_SET method. Underneath there is a specific locking sequence in intuition.library which means you can't safely add and remove BOOPSI objects dynamically during an OM_SET. The ClassAct authors did not understand layout.gadget had this fundamental design flaw given they were 3rd party developers at the time. Their workaround was to use an invisible Requester to try and block user input while the BOOPSI objects were added/removed but this in turn caused deadlocks with intuition.library.

@orgin
Quote:
That bug has been fixed and will be available in a future update.

@madmonkey
Quote:
The documentation is correct and you need layout.gadget 53.2 or higher to use the new methods.

All that info in this thread is highly important and interesting ! This info solves a lot of important and nasty things.

@ssolie

"That bug has been fixed and will be available in a future update."

Okey thanks.

@ssolie

Weird LM_ADDCHILD works for me with V52.1 of layout gadget

You mention that the deadlock occurs within OM_SET. Is this the only time that the lockup can occur?

Is there a way to detect when intuition will lock up and not call LAYOUT_AddChild in these circumstances? Really thinking of OS 3.x here as this doesn't support LM_ADDCHILD and so I have to use LAYOUT_AddChild.

@madmonkey
Quote:
Nope.

If you can, just don't dynamically add/remove BOOPSI objects. It is rare you need to anyway. Usually a page.gadget can be used if you are trying to hide/unhide banks of gadgets; just switch pages.

@ssolie

Thx for the info. Sadly, the page gadget is of no use for my purposes.

A lot of the custom objects I have written use a scrollbars property with settings None, Always and Automatic.

The problem setting is Automatic as the objects dynamically add\remove scrollbars depending on the size of their content, which changes as the user interacts with the object.

Users under OS3.X will either have to put up with the lockup (v. rare due to the fudges that are already in place) or use the settings None or Always until I add some more fudges to make the problem go away entirely.

For these objects I have a cunning plan, which removes the need to dynamically add\remove the scrollbar objects and should resolve the issue.

For the GUI designer, worst case will be the need to close and reopen the window as the user adds \ removes objects to it. Won't be pretty but if that's what has to happen under OS3.x so be it.

@Gazelle

Just gone through application library trying to understand prefsobjects. I just don't see how this would benefit me. The autodoc is really badly written, it often just lists a lot of random options without stating what they do and when you're supposed to use them. There's no useful examples. It refers to an example that doesn't exist in the sdk. It would take me far far longer to understand how to use it than to just write something on my own. (which is a bit ironic as the autodoc claims just the opposite).

It's a pity that stuff like this is added without proper documentation, there's no wonder that few people use this particular functionality.

If preferences are updated I need to propagate the change to all filer programs (they are separate running programs) near instantly. I can't find out how to use the app prefs to achieve that. Writing my own file to env: lets me add a notification of the file and each time it's updated each individual filer can read the new content and update themselves. From the autodoc I can't find out if that's possible or not.