Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

COM Object Reference [AutoHotkey v1.1+]


  • Please log in to reply
233 replies to this topic
Learning one
  • Members
  • 1483 posts
  • Last active: Jan 02 2016 02:30 PM
  • Joined: 04 Apr 2009
@sinkfaze
Clipboard := oExcel.Range("A3").Value      ; get value from cell A3, and set it to clipboard
What I actually wanted to say in that line is "to get value from cell A3 and store it in a variable - do this" and clipboard was just some sort of proof that it works.
oExcel.Range("A3").Copy
Problem is that it copies formula (not value, result) from A3 cell.

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

That's one of the reasons why you should keep both 32bit/64bit builds (even) in 64-bit Windows.

So, does that mean you would be able to use the ScriptControl Com object on a 64-bit OS as long as you're using the 32bit AHK build? I noticed that the ActiveX component wasn't even showing as registered in sbc's image.

The essential fact is that 64bit executables can use/load only 64bit dlls, 32bit executables can use/load only 32bit dlls.

When the 64bit support was added to AHK, I tempted to make AHK behave like Process Explorer, embed 64bit AHK into 32bit AHK and auto-detect the OS at the runtime then run 64bit AHK if OS is 64bit otherwise keep running the 32bit AHK. But I realized soon that the behavior is not suitable for AHK, users must have a freedom to choose which AHK build to be run (eve in 64bit OS) as in this case. Maybe we could add a switch to AHK to override the auto-detect OS feature, but this will be useless too if WOW64 is disabled. In conclusion, keeping separately 32bit/64bit AHKs is the best option.

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007
Sorry if it's a wrong place to post this. I'll upload sooner or later a standard library consisting of miscellaneous ACC/ATL/Query functions to be used with Native COM of 32/64-bit UNICODE AHK_L builds. I named it as Misc.ahk, but, I'd like to hear about member's opinions on better names.

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: Oct 13 2016 01:04 AM
  • Joined: 21 Dec 2007
thanks i been waiting on some refined atl functions and acc as well

I dont know if its ok with JW either but i certainly hopeso as this is turning into what seems to be an authoritive thread. Any chance we will get a rewritten queryinterface/service?
Never lose.
WIN or LEARN.

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

Any chance we will get a rewritten queryinterface/service?

Sure, Query meant QueryInterface/Service.

jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009

I named it as Misc.ahk, but, I'd like to hear about member's opinions on better names.

I uploaded the original version for the native COM of Misc.ahk in Zip ... [but] don't use the script yet.

Personally, I don't like Misc (though I'm not picky). Since it deals with mainly COM-related functionality, I'd say just leave it as the COM library (plus I'm rather used to typing "Com_" :wink: )

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

Personally, I don't like Misc (though I'm not picky). Since it deals with mainly COM-related functionality, I'd say just leave it as the COM library (plus I'm rather used to typing "Com_" :wink: )

This will conflict with the old COM_L, some users may still need the old COM_L. And ACC.ahk was also taken, so the viable ones are ATL.ahk or OLE.ahk, IMO. For ATL.ahk, the script deals not only ATL functions but also other functions, I thought ATL was too restrictive. For OLE.ahk, the reason was the opposite, the script doesn't touch even the tip of huge OLE subjects. Anyway, those are merely my personal opinions on the suggested names. If there is a name many members prefer, I'll use it.

BTW, please don't use the script yet. It was meant to be a concrete example for the discussion in that thread.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
If I were to download Misc.ahk, I would almost certainly rename the file, whether it is to be used directly or as a source for copy-paste. Misc.ahk is just too generic for my taste, and who knows whether I'd be able to find it again later? ;)

What about ComUtil.ahk?

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: Oct 13 2016 01:04 AM
  • Joined: 21 Dec 2007
I did download it and immediately split into acc.ahk ( i dont have or use the origional)and atl.ahk. I know it could be a huge pain in the arse :wink: but for clarity it might be better that way this does leave the 2 query functions and guid4string function alone :cry: 8)

I wonder what sort of effort to just add the query functions to the native AHK_L :idea: accessibility and atl provided by Sean are such a small subset of whats avail i doubt it would be worth the effort to incorperate directly
Never lose.
WIN or LEARN.

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

If I were to download Misc.ahk, I would almost certainly rename the file, whether it is to be used directly or as a source for copy-paste. Misc.ahk is just too generic for my taste, and who knows whether I'd be able to find it again later? ;)

I didn't like the name either. The main reason why I had chosen the name nevertheless was that I first planned to include not only COM related functions but also other short miscellaneous functions of any kind.

What about ComUtil.ahk?

I'll include the name in the poll, although I'm not sure atm if have to go to a poll in the end. BTW, it appears a little long to me, I personally preferred a name of 2~4 characters.

I did download it and immediately split into acc.ahk ( i dont have or use the origional)and atl.ahk.

That's an interesting idea (and I realize/suppose that I didn't update ACC.ahk for AHKL). BTW, one of ACC functions depends on Guid4String, I'll remove the dependency if you'd like to.

I wonder what sort of effort to just add the query functions to the native AHK_L Idea accessibility and atl provided by Sean are such a small subset of whats avail i doubt it would be worth the effort to incorperate directly

I presume the implementation itself is gonna be straightforward, and I also personally like to have them built-in, at least QueryInterface is a must-have IMO.

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: Oct 13 2016 01:04 AM
  • Joined: 21 Dec 2007

I'll remove the dependency if you'd like to.

If its going to be the only dependancy on it yes
Never lose.
WIN or LEARN.

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

If its going to be the only dependancy on it yes

OK, I updated Misc.zip. While updating, I also uploaded another experimental one combining the suggestions so far, ComUtils.zip which consists of separate Acc.ahk/Atl.ahk/Query.ahk. All three scripts are mutually independent.

What do you prefer or think?

jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009

This will conflict with the old COM_L, some users may still need the old COM_L.

My vote would still be to diminish the "old" Com Libraries & make this the main one (keeping the others available for now). However, since this will prolly be vetoed, I think the ComUtils.zip setup is good - seems more professional too.

One request might be that the Acc functions remove the word Accessible (and possibly even use Obj for Object, Win for Window, Pt for Point) since they start with "Acc_" now. A 30 character function name seems a bit long to me (Acc_AccessibleObjectFromWindow --> Acc_ObjectFromWindow --> Acc_ObjFromWin).

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

One request might be that the Acc functions remove the word Accessible (and possibly even use Obj for Object, Win for Window, Pt for Point) since they start with "Acc_" now. A 30 character function name seems a bit long to me (Acc_AccessibleObjectFromWindow --> Acc_ObjectFromWindow --> Acc_ObjFromWin).

I don't have an objection to it, however, I chose the names so as to minimize the impact when updating the existent codes, e.g., simply COM_ to Acc_. Will it be OK? BTW, my preference is Acc_ObjectFromWindow.

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: Oct 13 2016 01:04 AM
  • Joined: 21 Dec 2007
Acc_ObjectfromWindow seems better for me too but I use code hints. In general when deciding naming conventions I deter from abreviation. Not always but usually
Never lose.
WIN or LEARN.