Doing some layout class
Hello again,
Merry Christmas also. 🎅
... Let's says... like if ... I needed to code my own Layout class... for some purpose.
I couldn't find any example to do that anywhere, but I guess most job is in GM_LAYOUT...
... and well I was asking myself 2 questions so far:
- Is gadget recursion managed in a layout done by intuition methods "AddGadget() / RemoveGadget() ", or by just using DoGadgetMethod() recursively for all GM_XX methods ?
Isn't calling DoGadgetMethod() recursively under a GM_RENDER dangerous ?
- Let's say: I add or remove a gadget under my own layout, how do I send refresh message to myself so it reaches GM_LAYOUT , like when resize is done ?
Thank youhappy new year also
So, Having tested lots of technique here is what works to make your own layout on BOOPSI OS3:
- extends layout.gadget. Don't hope to recreate a layout extending gadgetclass only by just retaining children yourself, it works a bit but I can't get something stable.
- pass regular LAYOUT_AddChild and LAYOUT_RemoveChild as superAttribs. Must be done or will not be stable. Watch out LAYOUT_RemoveChild kills the child.
- only override GM_LAYOUT , where you set your children LeftEdge/TopEdge/Width/Height . I tried thing overriding GM_Render but got strange behaviours. do not if not needed.
- don't ever try to mess up with input methods HITTEST/ACTIVATE/HANDLEINPUT/UNACTIVATE, just call super methods for all of this.
- ( nothing to do at gadtools level AddGadget or anywhat, this was a stupid idea.)
It is possible to create you own layout kind of class. the listbrowser does it's own layout of the various areas and the scroller gadgets. And it is not a subclass of layout.gadget.
The RKRM changes and additions has a chapter on making your own gadget class ithat manages sub contents.
But if you want it to be the toplevel layout then indeed you are out of luck. I would suggest in that case to simply have a layout object with only your custom gadget as it's single child, and then your class can get creative.
Btw indeennever call dogadgetmethod from inside a gadget. Things will go into deadlock.
That said I've also made my own gadget that is a subclass of layout.
Online Status
... blogging a bit about how long it took me to find out a reliable way to just refresh my gadget so it uses GM_LAYOUT and GM_RENDER with a correct signal... The idea is that layouting and rendering needs absolutely a correct GadgetInfo that is passed recursively during draw, but can't be generated externally.
So well, I added a MYGADGET_Refresh attribute, then a refresh from external source would be just: SetGadgetAttrs(obj, window, NULL, MYGADGET_Refresh ,TRUE,TAG_END);
... then in my private gadget TrackListArea_SetAttrs() , I have a struct opSet *Set with set->ops_GInfo , and there it is, a correct Gadget Info, then I go like;
case MYGADGET_Refresh:
{
// goes layout...
{
struct gpLayout gpl;
gpl.MethodID = GM_LAYOUT;
gpl.gpl_GInfo = Set->ops_GInfo;
gpl.gpl_Initial = 0;
TrackListArea_Layout(C,Gad,&gpl);
}
// goes render...
{
struct gpRender gpr;
gpr.MethodID = GM_RENDER;
gpr.gpr_GInfo = Set->ops_GInfo;
gpr.gpr_RPort = ObtainGIRPort(gpr.gpr_GInfo);
if(gpr.gpr_RPort)
{
gpr.gpr_Redraw = 1;
TrackListArea_Render(C,Gad,&gpr);
ReleaseGIRPort(gpr.gpr_RPort);
}
}
}
break;