Implementing the 'Java Listener Method' in MFC



Click here for a larger image.

Environment: VC6, Windows 98 and later.

Introduction

This article was written to illustrate how to implement the 'java type' listener method in MFC. This small article demonstrates how you can take advantage of this method and how you can use it in your code. This is my first project, so if there is anything wrong with it or if there is anything better that can be implemented, please do mail me at el_josephrthomas@yahoo.com.sg. In general, this code can also be roughly seen as the implementation of the 'Observer Pattern'.

You can get more information on the observer pattern from the Houston's page and Wiki's page.

There is currently an article present on the Code Project site that implements the 'Observer Pattern' to illustrate a treadmill, but I have written this article purely to illustrate the 'java Listener method' and nothing else.

While writing this article, I came to know the mechanics of how the 'Java Listeners' work. Actually, I needed to implement the Java 'Listening' method in my MFC project. I asked my teacher and he said that because MFC does not provide a 'Listener' like Java, I'll have to make my own. So, this project is what I've come up with.

Coding

When you need to make a class an observer to the event source, you need to inherit your class from CJrtEventListener and implement the EventHandler method.

EventHandler is the method where you want the particular action to be performed. For example: In the project, I have four 'Listeners'; each 'Listener' wants to perform a different action when the source changes. So, all the 'Listeners' have different EventHandler functions.

The 'Source' to which the 'Listeners' are supposed to listen to is the edit box with a 'Change Event Source' button next to it.

The buttons on the control panel (at the top) control the 'Listeners'. When the control panel button in switched on, the respective 'Listeners' start to listen for the source; when it's switched off, the respective 'Listeners' stops listening to the source. These buttons also show the state of the respective 'Listener'.

CJrtEvent is the event class that is passed to the 'Listeners' so that they know that this is the event occurred, and update themselves.

CJrtEventSource is the source, which means that this is what your 'Listeners' will be listening for.

The 'Event class' and the 'Listener class' are kept decoupled, so neither has to know about each other's existence.

Acknowledgement

Thanks to my teacher, Dr. Zhang Binglu, for guiding and helping me.

About the Author

I am a student and am going to graduate in February of 2004.

Downloads

Download demo project - 117 Kb
Download source - 17 Kb


Comments

  • Observer? No requirement for listener!

    Posted by Legacy on 10/18/2003 12:00am

    Originally posted by: Armin

    I can't get information why you use the observer pattern. When you talk about the Java event handling, implement it in the same way. It's very easy to do it

    Define the listener interface. It should be a abstract class with pure virtual methods in C++.

    Implement the event class with the information you want.

    Write code for the event source. Implement the methods addXXXEventListener and fireXXXevent.

    Derive every class who should listen at the event from the listener class and implement the required methods.

    When the event happens call fireXXXEvent and call the methods from every added listener.

    That's all.

    Bye

    Reply
  • Hmm?

    Posted by Legacy on 10/17/2003 12:00am

    Originally posted by: Penny

    You "am going to graduate"?

    Good luck.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • When individual departments procure cloud service for their own use, they usually don't consider the hazardous organization-wide implications. Read this paper to learn best practices for setting up an internal, IT-based cloud brokerage function that service the entire organization. Find out how this approach enables you to retain top-down visibility and control of network security and manage the impact of cloud traffic on your WAN.

  • Following an IT incident through to resolution is more than just acknowledging an alert and restarting a server. The recent State of On-Call Report found that it takes most companies an average of 10-30 minutes to resolve an incident with an average of 5 people involved. Imagine how much money and time companies are spending to deal with incident resolution. But what if you had a tool that offered solutions baked in? Or a tool that sent alerts to the right person or team every time? These are the kind of …

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date