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
Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

I get the following error with the AHK_L Unicode 64bit build on Win7. The error does not occur with the Unicode 32bit build.

Afaik there is no 64-bit version of the ScriptControl (msscript.ocx).

sbc
  • Members
  • 321 posts
  • Last active: Jun 07 2011 10:24 AM
  • Joined: 25 Aug 2009

when I think documentation link, I think of a list of properties/methods & corresponding documentation (such as this)

Fixed that. :)

It may be worth noting that much of what can be done with WScript.Shell can be done natively with AHK.

I'm not sure what you mean. :?

Afaik there is no 64-bit version of the ScriptControl (msscript.ocx).

So it means not every build of AHKL supports all COM objects. Many of the users are not aware of it.

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

So it means not every build of AHKL supports all COM objects. Many of the users are not aware of it.

Rather i think it means that not all COM objects have a 64 bit counterpart
Never lose.
WIN or LEARN.

sbc
  • Members
  • 321 posts
  • Last active: Jun 07 2011 10:24 AM
  • Joined: 25 Aug 2009

Rather i think it means that not all COM objects have a 64 bit counterpart

As a result, some COM objects won't work with the 64bit build of AHKL. Then the 64-bit incompatible objects should be listed somewhere in this thread or the manual.

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

It may be worth noting that much of what can be done with WScript.Shell can be done natively with AHK.

I'm not sure what you mean. :?

I was just pointing out AHK natively has many of the features provided by WScript.Shell - which you documented in your post:
Msgbox % "Desktop:`n`t" . objShell.SpecialFolders("Desktop") ; MsgBox, %A_Desktop%

objExec := objShell.Exec("notepad.exe")         ;Run, notepad,,, PID 
While !objShell.AppActivate(objExec.ProcessID)   ;WinWaitActive, ahk_pid %PID% 
   sleep 100 
objShell.SendKeys("Hello World!{Enter}") ;Send, Hell World{Enter} 
iBtn := objShell.Popup("Do you cancel?", 5, "Continue?", 33)   ;Msgbox,33, Continue?, Do you cancel?, 5

Then the 64-bit incompatible objects should be listed somewhere in this thread

It should be listed in the post for the object - in System Requirements. I will update the ScriptControl object.

sbc
  • Members
  • 321 posts
  • Last active: Jun 07 2011 10:24 AM
  • Joined: 25 Aug 2009

I was just pointing out AHK natively has many of the features provided by WScript.Shell - which you documented in your post:

Oops, I've misread it as "worth nothing." :lol:

I cannot test since I'm running XP, but you could try CLSID Registry Scanner [COM/ActiveX], which would show you the registered Classes. I would be interested to see what you find.

Let me know if you need the exported csv file.
Posted Image

jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009
OK - so try it out with the following:
oSC := ComObjCreate("MSScriptControl.ScriptControl")
I know this works on XP, so if it works on 64-bit OS, I'll just modify the ScriptControl post.

Also, I noticed the image shows that it's not registered. You may just need to register the ActiveX Component.

sbc
  • Members
  • 321 posts
  • Last active: Jun 07 2011 10:24 AM
  • Joined: 25 Aug 2009
Nope, I get this:

Error: 0x80040154 - Class not registered
Line#
---> 003: oSC := ComObjCreate("MSScriptControl.ScriptControl")

Also, I noticed the image shows that it's not registered. You may just need to register the ActiveX Component.

Oh, how can I do it?

jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009
Well, you would need to register the DLL/OCX. However, since there is no DLL (InProcServer), I suppose you've just confirmed:

Afaik there is no 64-bit version of the ScriptControl (msscript.ocx).



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

As a result, some COM objects won't work with the 64bit build of AHKL. Then the 64-bit incompatible objects should be listed somewhere in this thread or the manual.

That's one of the reasons why you should keep both 32bit/64bit builds (even) in 64-bit Windows. IMO, the listing is not necessary as the error message will tell you about the non-existence.

sbc
  • Members
  • 321 posts
  • Last active: Jun 07 2011 10:24 AM
  • Joined: 25 Aug 2009
[*:2yr1h3rd]COM Object: WScript.Shell[*:2yr1h3rd]Purpose: Exchange variables between scripts[*:2yr1h3rd]System Requirements: General[*:2yr1h3rd]Documentation Link: WshEnvironment Object[*:2yr1h3rd]Other Links: Environment Variables[*:2yr1h3rd]Basic Code Example - demonstrates how to set a volatile environment variable and read it from another script:Save this code as Sender.ahk
objShell := [color=#107095]ComObjCreate[/color]([color=#666666]"WScript.Shell"[/color])
objEnv := objShell.Environment([color=#666666]"Volatile"[/color])
[color=#107095]loop[/color] {
	[color=#107095]random[/color], env, 0, 100
	;Here the variable is named "Test". Change the name as you need. 
	;But the other script to read the value needs the corresponding variable name.
	;This variable and its value will be lost after logout/restart/shutdown of your computer.
	objEnv.Item([color=#666666]"Test"[/color]) := env			
	[color=#107095]sleep[/color] 100
}
[color=#107095]Return[/color]
Save this code as Receiver.ahk
objShell := [color=#107095]ComObjCreate[/color]([color=#666666]"WScript.Shell"[/color])
objEnv := objShell.Environment([color=#666666]"Volatile"[/color])
[color=#107095]loop[/color] {
	[color=#107095]tooltip[/color] % objEnv.Item([color=#666666]"Test"[/color])	
	[color=#107095]sleep[/color] 100
}

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

Maybe HotkeyIt's dll can be used to bypass it?

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

Maybe HotkeyIt's dll can be used to bypass it?

No, because of the exactly the same reason why you could use 32-bit msscript.ocx with 32-bit AHKL but could not with 64-bit AHKL (and vice versa).

sinkfaze
  • Moderators
  • 6367 posts
  • Last active:
  • Joined: 18 Mar 2008

Clipboard := oExcel.Range("A3").Value		; get value from cell A3, and set it to clipboard


That's a bit of extra work, this is all you need:

oExcel.Range("A3").[color=red]Copy[/color]

And if you're pasting to another place in a workbook you can push the copy directly to the destination rather than saving to the Clipboard:

oExcel.Range("A3").Copy[[color=red]oExcel.Range("B12")[/color]]


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

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.

sbc
  • Members
  • 321 posts
  • Last active: Jun 07 2011 10:24 AM
  • Joined: 25 Aug 2009

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 don't have any problems using the ScriptControl object with the AHKL 32bit build on 64bit Win7. :roll:

Edit:
I mean it runs fine with the 32bit build. But I do have a problem switching over two different builds repeatedly.