IF USING NOTEPAD THEN PLEASE TURN ON WORDWRAP

Toolbar Version 2.1.1

This toolbar was designed specifically to be used on a main window of an SDI application in order to automatically display the menu as toolbar buttons. It can also be used on any window in order to build up toolbar options of non-menu items.

The main features allowed by this toolbar which are not available using the powerbuilder standard toolbar are:-
	Any size toolbar buttons
	Buttons have a transparent background
	Internet Explorer style colour highlighting is available

The following must be taken into consideration when creating and manipulating a menu for use with this toolbar.

1. Stock pictures
The toolbar cannot use the powerbuilder stock pictures. You must specify a bitmap file when setting up the toolbar picture in the menu painter.

2. Disabled bitmaps
If any toolbar buttons could be disabled then a disabled version of the bitmap is expected to be found in the same directory as the enabled bitmap. The disabled bitmap should have "-disabled" appended to the filename. eg if your picture name has been given as c:\myapp\toolbars\fileopen.bmp then the toolbar will expect to find a disabled version called c:\myapp\toolbars\fileopen-disabled.bmp.

3. Greyscale bitmaps
If an IE style toolbar is required then greyscale bitmaps must also be supplied of all standard bitmaps. The filename of the greyscale bitmaps should be an extension of the standard bitmap filename similar to the disabled bitmaps above. e.g. c:\myapp\toolbars\fileopen-gs.bmp could be the greyscale version of the colour bitmap c:\myapp\toolbars\fileopen-gs.bmp. The extension used is programmable, the example code supplied uses "-gs" but this can be set by the programmer. The extension can be set using the function of_tb_setMouseOffExtension(string as_ext). If the extension is set then only the colour bitmaps are used.

4. Transparent colour on bitmaps
The toolbar buttons make use of a transparentpicture object which allows light grey (the standard buttonface colour) to be transparent. Try changing display style to something such as "Brick" while you're running the example to see the effect.

5. Changing properties of a menu with menu driven toolbars
After the toolbar has first been created, it does not know when a menu item has been enabled, disabled or checked with code like "m_myMenu.m_file.m_save.enabled = false". This is because PB does not trigger any sort of event when the status of a menu item is changed. In order to change any property of a menu item this must be done through a call to the toolbar object. The toolbar object will automatically update the menu for you.


Notes on the example
====================
When using the example pibble make sure that toolbar.pbl is included in the path.

If bitmaps do not appear then try closing and re-opening the application, this usually does the trick. This is happening because I have not supplied a pathname in any of the bitmaps as I don't want to dictate where you copy this example application to.

Try changing the size of a toolbar when both windows in the application are open. You'll notice that the change in style is broadcast to all other toolbars in the application.

Examine the clicked event of each large button on the windows to see how they operate.

The example demonstrates my favoured method of using the toolbar control which is to actually place the toolbar in an ancestor window and create an interface in this ancestor for descendant windows to communicate to the toolbar.

The ancestor window contains duplicate functions to the toolbar object and delegates control to the toolbar.

This has been done in anticipation of Sybase introducing better toolbar functionality themselves in future. If and when this happens there is only one object throughout the application to amend to remove my own toolbar and pass control to another.

There are 4 functions and one event the ancestor window that the toolbar does not have.

The functions are designed to return the workspace area left available on the window.
	of_tb_getWorkSpaceWidth()
	of_tb_getWorkSpaceHeight()
	of_tb_getWorkSpaceX()
	of_tb_getWorkSpaceY()

The redraw event of the window is triggered by the resize event of both the window and the toolbar. Code is expected to be placed here on descendant windows to handle repositioning and sizing of visual objects after the available workarea has changed.

Watch for the repositioning of the commandbuttons when you resize the screen or change the toolbar size then have a look at the code in the redraw event of the windows.


Credits
=======
Credit goes to Chris Gross for use of code from his u_hoverbutton object. This object together with example code and documentation can be found on Chris's website at http://www.geocities.com/SiliconValley/Hub/3624/index.htm

Credit goes to Rui Cruz for use of code from his nvo_tooltip object. This object together with example code and documentation can be found on Rui's website at http://www.migmag.pair.com/pb/index.html

Thanks to Ken Howe for distributing this for me.


Apologies
=========
I have changed the name of public functions between versions 1 and 2.  Sorry for any inconvenience. The use of the old "menu" prefix used in version 1 seemed inappropriate when toolbars can now be built without use of menus.

Function names include a prefix so that if the object is inserted into an inheritance structure then function names are less likely to clash.


Change History
==============
Version 1: Initial release
Version 2: Partial rewrite to allow buttons of various sizes
Version 2.1: Inclusion of functions for IE style toolbar buttons
Version 2.1.1: Bug fix in setredraw function of toolbarmanager