Menu object

Discuss the future of the AutoHotkey language
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Menu object

27 Dec 2017, 14:34

Hello :wave:.

For reference, ahk v2 docs, Menu object. This is excellent, both in regards to the documentation and usage :clap:.

Minor comments, questions, suggestions...
  • Perhaps add an EventObj parameter for the menuCreate() function, similar to the guiCreate() EventObj (event sink) parameter.
  • I wonder if there are any plans on adding features, such as additional properties (count, isChecked , ...? ) and/or an enumerator? (I did see the count example)
  • I like the handle property better than file object's __handle, why the double underscore?
@ lexikos, Thank you very much for AutoHotkey Christmas Edition :xmas:
lexikos
Posts: 9551
Joined: 30 Sep 2013, 04:07
Contact:

Re: Menu object

28 Dec 2017, 22:38

  • There's only one event (Click) and it is per-item, not per-menu. It therefore makes no sense to pass an event sink object to MenuCreate().
  • There are no plans, only open-ended potential and a lack of urgency (i.e. adding these features later should not cause problems).
  • Handles are low-level (like the underscore...). Interacting with a file handle in the wrong way may cause the File methods to behave unexpectedly, as the File object cannot compensate for changes it does not detect. However, I will probably remove the underscores to be consistent with the newer objects (Gui and Menu).
wolf_II
Posts: 2688
Joined: 08 Feb 2015, 20:55

Re: Menu object

28 Dec 2017, 23:09

Helgef wrote:@ lexikos, Thank you very much for AutoHotkey Christmas Edition :xmas:
+1
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: Menu object

29 Dec 2017, 07:24

There's only one event (Click) and it is per-item, not per-menu.
I'm satisfied with your answer, and I agree that having only one event makes the suggested addition less important. Regarding the per-item part, from the viewpoint of a simple user, that is me, there was no difference in per-item in a menu, and per-control in a gui. I thought it could be convenient to specify a method name for the Label-or-Submenu parameter. BoundFuncs will do fine ofc.
Handles are low-level (like the underscore...).
I didn't make the visual connection before :D.

Thanks for your time, cheers.
Hello wolf_II :wave:
lexikos
Posts: 9551
Joined: 30 Sep 2013, 04:07
Contact:

Re: Menu object

30 Dec 2017, 00:28

Helgef wrote:I thought it could be convenient to specify a method name for the Label-or-Submenu parameter.
I see. I'm not sure if I thought that would be inconsistent with GUI or just didn't think it through. Now I see the only difference would be in passing the name/function to Add() vs. passing it to OnEvent(), and that difference already exists. It's not the event sink that makes no sense for MenuCreate(), but OnEvent(). I was probably forgetting that the GUI object's event sink is used by both the GUI and its controls.

In any case, my goal for the initial Menu object API was merely parity with the v1 commands, minus the global menu names. I may use your suggestion.
lexikos
Posts: 9551
Joined: 30 Sep 2013, 04:07
Contact:

Re: Menu object

26 Mar 2018, 05:35

I wrote the code for this (edit: menu event sink) but abandoned it after working out how to implement closures (added in v2.0-a090), which I think are more suitable (and of course, in no way specific to this one API).
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: Menu object

26 Mar 2018, 06:34

Hohoho, is it christmas again?! Thank you very much :clap:.
Cheers :xmas:
User avatar
Flipeador
Posts: 1204
Joined: 15 Nov 2014, 21:31
Location: Argentina
Contact:

Re: Menu object

31 Mar 2018, 14:39

A MenuDelete/Destroy function should be added... Or am I missing something? :think:

Code: Select all

MenuDelete(MenuObj)
{
    MenuObj.Delete()
    DllCall("User32.dll\DestroyMenu", "Ptr", MenuObj.Handle)
}
lexikos
Posts: 9551
Joined: 30 Sep 2013, 04:07
Contact:

Re: Menu object

31 Mar 2018, 17:32

Why should it? If you still have a reference to the object, you can do things with it. If there aren't any references to the object, the menu is already destroyed.

You can still call MenuObj.Delete() to free some resources and ensure there aren't any circular references.
User avatar
Flipeador
Posts: 1204
Joined: 15 Nov 2014, 21:31
Location: Argentina
Contact:

Re: Menu object

31 Mar 2018, 17:40

If there aren't any references to the object, the menu is already destroyed.
How is this?
Why should it?
What's happening here?

Code: Select all

F1::
MenuObj := MenuCreate()
Handle  := MenuObj.Handle
MenuObj.Add("ExitApp")
MenuObj.Show()
MenuObj := ""
Return

F2::
MenuFromHandle(Handle).Show()
Return

I understand that it is not absolutely necessary, you can only create the menu once and delete all its elements... I thought it would be nice to add this small function.
lexikos
Posts: 9551
Joined: 30 Sep 2013, 04:07
Contact:

Re: Menu object

31 Mar 2018, 19:53

That's a bug. The menu object currently isn't deleted due to a reference counting error.

"It is not absolutely necessary" and "it would be nice" don't exactly support your request. Why do you want it?

Unlike Menu Name, Delete, Menu.Delete() doesn't delete the menu because it can't. The object itself is what was being deleted, but now you have a reference to it, so deleting it would give you a dangling pointer and ultimately crash the script. "Destroy" could destroy the Win32 menu but leave the Menu object intact and able to create another Win32 menu as needed, but what's the purpose?
User avatar
Flipeador
Posts: 1204
Joined: 15 Nov 2014, 21:31
Location: Argentina
Contact:

Re: Menu object

31 Mar 2018, 20:33

That's a bug. The menu object currently isn't deleted due to a reference counting error.
Are you saying that when you do MenuObj := "" the menu should be destroyed? I thought that MenuObj behaved like GuiObj.
lexikos
Posts: 9551
Joined: 30 Sep 2013, 04:07
Contact:

Re: Menu object

31 Mar 2018, 21:03

Yes.

GUI objects are designed to stick around even if the script doesn't refer to them directly because the user can interact with the GUI, and the GUI can call event callbacks, giving the script a reference to the GUI object as a parameter. Actually, the GUI is destroyed (and the object deleted) if the user closes it and AutoHotkey itself holds the only reference to the object. I'm not sure if that's documented. If the GUI is never shown it won't be automatically destroyed (because it can't be closed), but it can still be used to receive messages, which can call event callbacks. It can also be shown or retrieved by WinTitle.

With a menu, it is much more likely that once the script releases its references to the object (including references stored in a GUI or another menu), it will have no way to use the menu at all, or to destroy it. Rather than inviting memory and handle leaks, the menu should be destroyed automatically. If you want to keep the menu in memory with only a handle, you can AddRef() the menu object.
User avatar
Flipeador
Posts: 1204
Joined: 15 Nov 2014, 21:31
Location: Argentina
Contact:

Re: Menu object

01 Apr 2018, 06:26

Yes.
I proposed MenuDelete because there was no way to delete the menus (due to a bug)... But it's already fixed; Thank you.
Is this documented? I do not see it. Maybe it would be nice to add in the MenuCreate page that when the menu object and all its references are deleted, the menu is destroyed along with all its submenus.
Rather than inviting memory and handle leaks, the menu should be destroyed automatically. If you want to keep the menu in memory with only a handle, you can AddRef() the menu object.
I agree. :)

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 10 guests