AutoHotkey Community

Don't understand, but guess I do not have to.
Maybe a new cleaned up MMenu modul could have a new interface. I would put the Options right after the Title, since I use it more frequently then icon or position. Just a thought.

_________________
Ciao
toralf

Perhaps.

I will consult you when the time comes to update MMenu.

_________________

2 toralf

Is this what you want ?



Just add it in MMenu.ahk and use it.

_________________

Thanks a lot I didn't know about MMenu_Count(). It wasn't in the doc. But now I see it is documented in the file header. Thanks again.

_________________
Ciao
toralf

Word doc is outdated. Use html reference.

_________________

don't have the html.

_________________
Ciao
toralf

Thanks got it now. Added it to LilBuilder repo

_________________
Ciao
toralf

Could this be changed? I would like it to be unique for its menu. This will help for LilBuilder. Specially for the common menu parts. Currently I use numbers, but that is not very robust, since order might change or items might be left out for some controls.

In my imagination: internally extend the item ID with the menu number. If this is done through the whole mmemu module, the item id becomes unique per menu.

_________________
Ciao
toralf

Well, there are bigger benefits of globaly unique ID then otherwise.
With global ID, you don't have to care about which menu contains item, and U can always set it or remove it (well, now it requires menu id, but in next update I planned to make this param optional). So if you once added ID=myId in some menu, you can set/remove it without knowing which menu was it.


You can always put ID in such way to be connected to the menu. Lets say you have menu named common. You can specify ID's to be Common_N. Without N, u have no mean to know if particular ID exist (this will change once AHK have asoc arrays).

I don't know what kind of problems you might have with ID that are not solvable in robust way with current API. Can you provide sample that is problematic for you ?

_________________

The problem might not be to dramatic and might be possible to solve. But having items unique per menu would solve it right away.

The global approach with what you plan for the next release will only remove the menu ID from Set/Remove, all the rest of the functions will require a Menu ID. I do not know if that is benefit enough to justify a global approach.

_________________
Ciao
toralf

Thanks for this great function! I'm using the My Favorites folder script and I was looking for a way to make icons and change menu color. By the other side, I'm looking desperately for a manner to be able to show more than one menu at once. To have for menus showing pressing a hotkey,for example. Is there any way to do it?????? Thanks.

Its not supported by Windows OS, but I think it can be done using some subclassing. I just don't have desires to do so, so you will have to leave without it.

You can try Black Box for WIndows for uber menu possibilities.

_________________

The icons part can be done. To get the associated small icon of a file, look in this thread for Chris' post about SHGetFileInfo().

Perhaps you could simulate four menus by having a single four-column menu.

The MMenu demo script shows how to use columns. Specifically, this line:The b| option places the item in a new column. The pipe '|' tells it to show a vertical line between the columns.

When I try the example menu (or make my own), the highlighted item is blue (not red as in the picture on the 1st page) and the text remains black, it doesn't invert the colour, so it can't be read. Any ideas what's wrong/how to change the colours? (I'm using Windows XP, latest AHK version)

You are probably using some skining application like WindowBlinds.
Exclude AutoHotkey.exe in its config if that is the case.

_________________