AutoHotkey Community

[Lexikos]

[animeaime]

[animeaime]

I have a some quick questios about your Menu test (trying to figure what's required and what's not).

[Lexikos]

[Lexikos]

Cases when a menu handle is destroyed include, but may not be limited to:

• Menu,,[No]MainWindow destroys the menu handle if the menu includes the standard menu items. Next time the menu handle is created, only the relevant standard menu items are added.
  
  
• Menu,,DeleteAll destroys the menu handle.
  
  
• If a pop-up menu is used with Gui, Menu, it has to be destroyed and recreated to convert it to the correct type of menu.
  

  Quote:

  Source: AutoHotkey Documentation: Gui, Menu Once a menu has been used as a menu bar, it should not be used as a popup menu or a submenu. This is because menu bars internally require a different format (however, this restriction applies only to the menu bar itself, not its submenus).

  
  
• If a menu item which has a sub-menu is given a different sub-menu or converted into a normal menu item, the old sub-menu is destroyed by SetMenuItemInfo. Although this is undocumented for SetMenuItemInfo, it was documented for its predecessor:
  

  Quote:

  Source: MSDN: ModifyMenu Function () If ModifyMenu replaces a menu item that opens a drop-down menu or submenu, the function destroys the old drop-down menu or submenu and frees the memory used by it.

  
  
• If a menu handle is destroyed, its sub-menus' handles are also destroyed. There doesn't seem to be a way around this:
  

  Quote:

  Source: MSDN: DestroyMenu Function () DestroyMenu is recursive, that is, it will destroy the menu and all its submenus.

  
  
• Any menus containing the destroyed menu are also destroyed. This is done so that the sub-menu itself is automatically recreated when the parent menu is next shown.
  

[animeaime]

Hmmm... I'll have to check into those, thanks. Also, why not use RemoveMenu instead of DeleteMenu when deleting an item? This way the menu won't be recreated next time - which should be more efficient anyway, right?

Also, now I see what you mean, a built-in value would be MUCH better than the dwMenu/ItemData value. This way, when the menu / menu item is destroyed and recreated, the behavior, is as expected, that nothing happens. If both the menu icons could be restored and this built-in value, then that would be great. If that built-in value stored a Class, then it would remain valid (because it's destroy function was never called), also, any other values which may be stored in that space are preserved. This way, only when the user calls something like Menu: delete, deleteAll, etc. where the menu SHOULD be destroyed, will the menu wrapper actually destroy anything (which will help fight potential memory leaks). Right now it's safe for delete and deleteAll, although I'm going to keep testing. I didn't test [No]MainWindow or Guis - never even crossed my mind that those would destroy the menu - so thank you a bunch for that information.

Edit:
I just thought of something. Since AHK has its own data structure that holds the menu data, is it destroyed automatically when the the menu / menu item handle is invalid? For example, when you call Menu, MenuName, delete, won't that remove each item that has MenuName as its submenu? That would mean that each of those item's data structures need to be removed, right? Is there a way to have a function run on the menu item's data at that time (likewise a function, or the same function, when deleting a menu). For example, both the Menu and MenuItem objects can be destroyed automatically by a call to Class_DestroyThis(Object) - where Object is the value stored in the dwMenu/ItemData (which hopefully can be instead stored as part of the UserMenu[Item] data structure). This function, then dynamically calls the destroy function for the Class object (either Menu_destroy for a Menu object or MenuItem_destroy for a MenuItem object). If you could add the ability to call a user-specified function when AHK destroys the menu/menu item's AHK data - that would be GREAT (although not sure if plausible). This way, only when AHK destroys the menu/menu item its Class object destroyed. Like I said, not sure if it's possible, but just a thought. Of course, since the function is user-specified it won't limit the use of the menu/menu item's data to solely a Class object.
_________________
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]

I hope I'm not a bother with all these questions - I'm going to you because you seem able to answer them. If I ever become a bother, please tell, that's not my intent.

Right now I'm trying to add functionality to "save" the menu so when NoStandard and other operations need to be done that recreate the menu, the previous values are restored. I know that the menu items have their wid (and menu item handle) which can be used to see that they are part of the "standard menu", but is there any characteristics on the menu separators? Or, does the code just "know" that they are there. I'm testing different configurations to reverse enginer the algorith used, but I thought since you were familiar with the AHK source code, you might have an idea.

Edit:
This might clear up my question: how does AHK know that what items are part of the standard menu? I know I can use the handle for the menu items; do the separators have any value associated with them to say that they are part of the standard menu? Or, does AHK just know that menu items X to Y in the structure are for the standard menu, and when NoStandard is called, those items are removed (and not used in the menu rebuild)?

Thanks for any help you can provide.
_________________
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]