Tables is a property with no parameters. Item is a method.
document.Tables[1] is property retrieval. It is a single operation where a property
Tables is invoked with parameter 1. How it is dispatched depends on the implementation of the object. I can offer some conjecture based on
"Item" is not a property, which I believe will be accurate:
- The object's implementation finds a property Tables. It was asked to retrieve a property, so this is good. If this property had parameters, it could be invoked directly. However, it does not have parameters, so instead the property's value is retrieved as t, then t[1] is invoked.
- The default member of t is Item (it's a common convention, but technically the default member could have any name), so t[1] is an attempt to invoke t.Item[1].
- As it tells you, Item is not a property, so t.Item[1] is not valid.
You might think that if
document.Tables[1] retrieves Tables and then invokes
.Item[1],
document.Tables(1) should retrieve Tables and then invoke
.Item(1). Past second-hand experience tells me that Office and MSHTML COM objects don't work this way. I suppose that this object's implementation throws an error because it finds a property
Tables when it was looking for a method.
If you use
(document.Tables)(1), AutoHotkey will invoke Tables as a property and then invoke the default method of the Tables collection, which I presume is Item. This avoids relying on the object itself to indirectly dispatch the
Item method via the
Tables property.
v1.1 was designed (but I think
not documented) to allow ambiguity between properties and methods of COM objects, in line with the ambiguity permitted by languages like VB, where array indexing and property parameters use the same syntax as function/method calls. Due to that ambiguity and perhaps a lack of clear guidelines, COM objects from different libraries (even just Microsoft ones) ended up being inconsistent with each other; e.g. Item and _NewEnum are sometimes properties, sometimes methods.
v1.1 invokes with inconsistent combinations of the
method and
property flags depending on a number of undocumented factors. When both flags (
method and
property) are present, the Office and MSHTML COM objects may do things like retrieve the
Tables property and then invoke its
Item method, but COM objects which could and should distinguish between
property retrieval and
method call are unable to do so.
v2.0.6 was intended to fix some cases that were clearly incorrect, with the one documented example being "
x.y acting as
x.y()". In particular, if an object from another instance of AutoHotkey (v1 or v2) is accessed via COM, prior to v2.0.6 it was impossible to retrieve the value of a property if that value was a function, because the function was called automatically.
The change had more far-reaching consequences than I was expecting, but ultimately I decided to treat the previous behaviour as incorrect, even in cases like
document.Tables(1) where VB examples would lead you to believe it should work. It is better to receive an error message like "Item is not a property" than to have some property's value unexpectedly called when it was meant to be retrieved, or similar occurrences. The kind of ambiguity permitted prior to v2.0.6 is not in keeping with the spirit of v2, or the defined meanings of each part of the syntax.
In other words, this is not a bug; you need to use the appropriate syntax for the property or method that you are invoking.