AutoHotkey Community

- I was interested in how much work has been done re. this, i.e. bringing Gui/Menu object functionality to AHK v1.
- If people have some useful information to share re. this, there is a chance, a small chance, that I might look into it more seriously. Unlike with other projects, I cannot easily estimate the difficulty.
- Obviously, if people help contribute to my object queries (e.g. here/in Ask For Help), this makes things more likely.

- Anyhow, there is one example, that I am definitely interested in. That is A_TrayMenu. I've attempted to backport A_TrayMenu.ClickCount := 1 to AHK v1, for my AHK v2 functions for AHK v1 library. I've succeeded, although I would welcome any suggestions/improvements to the script. In particular could I simply create a class called A_TrayMenu, instead of creating an instance of a class called A_TrayMenu.
- This was useful:
GeekDude's tips and tricks - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=7&t=7190

Make a function call itself on script start (Useful for init functions). Note this can also work with classes

Code: Select all

MyFunction()
{
    Static Dummy := MyFunction()
    MsgBox, I see you %A_UserName%
}

- AHK v1-only backport of A_TrayMenu.ClickCount. Links:

Menu
https://autohotkey.com/docs/commands/Menu.htm
Menu Object
https://lexikos.github.io/v2/docs/objects/Menu.htm
TraySetIcon
https://lexikos.github.io/v2/docs/comma ... etIcon.htm

GUI
https://autohotkey.com/docs/commands/Gui.htm
GuiCreate
https://lexikos.github.io/v2/docs/comma ... Create.htm

Interesting.

FYI the A_TrayMenu example didn't work for me. It's a tested example? I'll do more troubleshooting.

Edit: I'm not sure why that didn't work. But this does for me, and looks better, too, I think. I added a default value, and a get method to be consistent with v2. I've never used properties before, so I don't know if this is properly done or not.

- @derz00: Yes I did test it, although it's not a bad idea to ask. I had some false positives resulting from some previous tests. I've fixed the script now. I did not want to put global A_TrayMenu := new TrayMenuClass in the main body of the script, only in the library, this is because, otherwise you have a script that is not two-way compatible.
- Thanks for your example script, I like what you've done there.
- Super-global variables are interesting, if you define a variable as super-global anywhere in the script, with/without executing the line, that makes the variable super-global, but it only sets the contents of the variable if you execute the line explicitly.

Alright, your example works now. I thought I had tried it by changing the global's position. I guess not.

But again, I would definitely recommend using properties over the meta-function style. But maybe you're intending to save code space. This might be possible to do, but would be less-than-ideal design, and would be harder to do and more ugly to code if you will use __Get() to return the properties.

Yes, for this simple example, __Set() seems best. However, after looking through the specs for the Menu object, if I wanted to expand the class, I would probably avoid using __Set().

Hello you two .

I did not want to put global A_TrayMenu := new TrayMenuClass

Do as derz00 says, use a property, and change the class name, there is no need to initialise the class, Cheers.

Or you could use a Singleton pattern and name the class A_TrayMenu if you really want to use __Set and __Get.

Hello you two.

Very nice Helgef. One would think that would have been obvious sooner.

@nnnik, like your automatic init example here? https://autohotkey.com/boards/viewtopic ... 44#p175344

No I was actually refering to my SuperGlobal Automatic Init Singleton:
https://autohotkey.com/boards/viewtopic ... 21#p176521

- @Helgef: 'Do as derz00 says'. Hahaha. I've basically said that I agree with him, and that if I expand the class, I'll probably take that approach.
- Also, many thanks for your example, that uses the class directly.
- @nnnik: Thanks for sharing the link to your singleton example, I knew the thread, but I wasn't sure which example you meant.
- @derz00/@Helgef/@nnnik: All three of you are good candidates for backporting the Gui/Menu classes. What I recommend is, that all four of us (plus anyone else if you are interested) have a go at recreating the Menu class, which is relatively small. And we can compare results. Hopefully this would reveal all of the main issues that backporting the Gui class would entail.
- I had expected that someone would have offered to backport the Gui class, and to recreate Progress/SplashImage for AHK v2 by now. Why hasn't this happened yet?
- I will have a look at Progress/SplashImage, but it might be a few months from now.
- I would still recommend someone else to backport the Gui class, since I tend to deliberately avoid both the AHK v1 GuiXXX commands and object classes, in favour of my own GUI functions. Cheers.

