Hi Steve,
>1) How do the manager classes subscribe to the timer service?
>

Currently there is a fixed number of manager classes (forms, menu, user, etc.) so there is no registration going on. The application timer object knows who it needs to bradcast the message to and it does. The method can be subclassed for quick and dirty additions but I haven't had to do that in awhile.

However, you have made me think about some modifications that I may do in the near future. I could implement a registration process so that any new manager classes I come up with (e.g. RDBMS connection manager) could simply call a registration method with two parameters: object reference of manager class and method to initiate when timer fires. This would get added to a collection/array whose members would get notified. This would make the system highly flexible and it would alleviate some of the needs to subclass this method.

>2) Is there a common method in each manager class responsible for receiving the messages? Since we don't have multiple inheritence, is this some cut and paste code?

Again, currently there is a finite number and I know the method name that needs to be called. Luckily it is named the same because my manager classes inherit from the same parent with a method just for this (AppTimerFired).

Thanks Steve for making me go beyond my current boundaries. :-)