Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > microsoft.public.scripting.vbscript > #11348 > unrolled thread

Is it possible to create a custom global WMI event?

Back to article view | Back to microsoft.public.scripting.vbscript

Contents

  Is it possible to create a custom global WMI event? JJ <jj4public@vfemail.net> - 2016-08-08 20:22 +0700
    Re: Is it possible to create a custom global WMI event? "R.Wieser" <address@not.available> - 2016-08-08 18:39 +0200
      Re: Is it possible to create a custom global WMI event? JJ <jj4public@vfemail.net> - 2016-08-10 03:02 +0700
        Re: Is it possible to create a custom global WMI event? "R.Wieser" <address@not.available> - 2016-08-10 09:54 +0200
          Re: Is it possible to create a custom global WMI event? JJ <jj4public@vfemail.net> - 2016-08-11 01:30 +0700
            Re: Is it possible to create a custom global WMI event? "R.Wieser" <address@not.available> - 2016-08-10 23:06 +0200
              Re: Is it possible to create a custom global WMI event? JJ <jj4public@vfemail.net> - 2016-08-11 19:27 +0700
                Re: Is it possible to create a custom global WMI event? "Mayayana" <mayayana@invalid.nospam> - 2016-08-11 09:18 -0400
                Re: Is it possible to create a custom global WMI event? "R.Wieser" <address@not.available> - 2016-08-11 15:57 +0200

#11348 — Is it possible to create a custom global WMI event?

I want to create a WMI event that can be used for anything and not just the
XXXAsync() methods of the SWbemServices object. For example, for signalling
the completion of non WMI related tasks where other VBScript code in other
W/CSCRIPT.EXE processes can wait for the event. Something like SWbemSink but
works across different process.

Is this possible?

Currently, I'm using the presence of a file as the event but I'm hoping to
use something that doesn't write to disk.

[toc] | [next] | [standalone]

#11349

JJ,
> I want to create a WMI event
...
> Is this possible?

Looks to be:

https://technet.microsoft.com/en-us/library/hh849954.aspx

> Currently, I'm using the presence of a file as the event but
> I'm hoping to use something that doesn't write to disk.

Well, in that case a WMI event looks to be the proverbial cannon to shoot a
fly. :-)

My suggestion would be use the much simpler Event object

https://msdn.microsoft.com/nl-nl/library/windows/desktop/ms682396(v=vs.85).a
spx ).   If you want a "sender side only" solution, you could use a named
pipe -- which can be, IIRC, opened at the receiving side as a simple,
blocking "file".

regards,
Rudy Wieser


-- Origional message:
JJ <jj4public@vfemail.net> schreef in berichtnieuws
mzqhduvsrtpr.j1wiyht3gnv0.dlg@40tude.net...
> I want to create a WMI event that can be used for anything and not just
the
> XXXAsync() methods of the SWbemServices object. For example, for
signalling
> the completion of non WMI related tasks where other VBScript code in other
> W/CSCRIPT.EXE processes can wait for the event. Something like SWbemSink
but
> works across different process.
>
> Is this possible?
>
> Currently, I'm using the presence of a file as the event but I'm hoping to
> use something that doesn't write to disk.

[toc] | [prev] | [next] | [standalone]

#11350

On Mon, 8 Aug 2016 18:39:44 +0200, R.Wieser wrote:
> 
> Looks to be:
> 
> https://technet.microsoft.com/en-us/library/hh849954.aspx
> 
>> Currently, I'm using the presence of a file as the event but
>> I'm hoping to use something that doesn't write to disk.
> 
> Well, in that case a WMI event looks to be the proverbial cannon to shoot a
> fly. :-)
> 
> My suggestion would be use the much simpler Event object
> 
> https://msdn.microsoft.com/nl-nl/library/windows/desktop/ms682396(v=vs.85).a
> spx ).   If you want a "sender side only" solution, you could use a named
> pipe -- which can be, IIRC, opened at the receiving side as a simple,
> blocking "file".

For me, PowerShell is no different due to .NET.

I'm trying to use only resources that are available in every Windows
installations (with minimum version requirement), so that the script would
be guaranteed to work on those systems.

But you have a good idea, though. A tiny custom program that provides event
capability for both VBScripts and batch files would be very useful indeed.

[toc] | [prev] | [next] | [standalone]

#11351

JJ,

> For me, PowerShell is no different due to .NET.

It wasn't my intention to refer to either.

> I'm trying to use only resources that are available in every
> Windows installations (with minimum version requirement)

Same here.

> But you have a good idea, though. A tiny custom program
> that provides event capability for both VBScripts and batch
> files would be very useful indeed.

As you posted in VBScript my thought was you could create an COM/OCX
component.    But yes, making it a stand-alone program would make it broader
in its application.

On the other hand, it could cause a same kind of problem as using a lock
file: if the parent program dies before closing the external program holding
the signal you are left with a (session bound) permanent lock that will
disallow further usage of the parent program -- though a reboot (or logging
out and in again) will solve that, which is better than when using a lock
file.

