Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
109 user(s) are online (70 user(s) are browsing Forums)

Members: 2
Guests: 107

flash, emeck, more...

Headlines

 
  Register To Post  

(1) 2 »
Reaction Macro party thread
Supreme Council
Supreme Council


See User information
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?

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: Reaction Macro party thread
Supreme Council
Supreme Council


See User information
@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

Go to top
Re: Reaction Macro party thread
Just popping in
Just popping in


See User information
@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.

Go to top
Re: Reaction Macro party thread
Supreme Council
Supreme Council


See User information
@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);

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: Reaction Macro party thread
Supreme Council
Supreme Council


See User information
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.

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: Reaction Macro party thread
Just popping in
Just popping in


See User information
@orgin

Quote:
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);


LM_ADDCHILD is a method of the layout.gadget, not a TAG or macro, see layout_gc.doc:
NAME
    LM_ADDCHILD 
-- Add gadget to active layout. (V53)

    
SYNOPSIS
    uint32 result 
IDoMethodA(APTR objstruct lmAddChild msg);


Quote:
How do I refresh the window after adding some gadgets to it?


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

NAME
    WM_RETHINK 
-- Rethink an open window layout limits.

    
SYNOPSIS
    uint32 result 
IDoMethodA(APTR objMsg msg);

Go to top
Re: Reaction Macro party thread
Just popping in
Just popping in


See User information
@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.

Go to top
Re: Reaction Macro party thread
Supreme Council
Supreme Council


See User information
@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.

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: Reaction Macro party thread
Just popping in
Just popping in


See User information
@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?

Go to top
Re: Reaction Macro party thread
Just popping in
Just popping in


See User information
@Gazelle

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

Go to top
Re: Reaction Macro party thread
Supreme Council
Supreme Council


See User information
@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.

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: Reaction Macro party thread
Amigans Defender
Amigans Defender


See User information
@madmonkey
Quote:
No idea why the OS team added these methods rather than fix the existing methods.

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.

ExecSG Team Lead
Go to top
Re: Reaction Macro party thread
Amigans Defender
Amigans Defender


See User information
@orgin
Quote:
For some strange reason, LM_ADDCHILD does not return true even if the child is added.

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

ExecSG Team Lead
Go to top
Re: Reaction Macro party thread
Amigans Defender
Amigans Defender


See User information
@madmonkey
Quote:
Although the SDK docs state V53 i.e. OS4.1, LM_ADDCHILD works under OS4.0 as well.

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

ExecSG Team Lead
Go to top
Re: Reaction Macro party thread
Just can't stay away
Just can't stay away


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

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Go to top
Re: Reaction Macro party thread
Supreme Council
Supreme Council


See User information
@ssolie

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

Okey thanks.

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: Reaction Macro party thread
Just popping in
Just popping in


See User information
@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.

Go to top
Re: Reaction Macro party thread
Amigans Defender
Amigans Defender


See User information
@madmonkey
Quote:
Is there a way to detect when intuition will lock up and not call LAYOUT_AddChild in these circumstances?

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.

ExecSG Team Lead
Go to top
Re: Reaction Macro party thread
Just popping in
Just popping in


See User information
@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.

Go to top
Re: Reaction Macro party thread
Supreme Council
Supreme Council


See User information
@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.

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top

  Register To Post
(1) 2 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project