Kevin Gilhooly is with RIS Information Services in Dallas, working on a variety of PC-based client server projects. He can be reached at kgj@dfw.net.
Pulse is a small Windows utility that estimates the response time of a Windows 3.1 or Windows for Workgroups system.
Pulse redraws itself upon receipt of a timer message and reports the interval between redraws. In a loaded Windows system, this number will vary greatly. I have found Pulse helpful as a debugging tool, to help determine what parts of an application monopolize the system.
I originally wrote Pulse to determine how long a remote database call was taking to execute. When the connection started, the system went away for what seemed a great length of time. Pulse showed how long it actually took.
Pulse was written with Microsoft VisualC++ version 1.0. It has been compiled with later versions as well. Listing 1 shows the main window procedure. Full source code is available on this month's code disk and online sources. It is also available on my web page: http://www. dfw.net/~kjg/pulse.html.
Pulse Processing
After registering a private class, Pulse creates a window, and enters the message loop. During WM_CREATE processing, Pulse reads its initialization file, and requests to be a "topmost" window. (The Pulse window floats above all the other application windows.) It then starts a timer, requesting WM_TIMER messages to be posted once per second. You may set the interval to any value you choose. However, if the timer is set too low, the program will not be able to complete processing between timer ticks.On each timer message, Pulse invalidates its client area, generating a WM_PAINT message. When repainting, Pulse stores the current timer tick count (the GetTickCount API function returns the number of milliseconds that the Windows system has been running). It then calculates the difference between the current tick count and the count stored at the end of the previous paint processing. This difference is the current pulse count. Pulse redraws the window, and displays the current, minimum, or maximum pulse count, depending on the display setting.
WM_PAINT messages are the lowest priority messages in Windows. The messages are cumulative, so if a second message arrives before the previous one is processed, then the dirty areas (the areas to be redrawn) are added together into one new message. This is the key to Pulse. Most Windows messages will queue and the application processes each of these in turn when the machine is available. The tick count between these messages would be tiny, since the queued messages are all processed at once, before WM_PAINT. WM_PAINT messages accumulate, so multiple timer messages still result in a single paint message, hence a larger pulse count.
In a Windows system with all applications sharing properly, a WM_PAINT message will arrive once per second (or the actual timer setting, if different.) This assumes no application uses more than one full second to complete an action. Indeed, the usual current pulse display on my machine shows 1043 or 1044 (the number of milliseconds between paints, plus the time for the paint processing itself).
Pulse supports three display modes: the current pulse, the maximum pulse, and the minimum pulse. The current mode is kept in a global variable. The WM_PAINT routine switches on this variable to decide what output to display, so Pulse may be easily updated to display time of day, dates, etc. by adding another mode and another case to the switch.