Keysharp - the resurrection of IronAHK

Talk about things C#, some related to AutoHotkey
thelegend
Posts: 12
Joined: 23 Mar 2021, 15:29

Re: Keysharp - the resurrection of IronAHK

Post by thelegend » 11 Jun 2021, 11:28

:bravo: Watching from the sidelines and applauding your efforts, @mfeemster!

User avatar
mfeemster
Posts: 47
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

Post by mfeemster » 17 Jun 2021, 00:49

Thanks @thelegend, I am trying to get this done as quickly as I can, but it's going to take a while.

I have finished FileOpen() and the File object and have written unit tests for them.

I will now continue on with other miscellaneous areas of functionality. I'll report back when I have something significant.

User avatar
mfeemster
Posts: 47
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

Post by mfeemster » 10 Jul 2021, 00:15

I am happy to report that I've implemented all of the functions under Window section of the help file:

https://lexikos.github.io/v2/docs/commands/Win.htm

That includes all of the Window, Window Groups and Controls functions, except ControlSend() and ControlSendText() because I will do those functions later after implementing all of the keyboard functionality.

Minus those last two, that's 89 functions in total under the Window section.

I've finished up the various classes/functionality under the Object Types section as well.

I am omitting some of the more obscure/esoteric object design with the Any prototype and such related functionality. I will be using the C# object model because this is a C# program.

Most of the work under the Misc section is done, and I will revisit the remaining parts later. Some may end up not applying to this design, and will thus be omitted.

So what remains at this point? Here is a rough outline:

1) #directives
2) Most control flow is done, but a few more remain, such as the "until" construct and try/catch
3) The External Libraries section, including DllCall(). I am unsure if I will implement COM, I will have to evaluate.
4) The Mouse and Keyboard and Hotkeys and Hotstrings sections. This was partially done by IronAHK, and I have verified it works, so I am not starting from scratch. However, it will need a lot of work to be compatible with AHK, particularly with regard to AHK's pseudo "threads" which allow one hotkey to interrupt another despite being on the same actual thread. I may end up just using real threads to implement this. I will have to evaluate.
5) Fill in any remaining holes such as ControlSend() and ControlSendText() mentioned above.

I think I will work on them in that order. If I am able to complete them, then I will be very happy to say that an initial cut of the program will be ready for people to start testing in limited fashion. At that point, I will begin soliciting help for testing, as well as writing unit tests.

Keep in mind this is only on Windows for the time being, but some design framework is in place for running on Linux. We will only move to Linux after we get Windows running solidly.

Thanks for being patient, we are getting close.

burque505
Posts: 1520
Joined: 22 Jan 2017, 19:37

Re: Keysharp - the resurrection of IronAHK

Post by burque505 » 10 Jul 2021, 07:08

@mfeemster, thanks so much for the update. Regarding COM support, I would certainly love to see it!
Regards,
burque505

SOTE
Posts: 1279
Joined: 15 Jun 2015, 06:21

Re: Keysharp - the resurrection of IronAHK

Post by SOTE » 11 Jul 2021, 03:30

mfeemster wrote:
10 Jul 2021, 00:15
I am omitting some of the more obscure/esoteric object design with the Any prototype and such related functionality. I will be using the C# object model because this is a C# program.
I would like to offer a little push back on this or to at least get greater clarification, because a power of prototypes is in allowing the use of objects without Classes. In scripting languages where this has been implemented, it has been seen as a plus. JavaScript and Lua are 2 notable examples, along with AutoHotkey, as it allows for more choice (to either use objects with Classes or not) and greater simplification of programs.

There is also a trend of various new languages to bypass Class-based OOP all together, such as Go and Vlang (V is a new open-source programming language that has similarities to Go and builds on its concepts further). Hybrid languages such as Object Pascal creates choice by use of Records, where it can be used as an alternative to Classes. C# introduced Records in later versions, to also be an alternative to Classes and Structs, but this type of usage is less common in the language and implemented a bit differently.

