When owner-drawing is in use, MI uses the dwItemData field of the menu item to store a handle to the icon. This field is ideal for associating data with a menu item as it will remain valid even if the index of the menu item changes.
MI.ahk wrote:
; Associate the icon with the menu item. Relies on the probable case that no other
; script or dll will use dwItemData. If other scripts need to associate data with
; an item, MI should be expanded to allow it.
If you are writing a wrapper for the menu APIs, you are in the ideal position to write functions for other scripts to associate arbitrary data with an item. Providing such functionality from a "menu icons" library does not seem appropriate. If you wish to integrate any or all of the functionality of MI.ahk, you have my approval.
Additionally, if everything goes through your wrapper, you can automatically release any resources associated with a menu item when it or its menu is deleted. I think the best way to do this would be to allow scripts to register a subroutine (label) or function to be called when an item is deleted. Your wrapper could then free the item's icon either explicitly, or implicitly via a cleanup subroutine or function.
Any feature to automatically release resources used by the menu when appropriate would be important for most scripters; even my own resident script leaked memory for a while because I'd forgotten to explicitly remove the icons before recreating the menu.
You should take a look at
MMenu if you haven't already.
As for associating data with the menu itself, I would wrap the menu handle in a data structure. Within the menu API wrapper, the menu would be identified by a pointer to this structure rather than the menu handle. For example:
Code:
mi := MenuInfo_new(0x539)
MenuInfo_setData(mi, "Greetings, forum.")
MsgBox % MenuInfo_getHandle(mi) ": " MenuInfo_getData(mi)
MenuInfo_delete(mi)
MenuInfo_new(handle) {
; Allocate menu info structure { uint handle, str data }.
mi := DllCall("GlobalAlloc", "uint", 0x40, "uint", mi_size:=8)
; Store handle.
NumPut(handle, mi+0)
return mi
}
MenuInfo_setData(mi, data) {
; Free previous data.
if NumGet(mi+4)
{
DllCall("GlobalFree", "uint", NumGet(mi+4))
; Store NULL pointer to represent empty string when data="",
; or in case error-handling is added and the function returns early.
NumPut(0, mi+4)
}
if data =
return
; Allocate buffer for string.
mi_data := DllCall("GlobalAlloc", "uint", 0x40, "uint", StrLen(data)+1)
; Copy string into buffer.
DllCall("lstrcpy", "uint", mi_data, "str", data)
; Store pointer to string.
NumPut(mi_data, mi+4)
}
MenuInfo_getData(mi) {
; MulDiv returns NumGet(mi+4) unmodified, but "str" causes AutoHotkey to
; interpret it as a string. Safe even if NumGet(mi+4) returns NULL (0).
return DllCall("MulDiv", "int", NumGet(mi+4), "int",1,"int",1, "str")
}
MenuInfo_getHandle(mi) {
return NumGet(mi+0)
}
MenuInfo_delete(mi) {
; It is important that setData() frees the previous data and does not
; allocate new memory when data="".
MenuInfo_setData(mi, "")
DllCall("GlobalFree", "uint", mi)
}
Robustness, performance, usability, flexibility, etc. could be improved, but this is just a brief example. Any number of "fields" can be added, either string or numeric, by adjusting mi_size in MenuInfo_new.
dict.ahk uses a similar approach to implement an "associative array". ("dict" is short-hand for
Dictionary.)
Login
Register
FAQ
Search
MI_SetMenuItemIcon leaves it up to the caller to delete icons/bitmaps used before assigning another icon to the menu item or deleting the menu (item). My benchmark script was not doing this. Strangely, I did not see memory usage or handle count spike (watching task manager).
... Never mind. I found a way around it. I just made a wrapper function to keep track of the UseErrorLevel and have it turn UseErrorLevel on/off as needed.