jeeswg wrote:Why hasn't this happened yet?

Probably because both Gui and Menu objects are relatively quite new. But that would be a good idea. I would like a GUI obj wrapper for v1 but not for compatibility reasons.

Here's a start by RUNIE actually. https://github.com/Run1e/AHK-ImgurAPI/tree/master/gui

jeeswg wrote:Why hasn't this happened yet?

because people who want to use v2 syntax, they simply download v2 and use it.

I would be happy to help with this since the current Syntax is very quirky.
I won't be able to switch to AHK v2 since it's syntax is still rather unstable and I don't want to rewrite anything just because of some update.
The most I could do right no though is helping you get started by writing a simple Skeleton that you could use to complete the other tasks more easily.

guest3456 wrote:because people who want to use v2 syntax, they simply download v2 and use it.

Indeed . And more importantly, people who prefer error messages over silent failure use v2 instead.

I won't be able to switch to AHK v2 since it's syntax is still rather unstable and I don't want to rewrite anything just because of some update.

I have made the guess, that whatever code I write for v2 today will require less conversion tomorrow than if I had written it in v1 .

Yeah but what if you sum tommorrow the day after tommorrow and the entire next month?

I used italics to indicate that today and tomorrow wasn't meant to be interpreted litteraly . From when I started using v2, maybe 6 months ago, I have needed to do very few updates to my code due changes to the language, oth, I didn't write an imense amount of code and there was a large gap in the v2 development. But, as I said, it is a guess. However, there is no guess in that v2 is much easier to work with. And the fact that it is chaning makes it more intetersting, for me at least.

Cheers.

Of course I am aware of the fact that you don't mean tommorrow quite literally. My post is also ambigous since it could talk about both time and versions. But if I want each of my libraries that I personally use to work with the newest AHK version it's just too much work.
OOP and GUI just belongs together - there is no advantage to not using it. I probably could just grab RUNIEs library that has been mentioned in this thread and start using it.
If we use a library thats forward compatible things will be a lot easier.

- Thanks for your responses.
- My plan is to at least recreate the Menu object. People can then pick apart what I did. However, I would recommend people just edit my future script directly, over three-dozen back-and-forth messages trying to improve it.
- @nnnik: I would most welcome a skeleton. I believe fincs did a lot of work on this, i.e. it could be a useful basis to save you any unnecessary effort. In general, if anybody knows of any relevant links re. creating a GUI object in AHK v1, please post them here.
- If working on the GUI object, I'm not sure what the best starting approach would be, my hunch is to implement some general functionality, to recreate my 'control zoo' examples, and to pick the most difficult control and to try and get that working. What do people consider the most difficult control, listview? Thanks.

GUI:
AFC (fincs)
CGui (evilC)

Hopefully I found and started most part of my own redist classes not starting from scratch but using run1e's ones instead. There are accessible for eternal beginners like me who, resolutely, don't want to go into detail (but yearning for sufficiently safe a efficient codes at least off course and holding in high regard those who do, are commited to coding) and nevertheless come with the complete functionality of the built-in ahkv1 command it is the wrapper of.

Gui class has already been linked here's the menu one:
Class Menu (RUNIE)

- Thanks a lot @A_AhkUser.
- Two links that guest3456 provided on my GUI rethink thread.
AFC - AutoHotkey Foundation Classes v0.1 (Includes OOP GUI) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=1798
Proposed New GUI API for AutoHotkey v2 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=2998