That's not it, Chip. When those callbacks (and the ones from Internet
Explorer) fail, you get an "Object does not support Automation" error
from the ConnectEvent or ConnectObject call.
On 4/7/2012 6:22 PM, Chip Orange wrote:
Bruce,
I remember reading now that some of the event call-backs from Excel also
don't work with WE; that is, just as you're finding WMI isn't able to call a
WE VBScript routine, I seem to recall that some of the Excell events can't
do so either. I suspect you've hit on the same interface issue that the
Excel events are running into (if it's not just the authentication level).
I don't know, but since you have a working alternative, I'd be happy if I
were you; there was no alternative for use of the Excel events with WE.
They will probably be fixed some day, but there's always so much more which
needs attention.
Chip
-----Original Message-----
From: BT [mailto:[email protected]]
Sent: Saturday, April 07, 2012 8:00 AM
To: [email protected]
Subject: Re: ConnectEvent and ConnectObject Issue?
Hi Chip, Ron, and Steve:
This here is the script that works on windows 7 as stated
at the bottom of the email. I still have to ask, why is it
that this works as is, and it is not a semi sync but an async
call and does work in Windows7 but not inside the WE ConnectEvent?
As I stated in my reply to Chip, when taking out the on error
the call back error is no parameters, not correct amount if I
removed them but no error if I place them back in, meaning
the sub routine parms when using the WE ConnectEvent.
But, and I do mean But, there is never a call to that
subroutine in the ConnectEvent, but there is one when inside
a script outside of the WE Scripting model. No errors, just
no call to it, for I removed any error trapping and no errors happen.
This registry change does work as a .vbs file outside of WE
in Windows 7:
'Make this file inside windows 7 as RegistryChange.vbs '
then go to the registry path specified here and change a file
name and watch the msgbox come up.
' after exiting the msgbox
' then change the name back and watch the msgbox come up again.
Set wmiServices = GetObject("winmgmts:root/default")
Set wmiSink = WScript.CreateObject( _
"WbemScripting.SWbemSink", "SINK_") Dim strWMIKeyPath:
strWMIKeyPath =
"KeyPath='SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall'"
wmiServices.ExecNotificationQueryAsync wmiSink, _ "SELECT *
FROM RegistryKeyChangeEvent " _
& "WHERE Hive='HKEY_LOCAL_MACHINE' AND " _
& strWMIKeyPath
WScript.Echo "Listening for Registry Key" _
& " Change Events..."& vbCrLf
While(True)
WScript.Sleep 1000
Wend
Sub SINK_OnObjectReady(wmiObject, wmiAsyncContext)
WScript.Echo "Received Registry Change Event" _
& vbCrLf& wmiObject.GetObjectText_()
End Sub
Sent: Friday, April 06, 2012 9:43 PM
Subject: Re: ConnectEvent and ConnectObject Issue?
Hi Chip,
I thought I had read that once before and had saved so
many things, I got lost at where I had read it. I had gone
through al 3 of them and never went back to the semi sync event.
I spent tonight verifying the call back and that works. I
removed my error trap which went right on by with the resume
next, once I removed that I got back to errors to reduce down
to one thing s missing, that thing below you mention.
In other words the call back does say in the error the
number of function arguments are missing when I take them out
as a test, as it should be to insure all call back variables
are correct. So the ConnectEvent is working correctly.
I will go back through my saved blueprints and get that
one out again. I may have tried it before but when learning
and narrowing them down, I never went back to them; probably
due to XP working and never fussing as stated below.
So, will try it then we shall see if it works.
Thanks Chip for jogging my memory on this one.
Bruce
Sent: Friday, April 06, 2012 8:20 PM
Subject: RE: ConnectEvent and ConnectObject Issue?
Hi Ron,
At the site:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa3904
20(v=vs.85).as
px
MS says:
"The following script example shows asynchronous event
notification, making use of the
SWbemServices.ExecNotificationQueryAsync
method and SWbemSink object.
Note
Because the callback to the sink might not be returned at
the same authentication level as the client requires, it is
recommended that you use semisynchronous instead of
asynchronous communication."
Could this be the issue Bruce is seeing (that WE could be
expecting a different level of authentication in it's
call-backs (under Win7) than wScript host is expecting)?
Bruce,
This site has a suggestion that you change your method of
interfacing with WMI to "semi-synchronous" (explained via
linked pages from this site) to avoid this issue.
hth,
Chip
-----Original Message-----
From: Ron Parker [mailto:[email protected]]
Sent: Friday, April 06, 2012 5:09 PM
To: [email protected]
Subject: Re: ConnectEvent and ConnectObject Issue?
If an expert exists on this, I'm it, and I don't see any
way that the
"format or limitations of the connectevent" could be at fault.
If, as you say, it works on Windows XP but not on Windows
7, then that
alone points to some cause outside of Window-Eyes, don't you think?
How are you running your wscript script? That is, are you using
wscript or cscript, and are you running it from Explorer, from a
command prompt, or in some other way.
Addressing the comments in your script: ConnectEvent "knows"
that that event has two parameters. You should find that if
you don't
specify both parameters you get an error when you try to
connect the
event; do you?
On 4/6/2012 4:45 PM, BT wrote:
Hi Steve,
As I noted inside the email that the WMI does work as
long as I
am outside of the WE scripting environment. The WScript at
the bottom
works for both XP and Windows 7 but, the one inside my app
only works for XP.
So in saying that the only conclusion is the format or
limitations of the connectevent. I had mentioned as a
comment that
maybe the passed in parms are not being passed in. It would
seem that
at least one should be but I am only guessing.
I did try the connecteventwithparameters but which one
and how.
For I thought that any WMI event would automatically be
passed in, but
maybe that is the issue.
But, it works as is on an XP machine and not the
Windows 7 and
the WScript outside of the WE Object Model both work all the time.
I am at a loss and it seems to hinge on how the
connectevent is
taking and passing events here.
So I am asking the experts on this, for it would seem they
someone has come across this.
Bruce
Sent: Friday, April 06, 2012 3:47 PM
Subject: Re: ConnectEvent and ConnectObject Issue?
Bruce,
I'm not a WMI expert by any stretch, but I am thinking that
the added
security settings in Windows Vista and above may be
preventing your
script from working as it did in XP. Do you notice any
difference if
you disable the UAC?
Regards,
Steve
On 4/6/2012 3:37 PM, BT wrote:
Hi Steve,
All you scriptors below is an issue I have asked
several on.
The one that resides inside my Unintall app works on an XP
but not on a Windows 7.
In fact both work on the XP machine, only the one
inside my app
does not work on Windows 7.
The .vbs file at the bottom works on the Windows 7
and alerts
each time there is a change no matter the folder inside the
LocalMachine hive of the registry.
So the qeustion to ask is your connect object and event
routines suppose to be the substitute for the standard
script CreateObject ?
Sincerely
Bruce
The first one is inside my Uninstall app around
line 323 and
does not work in Windows 7, below that is the script and
does work in
Windows 7 when run outside of any WE app, using WScript.
In Uninstall app around line 323:
Dim strComputer: strComputer = "."
Dim strWMIKeyPath: strWMIKeyPath =
"KeyPath='SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall'"
' Universal way for all OS systems for local machine:
'Set wmiServices = GetObject("winmgmts:" _
'& "{impersonationLevel=impersonate}!\\"& strComputer&
"\root\default")
Set wmiServices = GetObject("winmgmts:root/default")
' Below is one script create but inside we apps you have
to split it
into
2
parts and is not working on windows 7, but does on XP:
Set wmiSink = CreateObject( "WbemScripting.SWbemSink")
wmiSinkConnection = ConnectEvent( wmiSink, "OnObjectReady",
"Sink_OnObjectReady")
wmiServices.ExecNotificationQueryAsync wmiSink, _ "SELECT * FROM
RegistryKeyChangeEvent " _
& "WHERE Hive='HKEY_LOCAL_MACHINE' AND " _
& strWMIKeyPath
Sub Sink_OnObjectReady( wmiObject, wmiAsyncContext) ' It
could be
failing because of the 2 parms needed.
msgBox " A registry change has happened! "
End Sub
Below is a standard script that works and reports the
registry change:
'RegistryChange.vbs
Set wmiServices = GetObject("winmgmts:root/default")
Set wmiSink = WScript.CreateObject( _
"WbemScripting.SWbemSink", "SINK_") Dim strWMIKeyPath:
strWMIKeyPath =
"KeyPath='SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall'"
wmiServices.ExecNotificationQueryAsync wmiSink, _ "SELECT * FROM
RegistryKeyChangeEvent " _
& "WHERE Hive='HKEY_LOCAL_MACHINE' AND " _
& strWMIKeyPath
WScript.Echo "Listening for Registry Key" _
& " Change Events..."& vbCrLf
While(True)
WScript.Sleep 1000
Wend
Sub SINK_OnObjectReady(wmiObject, wmiAsyncContext)
WScript.Echo "Received Registry Change Event" _
& vbCrLf& wmiObject.GetObjectText_()
End Sub
