toolbox-programming with oslib
David J. Ruck
druck at freeuk.com
Thu Oct 19 19:37:24 BST 2000
On 19 Oct 2000 Tony van der Hoff <OSLib at mk-net.demon.co.uk> wrote:
> I'm currently doing something similar. It is interesting to note that
> OSLib's toolbox problems are now starting to crawl out of the woodwork. I
> started having problems a few weeks back, then Uwe needed help, now you're
> reporting similar problems. I guess more and more people are switching from
> tboxlib to OSLib as they find tboxlib to be unsupported :-)
I just thinks is a bit daft to be using two libraries to do the job or one.
tboxlib has the advantage of some really cacky examples, but OSLib has the
source available, and that wins when hacking stuff about.
>
> > typedef struct
> > {
> > toolbox_class object_class;
> > int flags;
> > int version;
> > char name[MAX_OBJECT_NAME];
> > int total_size;
> > void *body;
> > int body_size;
> > } toolbox_object_header;
>
> Interesting, I've not used Template_Lookup; I'm a bit surprised at your
> void* in there, does the SWI translate the offset into an absolute address?
Thats how it is in tboxlib, as it is an absoulte address which points at
class specfic data - this would be so much nicer with C++ classes.
> I know you're experienced enough to know what you're doing, but I don't
> think I'd have done it that way (no criticism intended ;-).
I wouldn't have either, I thought it must be me failing to spot that really
obvious call to alter the sprite area of a toolbox window object, but there
doesn't seem to be one, so you have to get down and direty amoungst the old
Window templates.
> We already have structures defined by the new-style macros
> toolbox_RESOURCE_FILE_OBJECT MEMBERS and window_OBJECT_MEMBERS
> respectively. You may as well use those for forward compatibility (I'm not
> being dismissive of your ideas, but simply prefer to use existing
> structures).
Ahhh, thats where they are. I'm doing this all in a bit of a rush (two days
before the show), and I spent ages seaching all the headers for this sort
of thing, but toolbox_RESOURCE_FILE_OBJECT isn't matched by the search
of object\.\*header :-(
> I shall be adding:
> struct
> {
> toolbox_RESOURCE_FILE_OBJECT_MEMBERS
> } toolbox_object_template_header;
> and
> struct
> {
> toolbox_RESOURCE_FILE_OBJECT MEMBERS
> window_OBJECT_MEMBERS
> } window_object_template;
>
> and so on for each object type, to complete the missing definitions. As I
> told Uwe,
Yes I'll do that. Its not high priority as I've only ported the existing
tboxlib application as an exercise in discovering using OSLib's calls and
as a general refresh on toolbox stuff, as I'm very rusty.
> there is no reason why you shouldn't do that yourself until I
> re-release OSLib (use a different name, though ;-).
I wouldn't put it past you!
> I'm not convinced that that the toolbox_object_template_header structure is
> actually needed, but what the hell...
Well, if you can invent a call to do the sprite area setting directly, I'll
use that - maybe something for OSLibSupport?
> It would probably also be useful to define some macros for size and offset
> fields in each template.
>
> I believe that covers all requirements; correct me if I'm wrong.
Should do.
> > xstringsetsetselected_string
> > stringsetsetselected_string
> > xstringsetsetselected_index
> > stringsetsetselected_index
> > xstringsetgetselected_index
> >
> >shouldn't all these have an underscore after stringset? All the others do.
> >
> Yes, you're right. Thank you. In fact the correct format is
> (x)stringset_set_selected_string, etc.
>
> I've amended that for the next release.
Thanks, I'll macro that up now, to aviod changing the code later.
Cheers
---Dave
--
____________________________________________________________________________
David J. Ruck Phone: +44- (0)7974 108301 Email: druck at freeuk.com
____________________________________________________________________________
More information about the oslib-user
mailing list