... though the parent program could, on startup, possibly clean up any
outstanding lock file, mitigating that problem.

In other words, I myself would most likely go for a method more tightly
bound to the script itself, and (thus) terminating when the script ends --
regardless of if that happens by cleanly ending, or by throwing an error.

Regards,
Rudy Wieser


-- Origional message:
JJ <jj4public@vfemail.net> schreef in berichtnieuws
1lua92u37ohvl$.1894nbdxwqzgo.dlg@40tude.net...
> On Mon, 8 Aug 2016 18:39:44 +0200, R.Wieser wrote:
> >
> > Looks to be:
> >
> > https://technet.microsoft.com/en-us/library/hh849954.aspx
> >
> >> Currently, I'm using the presence of a file as the event but
> >> I'm hoping to use something that doesn't write to disk.
> >
> > Well, in that case a WMI event looks to be the proverbial cannon to
shoot a
> > fly. :-)
> >
> > My suggestion would be use the much simpler Event object
> >
> >
https://msdn.microsoft.com/nl-nl/library/windows/desktop/ms682396(v=vs.85).a
> > spx ).   If you want a "sender side only" solution, you could use a
named
> > pipe -- which can be, IIRC, opened at the receiving side as a simple,
> > blocking "file".
>
> For me, PowerShell is no different due to .NET.
>
> I'm trying to use only resources that are available in every Windows
> installations (with minimum version requirement), so that the script would
> be guaranteed to work on those systems.
>
> But you have a good idea, though. A tiny custom program that provides
event
> capability for both VBScripts and batch files would be very useful indeed.

[toc] | [prev] | [next] | [standalone]

#11352

On Wed, 10 Aug 2016 09:54:12 +0200, R.Wieser wrote:
> 
> On the other hand, it could cause a same kind of problem as using a lock
> file: if the parent program dies before closing the external program holding
> the signal you are left with a (session bound) permanent lock that will
> disallow further usage of the parent program -- though a reboot (or logging
> out and in again) will solve that, which is better than when using a lock
> file.

Yes, that's one of the problems when using a file based event. Which is why
I'm wondering if it's possible to use the real event from WMI.

> In other words, I myself would most likely go for a method more tightly
> bound to the script itself, and (thus) terminating when the script ends --
> regardless of if that happens by cleanly ending, or by throwing an error.

Do you have any idea?

I've also considered using TASKLIST.EXE, but it doesn't provide any field
that can be used as a binder to the script.

[toc] | [prev] | [next] | [standalone]

#11353

JJ,

> Yes, that's one of the problems when using a file based event. Which
> is why I'm wondering if it's possible to use the real event from WMI.
...
> Do you have any idea?

Well, that is what I tried to explain in my previous post: when a VB
script -- and the engine that runs it -- terminates *for whatever reason*
(other than hard power-down ofcourse) it will also releases all its loaded
COM/OCX objects.   And because of that you can, when your own object is
released, tell it to terminate the signalling it has set up.   And thats not
something you can do when using a stand-alone program or a file.

In other words: such a COM/OCX object is pretty-much the tightest binding
you have with your script.   Combine it with the earlier mentioned Event
object or a named pipe and you're good to go.

Hmmm .... Another method just popped into my mind: you could also take a
peek at broadcasting a system-wide message:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644932(v=vs.85).a
spx This one can be put in a stand-alone program.  Downside: The receiving
end needs to have a (hidden) window to be able to receive it.

Shucks, I just realized: if you have the "winsock" object already installed
you could use that to create a port on localhost which the second app than
can listen to.

Hope that helps,

Regards,
Rudy Wieser


-- Origional message:
JJ <jj4public@vfemail.net> schreef in berichtnieuws
4gr3m8ycwo5t.84esgior4f1v$.dlg@40tude.net...
> On Wed, 10 Aug 2016 09:54:12 +0200, R.Wieser wrote:
> >
> > On the other hand, it could cause a same kind of problem as using a lock
> > file: if the parent program dies before closing the external program
holding
> > the signal you are left with a (session bound) permanent lock that will
> > disallow further usage of the parent program -- though a reboot (or
logging
> > out and in again) will solve that, which is better than when using a
lock
> > file.
>
> Yes, that's one of the problems when using a file based event. Which is
why
> I'm wondering if it's possible to use the real event from WMI.
>
> > In other words, I myself would most likely go for a method more tightly
> > bound to the script itself, and (thus) terminating when the script
ends --
> > regardless of if that happens by cleanly ending, or by throwing an
error.
>
> Do you have any idea?
>
> I've also considered using TASKLIST.EXE, but it doesn't provide any field
> that can be used as a binder to the script.

[toc] | [prev] | [next] | [standalone]

#11354

