OK, I think I should've mentioned it from the start. The development of COM(.ahk) in
public by myself has been finished. There will be only bug fixing, but no more enhancement, possibly except for COM Error Handling if I ever enter into it and it turns out to be suitable to be used inside from a mere script. However, I don't think it will happen near soon as there are too many interesting subjects around. I think my interest is entering into the rather sensitive area, so probably even non-COM works will be kept in private mostly, I suppose. Anyway, my point here is that I'd like to avoid being constantly detracted by the finished work, especially by a hard-to-track error report unless the user provides sufficient infos for it.
So, I urge to always match the number of parameters.
My point is that COM.ahk does not enforce this.
If I enforce it, i.e. specifying the number of parameters, it would really stop working without any
explicit error message, when using mismatched number of parameters with the target AHK's functions. Without it, the functions may be still working even if the (intended) number of parameters is different. The only problem would be the stack mis-adjustment, but it would be corrected automatically thanks to the extra work of AHK/Chris.
As I said, DHTML events. ALL of them. DispParams contains zero params.
OK, you meant the individual events in DHTML, not the event interface. No problem with adding it (probably I'll add psink/this, not NumGet(this+12)). However, I'd like to ask first if it's not feasible using
Global variables with these, as if I add it I have to correct all of the event-related examples posted so far accordingly.
A "thread" in AutoHotkey is basically a snapshot of global script properties; anything that the manual says each thread retains its own settings for.
I see, you meant AHK's threads. I would say then there would be nothing to prevent from using
Fast, at least apparently. I even added
Critical in COM_DispInterface() for this. But, this perfectly seeming condition was my concern. If an error ever occurs around this
Fast/Slow mode in this near-ideal condition, it will be really hard to track down, especially when it's occurred in other user's machine. In fact, there is no 100% guarantee that it'll never happen, especially with COM. We don't really know what COM manager is doing behind the scene. So, unless I'm convinced that Fast mode improves the performance significantly over Slow mode, probably I may not add it. But, this doesn't prevent you from using it on your own, of course.
DllCall does stack cleanup.
This is what I meant by overhead: the caller should keep an eye on how many bytes are pushed on the stack, then clean them
after the call is returned with Cdecl. This after job isn't necessary with Stdcall, AFAIK.
Actually, I'm not sure that CDecl has any real effect. It seems AutoHotkey restores the stack the same way regardless:
I already knew it. That wasn't the point. I talked about things in principle. If taking into the extra safe-guard of AHK, this discussion wasn't necessary from the beginning. Cdecl/Stdcall won't matter with AHK's DllCall(), at least most times if not all.