Known Toolbox bugs which have been fixed ======================================== String Set: If the gadget was set to have no display field, the first menu item would never be ticked. Icon bar: The icon bar module will did handle sprites taller than 34 OS units correctly. Though having taller sprites does not conform to Style Guide recommendations, this has been fixed. Font Menus: By the time the FontMenu_AboutToBeShown event is delivered, it was too late to set the tick. The menu had already been created. Menus generally: Menus were 20 OS units too wide on RISC OS 3.1 machines, and were of incorrect width on any OS version if there was no menu title present. Menus also delivered Menu_HasBeenHidden events before Menu_Selection events - this order has been reversed. Gadgets: If a gadget is dynamically created (using Window_AddGadget) with an ID of -1 (the client doesn't mind what ID is used), external gadgets weren't told which ID was really being used. Button gadgets didn't report whether they were selected or not with the button_get_flags method, if the user caused the selection to occur rather than a call to button_set_flags. Toolbars: Various aspects concerning order of redraw have been changed, resulting in less flicker (e.g. they were redrawn when paging up or down in the parent window - this no longer happens). Additions to the existing gadgets/methods that have been completed ================================================================== All objects apart from the Colour dialogue support show type 3 - show centred. Action buttons within Window objects now have a SetFont method (see DisplayField_SetFont, page 357 of the Toolbox manual for registers). Other Toolbox considerations ============================ Toolbars do not always behave in a useful manner. The most common case is for internal toolbars, where the width or height of the toolbar is fixed; when the parent window is opened to a large size, the toolbars don't extend to fit the visible area. This can look fairly scrappy in some applications, and for some applications which extend or move gadgets on the toolbar as the window resizes (such as web browsers) is also of little use. This functionality has been added to the Toolbox, by making use of the extendable X and Y bits which are normally greyed out in the 'Other Properties' dialogue for a toolbar. The Toolbox used the RMA for all memory claims - this led to fragmentation. Memory claims have been moved out to a separate Toolbox dynamic area for OS versions that support these. When a new Toolbox module needs to be loaded, it must not already be in use or the copy already present will complain and refuse to die. There is no obvious way of altering this behaviour. Consequently, any new Toolbox module versions must be placed in the !System folder and loaded at startup, before any applications attempt to use the Toolbox. Work is currently in progress on various new gadgets, including self-redrawing gadgets. This allows the creation of, for example, gadgets that contain draw files. With this in place, the capabilities of user defined gadgets will be greatly expanded - at present, they're more or less limited to combinations of existing gadget types. Extensions that are planned but unfinished include show type 4 (show near pointer), gadgets with 24 bit foreground / background colour fields, and text area gadgets (which may also appear as one-line selectable writable fields). Some parts of the Toolbox have been extended to cater for extra features of the Wimp, which is currently undergoing some significant changes and enhancements. These include fixing long-standing bugs such as the loss of the Desktop font if a button containing a custom font slabs in. An extension to Wimp_ReadSysInfo is planned, to return the toolsprites size. The Wimp now has full support for nested windows, making implementation of panes considerably easier and much smoother (from the user's point of view) than before. This includes such things as small panes that sit alongside a scroll bar giving, say, page number information, etc. This is still in fairly early stages. This affects the Toolbox in a number of ways. An embedded window gadget is planned, and the text area gadget requires the nested wimp to operate at all. Bit 2 on the flags word for Toolbox_ShowObject is used to implement support for nested windows (only really meaningful on Window objects); the new show type 3 needs to be able to differentiate between whole screen or visible area centred behaviour. It is possible to dynamically alter a window's flag bits (to add or remove tools, for example) and the Window module needs to support this. At present the nested Wimp / Toolbox APIs are not sufficiently stable for release. Consequently, API details are not available at present. Unfixed bugs in the Toolbox =========================== These bugs are known about, but haven't been fixed yet.They are predicted to be significantly more difficult to fix than any big in the "fixed" list; they will be addressed as and when resource is available. Action button gadgets: These sometimes can't be shaded if they have objects attached to them. Colour dialogues: These can set the 'None' button when they shouldn't. Problems in the Toolbox C library ================================= The Toolbox eventlib has a limitation of not allowing an event handler to be deregistered within itself, unless the event is claimed. So a null handler that tries to deregister itself but not claim the null (say) will give obscure crashes; the solution is to claim the event (return a value of 1 rather than 0 from the event handler). The toolbox_get_client_handle call is declared as taking a void * as its last parameter. This should be a void **. The solution is to cast to void * in the call. So, though the code: void * handle; toolbox_get_client_handle(flags,object_id,&handle); is what you actually mean, you need to use void * handle; toolbox_get_client_handle(flags,object_id,(void *) &handle); instead.