Topic says most: I tried to use the page gadget and it seems to be a bit troublesome, using the recommended way of opening ReAction classes. There is no documentation about how to use it using a class pointer like it is recommended now (using the OpenClass() call, which is so far for disk based classes only!).
Did I miss something, or is it to be used by GetClass()ing the class pointer until further notice?
Wherever you formerly used NewObject(xy_GetClass(),NULL,...,TAG_END) you now use NewObject(xyClassPtr,NULL,...,TAG_END);
Are there other places where xy_GetClass() was used? If yes, just replace them all by the class pointer.
If you used reaction/reactionmacros.h before, either don't use it any more or make your own reactionmacros.h which uses class pointers instead of GetClass calls.
@whose
As you may have noted the layout.gadget exports two classes (layout.gadget and page.gadget). Using IIntuition->OpenClass() you will only be able to obtain access to the layout.gadget class.
If you need access to page gadget I suggest you simply obtain the "main" interface using IExec->GetInterface() and call the ILayout->PAGE_GetClass() at the beginning of your program storing the result in a variable called PageClass instead of calling it for each and every page.gadget object you create. If you're going to be using page.gadget in your program then you probably need access to the "main" interface anyway for ILayout->SetPageGadgetAttrs() so it won't be much extra work.
@thomas:
Hehe, no, no, this was a misunderstanding, I suppose :-) I already used the OpenClass() way of obtaining class pointers. But this doesnt work for page.gadget, which is part of layout.gadget. OpenClass() opens disc based classes only, so if theres no SYS:Classes/gadgets/page.gadget (which is the case actually), one wont get a class pointer to use with NewObject(). This was the initial problem, and it seems that I have to use the "good ol´ ways" of using the page.gadget library base and interface to obtain the class pointer using _GetClass(), as salass00 mentioned.
@salass
Thanks for the clarification :-)
Coder Insane-Software
www.insane-software.de
@whose
There is also the method of using the public class ID but it has more overhead since intuition has to do a string search of all the public classes in the system so I wouldn't recommend it:
Yeah, its mentioned in the layout.gadget autodocs that the dev should use the public class ID in order to get access to page.gadget. I never liked it for the same reason, too much overhead because of the class list traversal.
I prefer the way you suggested, using PAGE_GetClass() and caching the class pointer. A bit more work in the beginning, but much better if someone has to use lots of pages in a clicktab layout (but I dont have to, just 4 pages for my layout).
I wondered because the recommended way to obtain class pointers actually doesnt work for page.gadget, thats all. It would have been possible that I have missed something in the autodocs regarding the class pointer of page.gadget. Some "special" info is often buried in the depths of the SDK. Deep enough to miss it.
But obviously I didnt ;-)
Edit: bad spelling...
Coder Insane-Software
www.insane-software.de
Yes, I wasn't aware that page.gadget is a part of layout.gadget.
Call OpenClass() on layout.gadget and then use the page.gadget class name string to create page.gadget objects using NewObject(). The technique is analogous to using the BOOPSI objects contained in intuition.library.
Regarding performance, if it can be shown that string look ups are a system bottleneck we can introduce hashing and similar methods to speed that up.
Hm, I dont think that string lookup is a bottleneck, regarding the CPU power available. But its an ugly way, when all other GUI classes are openend the same way, except page.gadget. Just split page.gadget from layout.gadget and all things are fine. There is no reason to integrate page.gadget into layout.gadget. Make them dependend, thats it.
The old standard PAGE_GetClass() way is much more consistent than using the public class name when doing a NewObject() call. There are very few programs out there, using the public name of a non-OS3.x GUI class.
But its still ugly, when all other classes can be opened using OpenClass()...
Coder Insane-Software
www.insane-software.de
@ssolie
The biggest problem IMO with using public IDs with disk-loaded classes is that your program will compile and may even appear to work even if it's completely broken because you forgot to call OpenLibrary() for all your needed classes because some other program may have already used them so that they are already loaded in memory.