AutoHotkey Community

Not really. I've thought about it. How should the method be chosen where only one operand is an object, or both operands are different "types" of objects?
I've thought about it, and I agree. The simplest way would be for TokenToXxxx (where Xxx is String, Int64 etc) to invoke a method of the object. Memory allocation is an issue though, since these functions are normally only provided with a buffer of MAX_NUMBER_SIZE (256) bytes.
No. To allow that syntax would mean essentially throwing away validation of function names. However, you can do MyClass[p1, ... pn], which will call MyClass.base.__Get as long as p1 isn't a valid key. When an object is used as a "method" of some other object (like calling_obj.foo() where calling_obj.foo == method_obj) , it is called like method_obj[calling_obj](params) which generally calls method_obj.base.__Call since method_obj[calling_obj] wasn't assigned. (This is how MetaProps works.) Similarly, you could use any unassigned key (but this value will be passed to __Call): method_obj[""](params). If you think it would be useful, I could allow method_obj.(params). (I initially thought it seemed a bit odd/ambiguous.)
Do you see an exit code? SciTE tells me -1073741571, which is 0xC00000FD; i.e. stack overflow.
In other words, Object("base", TThumb, "label", "thumb") causes MetaProps to be called (to set .label := "thumb") before obj.label exists. When MetaProps tries to access the property, it recurses. It does this repeatedly until stack overflow occurs.

To avoid triggering meta-functions, set the "base" last or use _Insert. If you think Object() should only do raw assignments, let me know. If you thinks the current behaviour is better, also let me know. (You=anyone.)

Alternatively, you can bypass meta-functions using ._Insert().

Let the objects handle that stuff internally. You can handle mixed expressions as:


Unary operators don't have that problem at all.


I would personally use such thing. (all the time)

.
I think current behavior is better. I was well aware of the importance of ordering, I guess it slipped true.

_________________

In R43 bellow code stopped working:



The A_LastError value is always ERROR_PROC_NOT_FOUND (127)

I tried different ways of calling, using astr and A but results are always the same.

_________________

To be clear, I would only remove the requirement that the string between . and ( is not empty. I suppose it would work as follows:
__Call would work the same as for other methods, but of course the method name parameter would be an empty string.
I doubt it.

• GetProcAddress has no separate ANSI/Unicode versions. It accepts an LPCSTR (not LPCTSTR or LPCWSTR), so is always "astr".
• GetWindowLong really isn't a function - it's a macro for GetWindowLongA or GetWindowLongW. MSDN gives it away with "Implemented as ANSI and Unicode versions." When you call it in AutoHotkey, DllCall adds "A" or "W" when it fails to find "GetWindowLong". (I suspect you knew this but overlooked it this time.)
• GetModuleHandle is also a macro for 'A or 'W, and accepts LPCTSTR, effectively the native string type for the current build - "str",string or "ptr",&var or "uint",&var (in current/32-bit builds).

Thanks for posting, though.

If I understood it right, I vote for yes please


That would be great


Personally I do not care. But from a user/beginner perspective I would suggest not to use it there, unless something like this would work (I know we discussed before )

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

I know about marcros, A, W, and other stuff plus I am sure I tried that code. I was testing with several Win APIs but I posted only that one.
One another was DefWndProc. Can you explain me why this doesn't work ? I don't know maybe I just didn't sleep right last night...


It is equivalent to "wstr", "DefWndProcW" so it should....


I didn't think about this, but it looks like nice syntax suggar. The extreme variant looks a bit strange (obj......func()) but I guess its better then to write obj.obj2.boj3.obj4.obj5.obj6.func() each time.

EDIT:
Ah, I see (brainwashed obviously)

I reread your post to notice color changes of one letter (which is not easy for me as I have astigmatism and am blind for some colors). I also yesterday noticed a dot after 3thd reading.

_________________

What's better for a beginner, and why?
Of course that should work; by "only do raw assignments" I really meant "not trigger meta-functions." If it didn't work, parameter order would no longer be an issue. That is; the rest would effectively be raw assignments since there would be no base to define alternative behaviour.

On the other hand, I was considering allowing this:
This would work without ambiguity because Object() currently doesn't support an odd number of parameters (except for a lone integer parameter).
I don't see anything "nice" or useful in it, only potential headaches.

When I proposed it, I didn't think about "long dot" syntax. I am interested in calling objects as functions without container objects. In that sense, "obj.()" is the closest to that wish.

_________________

You are right, after thinking about this a while I agree.
How about to support this?


EDIT
Currently this looks to crash, could be [] same as [""] as well

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

I just want to report that I successfully ported very complex script, Multi-Rename Script to Unicode.

I want to share my impressions about it.

First, I am impressed how things work flawlessly.

One big concern, however, are DllCalls. DllCalls were failing in such measure that I spent entire day debugging and tracking which one failed and why (MRS has 20 or so modules). Because some APIs have W variants and some only A, and because str is silently converted to wstr, and because you have to use Transform ToUnicode with output str's, it can be hard to track problems to unprepared and habitual mind. I almost wished the default string format for DllCall is still astr

There are also problems with direct string memory handling if you have those (I happened to have every kind of unsupported sh*it in MRS).

Then, I wanted to make sure MRS could be run with both AHK and AHKL so I introduced A_IsUnicode ? all around plus Translate( ByRef var ) function that translates to Unicode from centralized place so the only change in switching ahk branch is the need to put return at start of Translate() func (making function that doesn't depend on Transform keyword is feasible, because AHK complains about "ToUnicode").

All in all, if you need to port things the number of DllCalls and NumGets/Puts will influence the job a lot and if you need to support both AHK and AHKL its doable with single version of the script.

Finally, I am sorry if I posted bunch of stupid questions in the process

_________________

I don't think so. It would have to be inconsistent with regular (non-dynamic) function calls, in that each optional parameter's default value would be ignored. (There's no way in advance to know what the default value of a parameter in an object-invoke should be.)
It crashes because load-time validation of the parameter count doesn't occur - the "function call" isn't determined to be ObjSet until after the parameters are processed. I've added a run-time check to Object::Invoke to compensate.
That would reduce its usefulness. If you want it to work that way, the following should work (and even prevents the crash mentioned above):
I've commited a fix for the crash and updated the downloads to include this and some other fixes I had committed earlier. I'm updating my build & release process, so for now I haven't incremented the revision number. I might drop revision numbers entirely.


majkinetor, I'm glad to hear of your success. Btw, jackieku and fincs did most of the real work behind the unicode changes.

why that? I don`t see any benefit to do this. Please do not answer with "I don`t see any benefit not doing this.".

In example, I am using one older version for just one specific script. And updating to one newer version is more risky than in mainstream Ahk. So I stay with old version. Someday it could be important to know the version number.

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

What happened with this fix ?

_________________

I have a problem with IniWrite:

What I get is UTF-8 + BOM Config ini file with garbage.

I also have problem with code bellow - It works when test.ini is UTF8 but doesn't with UTF8+BOM when it returns error 2 (file not found).


Thx for help.

_________________

If the APIs are from the Windows itself, I believe almost all APIs have "W" version. (If there is no "W" version, why add "A" to the function name?) Some of them may not have "A" version (e.g. CommandLineToArgvW and many COM interfaces). Unicode is not a new thing for Windows, it just a new thing for AHK.

There are some tips for DllCall() at AutoHotkeyU's wiki page.