Arguably, if Class-based object usage is forced, it might cause problems in terms of freedom of programming style. This might also raise a red flag in terms of porting various code over to Keysharp from AutoHotkey, where objects are used differently or at least various workarounds might be needed. Maybe this isn't anything to worry too much about and of course it's your decision, in terms of which direction things will go. The community applauds your efforts. However, I'm intrigued on your thoughts about this subject.

User avatar
mfeemster
Posts: 47
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

Post by mfeemster » 11 Jul 2021, 20:26

I don't understand the concept of "objects without classes". Can you explain it?

Since it's a C# program, I'll just use the C# object model.

It's a question of why people use AHK. Do they use it to do obscure, esoteric object tinkering? Or do they use it to automate various desktop tasks? My impression was that it was for the latter. If they want to see how quirky they can get their object designs, then Lua or any other others you mentioned is probably a better choice.

SOTE
Posts: 1279
Joined: 15 Jun 2015, 06:21

Re: Keysharp - the resurrection of IronAHK

Post by SOTE » 11 Jul 2021, 21:36

mfeemster wrote:
11 Jul 2021, 20:26
I don't understand the concept of "objects without classes". Can you explain it?

Since it's a C# program, I'll just use the C# object model.

It's a question of why people use AHK. Do they use it to do obscure, esoteric object tinkering? Or do they use it to automate various desktop tasks?
Prototype-based object use is quite pervasive in AutoHotkey, it might not seem so on the surface because object use is so simplified (a credit to its design). Many AHKers can just be thinking of associative arrays, and not making the distinction that there is a bit more going on. I'm bringing this up, as it's not clear how the C# Class-based object model would mesh with the Prototype-based AutoHotkey model. I'm sure there are all kinds of workarounds, but maybe it's something to look at. Since there is no published Alpha of Keysharp yet, just kind of curious how it would be handled.

Wikipedia (https://en.wikipedia.org/wiki/Prototype-based_programming) does a good job in explaining the distinction between Prototype-Based OOP versus Class-Based OOP.

"Objects inherit directly from other objects through a prototype property." --Wikipedia
"An object is a prototype or base if another object derives from it." --AutoHotkey v1 documentation (https://www.autohotkey.com/docs/Objects.htm)

In AutoHotkey (or JavaScript), if you simply wanted to create an object, you just need to use {}, thus thing := {}.

The properties and/or methods don't have to be defined within a Class, but simply assigned to the variable.

For properties or values, you simply need to do- thing.foo := "bar"

Instead of doing the assignments vertically, you can kind of do this all in one go and horizontally, such as- thing := {KeyA: ValueA, KeyB: ValueB}

The methods (functions) assigned don't have to be contained within a Class, but can be derived from anywhere in the script, thus- thing.test := Func("thing_test")

Combined, you would have something like this:

Code: Select all

thing := {}
thing.foo := "bar"
thing.test := Func("thing_test")
thing.test()

thing_test(this) 
{
    MsgBox % this.foo
}
Inheritance is dynamic and simplified. We simply use assignment.

Code: Select all

other := {}
other := thing
other.test()
This simplified use of objects and as extensible associate arrays allows for scripts with code like below:

Code: Select all

Data := MouseGetPos()
MsgBox, % Data.X " " Data.Y " " Data.Win " " Data.Ctrl


MouseGetPos(Options := 3) 
{
	MouseGetPos, X, Y, Win, Ctrl, % Options
	Return {X: X, Y: Y, Win: Win, Ctrl: Ctrl}
}

User avatar
mfeemster
Posts: 47
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

Post by mfeemster » 11 Jul 2021, 22:46

Ok thanks, I'll look into that.

User avatar
mfeemster
Posts: 47
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

Post by mfeemster » 18 Jul 2021, 17:37

I am happy to announce that I have try/catch/tryelse/finally/throw/OnError() working.

I will work on the remaining missing control flow items next.

Post Reply

Return to “C#”