Safe Win32 Timer

Environment: Win32, C++

Hello guys. This article presents some Win32 timer-related stuff. It consists of two classes:

  1. CTimerHost -- that class is the source of "safe" timers. That means you can kill timer and be sure that you will not receive any timer notification from already dead timer. That timer should be used and destroyed only from the thread it was created.
  2. CTimerThunk<...> -- represents thunk for receiving timer notifications.

These classes uses dynamic thunking technology. That means total absence of any static maps or lists. Enjoy.

Example of usage:

#include "sf_timer.h"

// for example in your CApp
CTimerHost g_TimerHost;

class CMyClass
{
public:
    CMyClass() : m_Timer(g_TimerHost, this, OnTimer)
    {
        timer.SetTimer(500);
    }

    void Stop()
    {
        timer.KillTimer();
    }

    void OnTimer(DWORD dwTime) {}

protected:
    CTimerThunk<CMyClass>   m_Timer;
};

Downloads

Download source - 5.17 Kb


Comments

  • No portability...

    Posted by Legacy on 08/01/2001 12:00am

    Originally posted by: Paul

    While this method is certainly a nice trick, it is not easily portable to other operating systems or other processor architectures.  When I am dealing with one of the Windows function that requires the use of a callback, I favor using a map from the standard C++ library.  For example, if you were setting up a WndProc callback function, you could make the map reference the hWnd parameter, and the stored information the address of the class instance:
    
    


    class Window
    {
    public:

    Window( );
    virtual ~Window( );

    // Register the window class...
    void Register( )
    {
    WNDCLASSEX wc;
    wc.lpfnWndProc = Window::WndProc;
    ::RegisterClassEx( &wc );
    }

    // Create the window...
    HWND Create( )
    {
    g_window = this;
    m_hWnd = ::CreateWindowEx( ... );
    ::ShowWindow( m_hWnd, SW_SHOW );
    ::UpdateWindow( m_hWnd );
    return( m_hWnd );
    }

    // The class callback...
    LRESULT Switch( UINT uMsg, WPARAM wParam, LPARAM lParam )
    {
    switch( uMsg )
    {
    case WM_CREATE:

    return( 0 );
    break;

    case WM_DESTROY:

    return( 0 );
    break;

    default:

    return( DefWindowProc( m_hWnd, uMsg, wParam, lParam ) );
    }
    }

    private:

    HWND m_hWnd;
    std::map< Window* > m_map;

    static Window* m_window = 0;

    // The real callback
    static LRESULT CALLBACK WndProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam )
    {
    //
    if( ( uMsg == WM_CREATE ) && ( Window::m_window != 0 ) )
    {
    m_map[hWnd] = Window::m_window;
    Window::m_window = 0;
    }
    }

    return( ( m_map[hWnd] )->Switch( uMsg, wParam, lParam ) );
    };

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

Top White Papers and Webcasts

  • You probably have several goals for your patient portal of choice. Is "community" one of them? With a bevy of vendors offering portal solutions, it can be challenging for a hospital to know where to start. Fortunately, YourCareCommunity helps ease the decision-making process. Read this white paper to learn more. "3 Ways Clinicians can Leverage a Patient Portal to Craft a Healthcare Community" is a published document owned by www.medhost.com

  • With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with ease (both locally and remotely), and ultimately spend more time coding instead of waiting for the dreaded application redeploy to finish. Every time a developer tests a code change it takes minutes to build and deploy the application. JRebel keeps the app server running at all times, so testing is instantaneous and interactive.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds