Not sure exactly what you mean...If you tell us exactly what you want to do may be able to give more detailed advice.
By creating custom handlers for the Timer event, you are subclassing.
Timer msgs are generated at set intervals, regardless of the state (complete/incomplete) of the previous timer event.
Consider a timer of 100 ms. Processing takes 90-110 ms. It is possible to still be processing one timer when the next fires. This will tend to make the unresponsive, as all it can do is process timers. [* Note1]
The things to remember/consider are;
Single Threaded:
Make sure a second timer event (of the same type) does not fire while processing a timer event. Killing the timer prior to processing and restarting the timer after processing ensures that the timer events do not collide. It means the interval between timer msgs becomes [Timer delay + processing time].
This may be undesirable in some situations.
Multi Threaded:
If the operation is lengthy you may want to launch a new thread each timer event.
This is because your app will be unresponsive to user input while the timer msg is being processed.
[Note1]
Timer msgs are the lowest priority in the msg queue. They will be ignored if other msgs are in the queue.
Only use WM_TIMER for non time critical processing (you don't mind an approx diff of +/-100 ms in each msg).
For time critical use QueryPerformanceTimer() or similar.
"Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
Friedrich Nietzsche
"I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
George Best
"If you are going through hell....keep going."
Winston Churchill