AHK_user wrote: ↑27 Apr 2022, 01:09
It is indeed cool if the onevent and onnotify would also work, but I would certainly appreciate it if the default "Click" callback would be also included in the line where you add the button to the toolbar.
I think I understand what you are saying here, but the callback for a toolbar is for the entire toolbar, not a specific button. So adding such a field to the
Toolbar.Add() method would not make much sense. It would make more sense to mimic the AHK v2 behavior with OnEvent / OnNotify. What context are you thinking of that would require specifying a callback for a specific button?
Below I explain a bit more about the data that is fed into a toolbar callback (currently and likely in future updates).
PS: I know that I didn't actually write any docs for this. I plan to do that with a rewrite of this lib.
AHK_user wrote: ↑27 Apr 2022, 01:09
If possible, It would be completed if it could also accepts flat arrow functions.
The
fat arrow functions are simply another kind of function object. So a predefined callback or a
fat arrow function would work either way. I think this old script may actually accept just a string (old AHK v1 style), so that should change for sure.
AHK_user wrote: ↑27 Apr 2022, 01:09
This callback parameter could be possible also a menu object to show the menu.
I don't quite understand what you mean here. When you click anywhere on a toolbar (including on a button), the callback function (currently and in the update) will give an object that specifies the following:
- Button Index (0 or -1 for no button i think)
- Button CmdID (a TBBUTTON struct thing)
- X/Y coords of the mouse cursor click on the toolbar
- X/Y coords of the top-left of the button clicked
- W/H of the button
- and much more
All this info, in part or in whole, can be used in order to create the menu at the specified location. In the example I tried to briefly explain the contents of the obj in the callback (there is a lot).
In the example the explanation is several commented lines, starting at Line 179:
Toolbar event callback: tbEvent(tb, lParam, dataObj)
And you can see some of this info as the example script is run, in the text box.
But actually creating and/or displaying the menu obj is done by the user in the callback with the above info, and this process is done completely externally according to my observations. If I conform to the AHK v2 syntax, the user can still customize their callback function and the setup of the Toolbar object using something like this:
Code: Select all
; after creating the Toolbar obj, then...
; ========= maybe don't do both of these ============================
Toolbar.OnNotify( 0x1234, cb_func.Bind(,, UserMenuObj) )
; -- or --
Toolbar.menu := MenuObj ; then is accessible below without Bind)
; ===================================================================
cb_func(GuiControl, lParam, MenuObj) {
; the resulting callback has the extra user-defined parameter
; -- or --
; Simply use GuiControl.menu to access the menu obj
}
This kind of customization is basically limitless. I think you can even override the default fields in any given built-in AHK v2 callback funciton with the
Bind() method. You can also attach the MenuObj to the Toolbar obj (as shown above).
If you can show me a context where an actual menu object should be somehow handled by the internal code of the toolbar, and not by the user in some way, then I'd be happy to consider making that change in this script.
GitHub
