toolbox-programming with oslib

[Tony van der Hoff]

On Wed, 18 Oct 2000, at 20:53:38, David J. Ruck <druck at freeuk.com> wrote on the
subject "toolbox-programming with oslib":

>On 13 Oct 2000 "Jonathan Coxhead" <jonathan at doves.demon.co.uk> wrote:
>> On 12 Oct 00, Tony van der Hoff wrote,
>>  | The problem is that the dcs_obj and colourdbox_obj
>>  | structures are not the entire template, but only the object-specific
>>  | part. The toolbox requires a standard header to be prepended to make a
>>  | complete template. Unfortunately, oslib currently does not appear to
>>  | define such structures pre-built, so you have to fiddle around with your
>>  | own.
>> 
>>    The reason it doesn't is precisely the same reason that we discussed a 
>> while ago regarding the same situation for message types: it's better 
>> design if the "base part" is included in only 1 place (wimp.h for messages, 
>> toolbox.h for templates), and everything else extends it.
>
>I've just ported a application which used a mixture of OSLib and tboxlibs
>to pure OSLib, and I'be been bitten by the lacking of OSLib in this ara.
>I needed to change sprite area of a toolbox window. I've ended up having
>to define the following.
>
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 :-)

>    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?

>    typedef struct
>    {
>        unsigned int            flags;
>        char                    *help_message;
>        int                     max_help;
>        char                    *pointer_shape;
>        int                     max_pointer_shape;
>        int                     pointer_x_hot;
>        int                     pointer_y_hot;
>        char                    *menu;
>        int                     num_keyboard_shortcuts;
>        keyboardshortcut_object *keyboard_shortcuts;
>        int                     num_gadgets;
>        gadget_object           *gadgets;
>        toolbox_c               default_focus;
>        int                     show_event;
>        int                     hide_event;
>        char                    *toolbar_ibl;
>        char                    *toolbar_itl;
>        char                    *toolbar_ebl;
>        char                    *toolbar_etl;
>        wimp_window             window;
>    } window_template;
>

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 ;-).

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).

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,
there is no reason why you shouldn't do that yourself until I re-release OSLib (use
a different name, though ;-).
 
I'm not convinced that that the toolbox_object_template_header structure is actually
needed, but what the hell... 

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.

>
>And then use them as follows:-
>
>    toolbox_object_header *object_header;
>    window_template       *wtemplate;
>    
>    E_CHECK_ABORT(xtoolbox_template_look_up(0, "Main",
>                                            (toolbox_id*)&object_header));
>
>    wtemplate                     = (window_template)object_header->body;
>    wtemplate->window.sprite_area = h->sprite_area;
>
>    /* Main window initialisation */
>    E_CHECK_ABORT(xtoolbox_create_object(toolbox_CREATE_GIVEN_OBJECT,
>                                         (toolbox_id)object_header,
>                                         &h->main_id));
>
>The last call also could do with a specific type safe function when using
>an object header.
>
Or (error handling omitted):

  toolbox_id* template;
  xtoolbox_template_lookup( 0, "main", &template );
  ((window_object_template*)template) -> window.sprite_area = h.sprite_area;
  xwindow_create_object( toolbox_CREATE_GIVEN_OBJECT,
                         template,
                         &h -> main_id
                       );

>While I'm at it i've also noticed a nane anomally in stringset.h
>
>   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.


-- 
Tony van der Hoff         |  mailto:OSLib at mk-net.demon.co.uk
Buckinghamshire, England  |  http://www.mk-net.demon.co.uk/oslib/
----------------------------------------------------------------