AutoHotkey Community

[Lexikos]

ItemClick executes when an item is selected from the example menu. Afaik, every item must have a label, but since the example is only showing off the icons, the label doesn't need to do anything.

[Superfraggle]

Hi Lexicos, Great script as always.

I am having some issues with it, probably missed a comment somewhere, but take this example.

[Lexikos]

It appears AutoHotkey recreates the tray menu when you delete M, so hTM is no longer valid. You also need to reset the tray menu icons. Try this:

[Guest]

hi do you know how i can use your menuicons with this kind of menu?

[Lexikos]

Follow the examples previously posted. It is no different from any other menu...

[Guest again]

thanks

but i cant get it to work. im on xp sp3

I get no errors with this code, but no icons either. Also the menu gets stuck if i try to click it away (outside of the menu). I tried to experiment within the CreateMenu() loop with no luck.

The example above gives me icons but with 20-30 menu/submenu items it gets alot lines of code that way ...


Maybe im lost in translation, is this the way you meant?

[Lexikos]

[animeaime]

Sorry for waking a dead thread, but just wanted to add my $0.02 and see if this helps. I added memoization (of menu handles) to your code and was wondering if you might incorporate it into the main program - so that others can use it too.

My question is: will memoizing the values cause problems? I presume not since you suggested a similar technique, but just wanted to make sure.

Here is the "updated" MI_GetMenuHandle method. This way, you don't have to pass the handle, but can just pass the menu name (e.g. "Tray"), and it will (on first access), save the value, and on subsequent calls reuse that value. And, thanks to your excellent encapsulation, this applies to ALL the methods.

Of course you can choose to add this or discard it. If you discard it because there's some problem with it please do tell - I don't want to build code using this method if it's faulty.

Here's the code, pay attention to the lines in red.

[animeaime]

Also, I was reading through the code a bit and think this is a typo.

Old version:

[Lexikos]

[animeaime]

In response to my first post, is there a problem with caching the menu handles as I did?
_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

[Lexikos]

Sorry, I didn't see that post.

There is a problem, but only if the menu is deleted and recreated - i.e. because the handle changes. Is there any particular reason you think the menu handles need to be cached?

[animeaime]

Well, right now I'm writing a "complex" (maybe inclusive is a better word) menu wrapper, which I will post when complete, and I want the ability to incorporate my functions with yours. Right now, there are many people that use your code and they may have all their menus set up around the handle of a menu. So, to ease transition and to incorporate the functionality of these tools, I would like some way to link the handle numbers currently used with the menu name (which is what I use to wrap the menus).

The other reason is that I presume that many people, myself being one, don't want to have to keep track of another variable to store the handle of the menu when using your suite. Instead, I would much rather call the functions using the menu name (versus the handle) and have the code cache for me.

Another benefit is that anyone else that has any menu wrappers they want to add to your suite (and mine when ready) will then be able to have an easy link (since both the menu names and handles will be easily linked).

In my menu wrapper I will account for the fact that deleting a menu will change the handles. Will it change just the menu handle for the deleted menu or for all menus?

I am just tired of having to keep track of all the values that I use for my menus - the menu handle, the item names, the displayed item names (which may differ if for example the item contains ampersands as literals), a pointer to the menu data (so to allow easy moving of menu items in the menu without having to move the menu data that goes with it), the menu label, the menu size (both the displayed menu size, and the number of items already added to the "menu storage"), and others that are program dependant - which is why I'm creating a menu wrapper. Then, I thought that I could combine it with the functonality of your menu icons program - and to do this (and account for all the code that uses menu handles and not menu names), I need all my functions that use menu names to allow the handle to be used instead (which then checks the cache for the menu name).

So, in "short", it's because I think AHK needs "good" wrapper methods so that menu creation is easier (like we have many GUI wrappers to make GUI creation easier).

The code should be up in a few days (working out some of the small details), so you don't have to decide now, and instead can see my menu wrapper and see if you want to.

I believe that the code recommendations are backward compatable and thus all the code already running will be fine - I just thought that a little upgrade would help to incorporate your suite with mine (and any others that do/will use menu names to store menu data)

Also, to clear up any confusion I may have created, when I say "incorporate" I don't mean they need to be combined, just that by adding these functions they can "work well" with each other (and other menu suites that are/will be developed through the life of AHK).
_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

[Lexikos]

[animeaime]

So, just to clarify, there is "no" (or little) performance loss by using the menu name (versus the menu handle) in your functions? My confusion comes because inside your TestMenu.ahk file you say the following, "Refer to a menu by handle for efficiency."