On Wed, 10 Aug 2016 23:06:45 +0200, R.Wieser wrote:
> 
> Well, that is what I tried to explain in my previous post: when a VB
> script -- and the engine that runs it -- terminates *for whatever reason*
> (other than hard power-down ofcourse) it will also releases all its loaded
> COM/OCX objects.   And because of that you can, when your own object is
> released, tell it to terminate the signalling it has set up.   And thats not
> something you can do when using a stand-alone program or a file.
> 
> In other words: such a COM/OCX object is pretty-much the tightest binding
> you have with your script.   Combine it with the earlier mentioned Event
> object or a named pipe and you're good to go.
> 
> Hmmm .... Another method just popped into my mind: you could also take a
> peek at broadcasting a system-wide message:
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms644932(v=vs.85).a
> spx This one can be put in a stand-alone program.  Downside: The receiving
> end needs to have a (hidden) window to be able to receive it.
> 
> Shucks, I just realized: if you have the "winsock" object already installed
> you could use that to create a port on localhost which the second app than
> can listen to.
> 
> Hope that helps,

I am so sorry that I've made a mistake. I've misunderstood you earlier and
have made you made time to write long replies.

I also forgot to mention that I need my scripts to work on all Windows
installations (at least Windows XP; i.e. WinXP and newer; with/without
service packs). So, I need to use only the resources that are already
available in the system. Using third party or custom programs is one of my
considerations, but it's currently as a last resort only - since file based
event is still enough to do the job albeit dirty.

[toc] | [prev] | [next] | [standalone]

#11355

"JJ" wrote:

| I also forgot to mention that I need my scripts to work on all Windows
| installations (at least Windows XP; i.e. WinXP and newer; with/without
| service packs).

  It's an interesting issue. You never explained what you're
trying to do, so it's hard to think about solutions. I've used
IE windows before, tracking changes in things like status text.
But then IE changes with every version, so that can be tricky.

  I've also used Ax EXEs, but of course that doesn't fit your
requirement of no extras. Even if it did, VBScript getting events
is awkward. WScript.CreateObject allows for specifying an
object for event subs, but the script still has to loop in paralysis
while it waits for that event. So I've only used that method
where I absolutely have to, such as with an emailing component
where I need to wait for the server's final "goodbye" before
ending. So it's hard to see any advantage to WMI. You'd still
be stuck with a looping script, even if you can get an event
using WScript.CreateObject. And while WMI is well supported,
it's not guaranteed. I would have the service disabled if I
didn't use it myself. It's not of much use to the average person,
except as the basis of hardware reporting utilities.

  For something shared across scripts it's hard to imagine
anything better than a file used as flag. But I'd be interested
if you find something better. :) 

[toc] | [prev] | [next] | [standalone]

#11356

JJ,

> I am so sorry that I've made a mistake. I've misunderstood
> you earlier and have made you made time to write long replies.

No problem, that sometimes happens.   And I'm not free from blame either, as
I, even though you already mentioned it should work on every windows
installation, thought you where able to add your own executable to it (the
program that, I thought, would than recieve the by you mentioned WMI event)

In that case I think you're pretty-much out of luck with VBScript though
(other than the basic "using a file" signalling)...

Regards,
Rudy Wieser


-- Origional message:
JJ <jj4public@vfemail.net> schreef in berichtnieuws
1f0cf93tk73wd$.f9l8tqj5wvue.dlg@40tude.net...
> On Wed, 10 Aug 2016 23:06:45 +0200, R.Wieser wrote:
> >
> > Well, that is what I tried to explain in my previous post: when a VB
> > script -- and the engine that runs it -- terminates *for whatever
reason*
> > (other than hard power-down ofcourse) it will also releases all its
loaded
> > COM/OCX objects.   And because of that you can, when your own object is
> > released, tell it to terminate the signalling it has set up.   And thats
not
> > something you can do when using a stand-alone program or a file.
> >
> > In other words: such a COM/OCX object is pretty-much the tightest
binding
> > you have with your script.   Combine it with the earlier mentioned Event
> > object or a named pipe and you're good to go.
> >
> > Hmmm .... Another method just popped into my mind: you could also take a
> > peek at broadcasting a system-wide message:
> >
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644932(v=vs.85).a
> > spx This one can be put in a stand-alone program.  Downside: The
receiving
> > end needs to have a (hidden) window to be able to receive it.
> >
> > Shucks, I just realized: if you have the "winsock" object already
installed
> > you could use that to create a port on localhost which the second app
than
> > can listen to.
> >
> > Hope that helps,
>
> I am so sorry that I've made a mistake. I've misunderstood you earlier and
> have made you made time to write long replies.
>
> I also forgot to mention that I need my scripts to work on all Windows
> installations (at least Windows XP; i.e. WinXP and newer; with/without
> service packs). So, I need to use only the resources that are already
> available in the system. Using third party or custom programs is one of my
> considerations, but it's currently as a last resort only - since file
based
> event is still enough to do the job albeit dirty.

[toc] | [prev] | [standalone]

Back to top | Article view | microsoft.public.scripting.vbscript

csiph-web