Dynamic gadget CheckBox

I need help,i need to have a dynamically checkbox. I need several,someitmes 1,other times maybe 200. Anyone's got an idea how to do this?

The code i use for the checkbox.

LAYOUT_AddChild, gadgets[GID_CHECKBOX1] = (Object *)CheckBoxObject,
GA_ID, GID_CHECKBOX1,
GA_RelVerify, TRUE,
GA_Text, tempis,
CHECKBOX_TextPlace, PLACETEXT_RIGHT,
CheckBoxEnd,

@Antique

Maybe you should use a listbrowser for that, every entry in a listbrowser can have a checkbox befor it. Sys:Utilities/UnArc uses that for example.

@ZeroG

Nice idea btw.

Will look into that instead.

@Antique

If you need a changing number of checkboxes in your layout, you'd be better off using a listbrowser with checkable nodes. Adding and removing listbrowser nodes is much easier, faster and safer than performing in-place changes to a layout.

Another advantage is that your layout will keep a certain size and shape, regardless of whether you have three or 100 checkboxes.

@Antique

You can use LAYOUT_AddChild to dynamically add gadgets to a window however you run the risk of hanging the OS

In OS 4.1 a method LM_ADDCHILD was introduced which will attempt to add the child gadget.

As to why this new method was introduced rather than fix LAYOUT_AddChild is beyond me

@madmonkey

The reason might be a design flaw, don't know. But the introduction of a method is logical because in OOP, actions upon objects should be done through methods, not through attributes.

@trixie

I agree that logically it should be a method not an attribute. Just doesnt make any sense to me to introduce a new way of doing things rather than fix the existing way.

NB Setting attributes on an object calls the method OM_SET so everything is a method anyway.

@ZeroG

Thanks for the tip. Much easier than i thought when using listbrowser.

@Antique

@madmonkey
Quote:
Because it was the only way to remain backwards compatible. Plus it always should have been a method to synchronize with intuition, etc. properly.

@ssolie

Quote:

Funniest thing I've heard in a long time. So if there's a bug that hangs the OS, it won't get fixed because then it wouldn't be backwards compatible! I'm sure all the major software houses follow the same development methods. Lol

I can appreciate it might take time and effort but remaining backwards compatible to keep the undocumented OS lockup is plain silly.

@madmonkey
Quote:
The situation is clearly documented in the layout.doc autodoc.

There are a lot more such situations in the OS. Perhaps you would like to point them all out and laugh some more?

@madmonkey

What a constructive comment. And bugs will be fixed.

@ssolie

As I pointed out in my original post the lockup and new method are documented in the latest SDK.

However in previous SDKs there is no mention of the lockup or new method so forgive me for using LAYOUT_AddChild when there was no other way to create dynamic GUIs.

I just wish it had been documented previously as it caused me quite a few headaches.

I apologise if my comment caused offense. It just made me smile that backwards compatibility is the reason for not fixing the original mechanism.