Page 4 of 6

Re: New test build - Functions and Objects as Labels (and m

Posted: 24 Jan 2015, 23:14
by evilC
lexikos wrote:To save further derailing the topic, I've moved the OnMessage discussion to Wish List.

evilC: Use bind v1.2 from the top post.
Is it possible for RegisterCallback() to able to accept bound functions also?

Re: New test build - Functions and Objects as Labels (and m

Posted: 25 Jan 2015, 02:02
by lexikos
It effectively already can; you just need a different kind of bound function.

Code: Select all

x := new Thing, x.Label := "Fred"
cb := new CCallback(x.M, [x], "F", 1)
DllCall(cb.ptr, "int", 42)

class Thing {
    M(arg) {
        MsgBox % this.Label ", " arg
    }
}

class CCallback {
    __New(fn, bound_args, opt:="", argc:=0) {
        if !(IsObject(fn) || (fn := Func(fn)))
            throw Exception("Invalid function", -1, fn)
        this.fn := fn, this.args := bound_args, this.argc := argc
        this.ptr := RegisterCallback("CCallback_", opt, argc, &this)
    }
    Call(parg) {
        args := this.args.Clone()
        Loop % this.argc
            args.Insert(NumGet(parg + (A_Index-1) * A_PtrSize, "uptr"))
        return this.fn.Call(args*)
    }
    __Delete() {
        if this.ptr
            DllCall("GlobalFree", "ptr", this.ptr)
    }
}

CCallback_(parg*) {
    return Object(A_EventInfo).Call(parg)
}
You could take it further than that - convert parameters to the appropriate types, and such.

One potential pitfall is that you need to ensure the CCallback object isn't deleted before you're finished with the callback. The way I've designed it, you manage the lifetime of the object and the object takes care of freeing the callback. With normal callbacks, usually the script just ignores memory management (or more rarely, calls DllCall("GlobalFree", "ptr", cb)).

Changing RegisterCallback to accept an object wouldn't add much value, and would have a higher cost to retain backward-compatibility. That has to do with how it overrides the behaviour of the parg* parameter (see above) to pass a pointer instead of an array.

Another problem is that RegisterCallback returns a pointer to an opaque data structure, which you free with GlobalFree. Instead, we would need a function for freeing the callback structure and any associated object.

Re: New test build - Functions and Objects as Labels (and m

Posted: 25 Jan 2015, 10:12
by geek
Not to mention the script you had me draft up at 1AM last night :yawn:

Code: Select all

#persistent

MyObject := new ExampleObject("Random String")
Callback := MyObject.SetUpCallback()

DllCall(Callback, "UInt", 20, "UInt", 40)
return

class ExampleObject
{
	__New(String)
	{
		this.String := String
	}
	
	SetUpCallback()
	{
		return RegisterBind(this.CallMe, "Fast",, this)
	}
	
	CallMe(Integer, AnotherInt)
	{
		MsgBox, % this.String "," Integer "," AnotherInt
	}
}

RegisterBind(Params*)
{
	if IsObject(Params)
	{
		this := {}
		this.Function := Params[1]
		this.Options := Params[2]
		this.ParamCount := Params[3]
		Params.Remove(1, 3)
		this.Params := Params
		if (this.ParamCount == "")
			this.ParamCount := IsFunc(this.Function)-1 - Floor(Params.MaxIndex())
		return RegisterCallback(A_ThisFunc, this.Options, this.ParamCount, Object(this))
	}
	else
	{
		this := Object(A_EventInfo)
		MyParams := [this.Params*]
		Loop, % this.ParamCount
			MyParams.Insert(NumGet(Params+0, (A_Index-1)*A_PtrSize))
		return this.Function.(MyParams*)
	}
}
Edit: added a return

Re: New test build - Functions and Objects as Labels (and m

Posted: 25 Jan 2015, 10:14
by evilC
Oh, I thought you had to go before you got it working...
Sorry dude.

Re: New test build - Functions and Objects as Labels (and m

Posted: 25 Jan 2015, 10:16
by geek
Nah, it works fine. What I was doing at the end there was making it so it would infer the number of parameters in the registered callback function. I had pasted my finished version not long before leaving ;)

Re: New test build - Functions and Objects as Labels (and m

Posted: 25 Jan 2015, 19:30
by evilC
Well I actually have GeekDude's code working in there now, will look at lex's example and see if I can digest what either of you are doing. I vaguely get the idea.

For now though, my last major niggle with AHK code structuring has bitten the dust and AHK feels like a new toy.

This thread is so full of win it deserves a little dance.

:dance: :dance: :dance: :dance: :dance: :dance: :dance: :dance: :dance: :dance: :dance: :dance:

Re: New test build - Functions and Objects as Labels (and m

Posted: 31 Jan 2015, 06:10
by lexikos
Update

I've uploaded a new build. It's not very interesting since it mostly consists of internal changes, but needs to be tested on a variety of scripts.

v1.1.19.02-17+gcd46158:
  • Simplified pre-parsing of #if/static var initializers.
  • Refactored pre-parsing of blocks and if/else/loop/etc. to fix bugs and reduce code size.
    • Fixed crash on load when an auto-include ends with if/else/loop/etc.
    • Fixed crash when stepping past RETURN in a function at the very end of an auto-included file.
    • Fixed try global x := fail(), y := fail() not applying try to the second declaration.
  • Fixed break n to not terminate the thread when until is present.
Look out for any changes in behaviour (i.e. bugs) related to #if expressions, static var initializers, or grouping of statements (under if/else/loop/for/while/try/catch/finally).

Re: New test build - Functions and Objects as Labels (and m

Posted: 31 Jan 2015, 07:58
by fincs
TillaGoto.ahk line 1116:

Code: Select all

---------------------------
TillaGoto.ahk
---------------------------
Error:  A Goto cannot jump from inside a function to outside.

	Line#
	1103: Break
	1106: if Not IsValidHotkey(t)  
	1106: {
	1109: u := u ? u : GetScriptEscapeChar(s)
	1110: v := v ? v : GetScriptCommentFlag(s)
	1112: StringReplace,t,t,%u%%v%,%v%,UseErrorLevel
	1115: if (Not ErrorLevel) || (ErrorLevel &&  Not IsValidHotkey(t))  
--->	1116: Goto,NextIteration
	1117: }
	1120: t .= "::"  
	1123: sLabels0 += 1
	1124: if bExternal  
	1124: {
	1125: sLabels%sLabels0%_File := sPaths0
	1126: sLabels%sLabels0%_Line := LineFromPosEx(s, i)

The program will exit.
---------------------------
OK   
---------------------------
GenDocs/RetrieveDocs.ahk line 118: same error

Re: New test build - Functions and Objects as Labels (and m

Posted: 31 Jan 2015, 11:31
by evilC
I can confirm that my Input command Bind technique using #if blocks which add hotkeys when a class property is TRUE, still works fine with this build.

Re: New test build - Functions and Objects as Labels (and m

Posted: 31 Jan 2015, 19:19
by lexikos
Thanks fincs and evilC.

I've uploaded a build fixing the issue fincs reported - v1.1.19.02-20+gaa8308b.

Re: New test build - Functions and Objects as Labels (and m

Posted: 02 Feb 2015, 20:53
by geek
I've just replaced my binaries with the latest ones from the original post in this thread (Not just GeekBot's). So far everything seems to be working fine

Re: New test build - Functions and Objects as Labels (and m

Posted: 06 Feb 2015, 00:22
by evilC
Hi Lex, I tested the new build and can confirm working.

Also, I wrote AHK-EXE-Swapper to let people easily swap in/out test builds etc.

I notice you are making changes to localization, not really sure I understand the implications of what you are saying yet.

I have a user with an AZERTY keyboard complaining that when one of my scripts sends 1, it holds Shift, seemingly because 1 is a shifted character on his keyboard.

I made a post but nobody seems to know how to work around.
Is that something that is adressed by this build? Is it a fundamental limitation? Or am I just missing an existing way to do it?

Re: New test build - Functions and Objects as Labels (and m

Posted: 06 Feb 2015, 02:40
by lexikos
evilC wrote:I notice you are making changes to localization,
Not specifically. Just fixing a bug. It wasn't even the point of the test build.
I have a user with an AZERTY keyboard complaining that when one of my scripts sends 1, it holds Shift, seemingly because 1 is a shifted character on his keyboard.
Does it produce the right character? If so, it's working properly and the complaint is unfounded.
Is that something that is adressed by this build?
Clearly not.

Re: New test build - Functions and Objects as Labels (and m

Posted: 06 Feb 2015, 03:41
by evilC
Yes, but it hits another key that you didn't ask it to, and I can see no way around it.

On QWERTY keyboard, I suppose the inverse is true - you cannot send ! " $ etc without hitting shift, but in this case (A game), it kind of nobbles AHK completely as a way of sending actions if you cannot send 1 on it's own without shift.

Again, with a QWERTY keyboard, you have {Blind} to mitigate this, but apparently Send {Blind}{1} on an AZERTY keyboard does not send & (The unshifted character on the 1 key) as I hoped it might.
This means that writing scripts that send number keys problematic if you wish them to work with QWERTY or AZERTY keyboards in games.
Would it maybe be possible to get something similar to {Blind} to cater for this case?

If you do not wish to derail this thread any more, I have a thread on this subject here.

Re: New test build - Functions and Objects as Labels (and m

Posted: 06 Feb 2015, 04:26
by lexikos
evilC wrote:If you do not wish to derail this thread any more,
You've derailed it quite enough. My terse responses had an intended air of "I don't care to discuss this here". Obviously I was too subtle.

Re: New test build - Functions and Objects as Labels (and m

Posted: 07 Feb 2015, 22:16
by lexikos
Update - v1.1.19.02-27+gf3cb786

Changed the way OnMessage works with function references/objects.

OnMessage(Msg, Object [, MaxThreads])
  • If MaxThreads is omitted or non-zero, registers Object to be called when Msg is received.
  • If MaxThreads is 0, unregisters and releases the object.
  • If registration failed, an exception is thrown.
  • No return value.
  • Multiple objects/functions can monitor the same message. The most recently registered handler is called first.
  • Monitors can safely unregister themselves or other monitors.
Each message also has a single "legacy mode" handler, so OnMessage with a function name or empty string behaves exactly as before and does not affect the new handlers.

So OnMessage(x, "Fn") behaves as before, but OnMessage(x, Func("Fn")) does not affect other handlers (unless Fn returns a value when called, in which case the other handlers are not called).

Minor fixes from master branch:
  • Use GetGUIThreadInfo instead GetFocus to retrieve focused control (thanks HotKeyIt).
  • Improved remapping to allow scXXX::Y when scXXX has no corresponding VK.
  • Fixed ListView to not raise '*' events for unknown notifications.

Re: New test build - Functions and Objects as Labels (and m

Posted: 08 Feb 2015, 03:44
by Coco
Nice, convenient. Works fine here.

Re: New test build - Functions and Objects as Labels (and m

Posted: 08 Feb 2015, 09:22
by evilC
Damned sweet, but would it be possible to allow setting an option to switch the order? It would be nice if it were possible to have the messages fire in the order they were registered.

Say you have a library that uses OnMessage to handle GUI scrollbars - if someone writes a script using this library that listens to mouse wheel messages, it would be desirable for the scroll library to be able to intercept the message first and have a chance to do it's thing before the script using the library gets the message.

Re: New test build - Functions and Objects as Labels (and m

Posted: 08 Feb 2015, 18:54
by evilC
Any suggestions as to whether it is possible to compile a script using these test builds?

It seems the normal AHK2Exe needs .bin files, which I do not have for this test build.

Re: New test build - Functions and Objects as Labels (and m

Posted: 08 Feb 2015, 20:20
by lexikos
No. You would need to download the source code and compile AutoHotkeySC.bin first.