WMI Programming with Visual Basic.NET: More About Trapping System Events
(Page 1 of 4 )
In my previous article, part six of this series, we started trapping system events through WMI. In this article we continue to discuss the same topic, but go more in depth.
You can download the zip of the entire Visual Studio.NET solution (developed for this article) here.
The first part of my series gives you the details for creating a Visual Studio.NET solution for WMI from scratch. It will not be repeated anymore in any of the future articles in this series.
Can we watch for events permanently?
In my previous article (part six), I introduced the concept of events
in WMI. I also discussed "Event Queries." Several new classes were also introduced. Finally we looked at a simple example of handling the events of WMI. Therefore, before reading this article, I strongly suggest that you read the previous article in this series. You will understand this article if and only if you have thoroughly grasped my previous article.
If you understood my previous article, you will know that the example
I discussed in that article works only for one single event. The
program automatically stops listening (or watching) for successive events (after the first notification of the event). Can we listen (or watch) continuously (permanently) for the events being generated by system? Will we be able to catch the events forever? Is the implementation much more difficult than for the single event handler?
Any one who understands the example in my previous article would certainly raise the above questions. And of course, it is also a FAQ. But the wonder is that, the implementation is very easy. The only issues are the need to have a permanent "subscriber" for the respective type of event, and the need to add an event handler on
our own.
This raises another question. When should it stop listening (or watching)? Of course, this is as important as the above questions.
If we don’t stop "watching" for the events (or, in other words, unsubscribe), some of the system resources may be blocked unnecessarily. So, our new application should "start" (subscribe) listening (or watching) and should also be able to "stop" (unsubscribe) listening.
To meet all the requirements mentioned above, I would develop another application which looks pretty similar to that of the previous article, but with some minor changes. So, let’s start with the application then.
Next: Creating a better application >>
More Visual Basic.NET Articles
More By Jagadish Chaterjee
/ 10 
