AutoHotkey Community

Great examples. Can you explain a bit more what the values represent that you used?



Could you create an example which reads from an Excel file too? That would be very helpful. Thanks.

_________________
mirror 1 • mirror 2 • mirror 3 • ahk4.me • PM or

Notice that it used Invoke_(), which is supposed to be used in some rare cases where need to specify the types too.
But, "Item" should not be included in some rare cases, as it's the default member of many COM objects.
So, I'm not satisfied to use Invoke_() for "Item", but it's rather complicated to cover all possible cases without specifying the types.

Anyway, I attempted and updated CoHelper.ahk, so as to cover at least the Method/PropertyGet with the integer index parameter:




I'll do it later.

Your example with the updated CoHelper.ahk doesn't work for me (Excel 2000 v. 9.0.6926 SP-3)

_________________
mirror 1 • mirror 2 • mirror 3 • ahk4.me • PM or

What does it do, or not do? I run the same version of Excel on XPSP2 and it works fine here.

My bad...

I forgot changing "Sheet1" to "Tabelle1" (I'm working on a German system).

_________________
mirror 1 • mirror 2 • mirror 3 • ahk4.me • PM or

This is a good example of "Item" with the string parameter and the integer index parameter. Actually, I used the string parameter instead of the index parameter to avoid using Invoke_().
Now, the following can be replaced


with



BTW, what do you guys think about omitting member function name "Item" in the index parameter cases?
Was it a good or a bad decision?

Another example:

Thanks for the example.

I have no idea if leaving the function name and sheet name out is good or bad. Would it be problematic to access a sheet by name now?

I'm really not savvy at this, just experimenting a bit, but being able to read/write from Excel directly would be very useful (right now I save sheets as csv, parse them, write back to csv, and convert from csv to xls).

_________________
mirror 1 • mirror 2 • mirror 3 • ahk4.me • PM or

The only problem I have with it will be remembering to use it six months from now. It's easy to remember when something doesn't work with Invoke() to just switch to Invoke_(). That still works. It's harder to remember a new syntax just for "Item" when it's an index. A note in CoHelper would be a useful reminder for the future since unwinding the code takes a few minutes.

Say goodbye to your old ways of handling Excel data. This is so much simpler and faster. I'm currently translating some of my old Access Visual Basic macros into AHK. Gone are the headaches of moving data between the database and AHK.

The problem is that you have to specify the function name "Item" if using string parameter, but should omit if using the integer parameter.
This is unavoidable as there is no way for Invoke() to differentiate whether a string is a function name or a parameter.
It's also based on the assumption that there is no function name purely consist of digits, and we're never gonna use the dispID directly.
I'll continue in the following reply.

Count, Item, _NewEnum are special member names. So, "Item" is omitted frequently like:
Worksheets("Sheet1"), Worksheets(1), Cells(1,2), etc.
However, looks like it was a bad decision to omit the name "Item" only for the integer index parameters. I'll restore it to specify the name "Item" even with the integer index.
However, there still remains discrepancy between the string & the integer index parameters: can simply use Invoke() with the string, but should use Invoke_() with the integer parameter.
And, I'd really like to avoid using Invoke_() with the "Item" function as it's one of the special members in COM.

I suppose a way with the least risk would be that if a parameter is recognized as an integer don't do type coercion into bstring but do specify it as one of the integer types. It would also reduce substantially further the need of Invoke_().
One problem with it, however, is what integer type should be used.
integer (:VT_I4) or (U)int64 (:VT_I8 or VT_UI8) or etc.
VT_I4 may be the safest bet, whereas VT_UI8 may be the most generic.

Although the types didn't really matter in my quick tests, I can't be sure of it atm.

Whatever is most common in the Office apps is probably the way to go. Folks poking around in the Windows API will probably be more comfortable with specifying types when necessary.



This may be some sort of type issue? I'm translating a bit of code from VB to AHK, and can't seem to get the "Write" method on a stream object to work when the source is a binary database field. The stream object stays empty no matter what VT_ type is specified for the data value (see the highlighted line of code). Thanks for any hints.

Here's the VB code I'm translatingAnd the AHK version

I updated the Invoke() with VT_I4, however, am currently using VT_UI8 myself as an experiment, as would not specify correctly data values of integer type greater than 2**32 with VT_I4.


Why did you use 12 as the type? 12 is VT_VARIANT, so, I suppose it was wrong here unless the data field is encapsulated in a variant.

Need to do some debug: go to the near the end of Invoke(), add MsgBox, % NumGet(varResult,0,"Ushort") before and after If nFlags & 3 syntax. The reason of adding two is to check also whether a type coercion is happening or not.

I agree that in most cases it will probably be more helpful if it is assumed to be an integer than to be a string.


According to the VARIANT specification, VT_I8 and VT_UI8 should not appear in a VARIANT.
http://msdn2.microsoft.com/en-us/library/ms221170.aspx
http://www.marin.clara.net/COM/variant_ ... itions.htm

I had one example of a property returning a value that wouldn't fit in I4:

The FreeSpace property was returning a VT_R8 on my computer that had dozens of GB of free space.

_________________
-m35

I tried them all. VT_VARIANT was the last one left in there before I posted.

Before/After the "If nFlags". Same result for every VT_ type I tried.

Thanks for the help.