I've just spent the morning converting and documenting Rammy's perl =
toolbar functions into XS. They're now in the CVS.
The new functions are as follows:
# (@)METHOD:SetButtonState(BUTTON, STATE)
# (@)METHOD:MoveButton(BUTTON, TARGET)
# (@)METHOD:ChangeBitmap(BUTTON, BITMAP)
# (@)METHOD:CheckButton(BUTTON, CHECKED)
SetToolTips is not really needed, as you should be able to assign a =
tooltip object using the -tooltip option when constructing the toolbar =
now. Same thing with SetImageList; you should be able to use -imagelist =
to set an imagelist now.
Note that there is already a Padding() method for the toolbar so I didnt =
add Rammy's padding one which seemed to do a similar thing. I've also =
(hopefully) fixed the "tooltips crash application on exit" bug that =
appeared when I ran Rammy's test code.
There is some safety checking on SetImageList, AddBitmap and =
ChangeBitmap. You cannot call SetImageList and AddBitmap/ChangeBitmap on =
the same toolbar as microsoft says this would be a really bad idea, so =
you get a croak about it if you try it.
Another thing is, I've modified the ButtonClick event so that when a =
button that has the TBSTYLE_DROPDOWN style applied to it is clicked, an =
extra argument gets passed to ButtonClick with the value of 1. This =
allows you to tell if you need to show a drop-down menu.
There have been a ton of constants added to GUI.pm and =
GUI_Constants.cpp, so you can use most of the regular toolbar styles, =
extended styles, button styles etc. One word of warning is to avoid =
using the BTNS_*** constants and use the TBSTYLE_*** equivalents =
instead, as the availability of the BTNS_*** constants depends on the =
headers and compiler used (they're a new thing).
I added dwFlags to the USERDATA and CREATESTRUCT structs. This dword is =
intended to store any per-object flags needed. for instance, the toolbar =
uses FLAGS_TB_HASBITMAPS to remember if AddBitmap has been called and =
complain if the user attempts to SetImageList on the same toolbar =
object. Developers: add flags as you see fit.
One last thing. We're running out of mask bits in the NEM. Are they =
really needed? The mask only appears to be used as a speed thing (to =
avoid doing a hash lookup for each event) so perhaps it would be more =
sensible to group some events together or something? Thoughts please...