8. Debugging and Optimization with WinID

1. Check Visual layout of your application. Very often we create software programs that employ a big number of user-drawn complex overlapping controls, but have you ever thought about "visual correctness" of how we position those controls and how well we program the GUI part of the user interface? You'd be surprised how many times this is not true. Very often controls overlap each other, become much bigger in size, sometimes redrawing functions do not respond right to certain situations rendering those windows looking ugly and confusing for the user. You can simply test it with WinID by running it in Highlight Selected Control Mode over your controls to see how well they redraw themselves. If you see that some of them flicker "unnaturally", lose parts of its visual theme or disappear from the screen, then you should address the GUI (Graphics User Interface) part of your application. By doing this test with WinID you prevent embarrassing moments of issuing updates for your software after user complaints.
    
2. Check resource leaks in your application. While there is a host of costly programs (like Compuware's BoundsChecker) allowing you to trap and debug resource and memory leaks in your application, WinID gives you less expensive way to monitor your program's "unwanted leaks". WinID interacts directly with the Operating System and provides handles count values in the Process Info section of the Readout Pane that can tell if you have a resource or memory leak in your program the way Operating System sees it.
    
   INFORMATION: The handles count values are available on Windows NT family Operating Systems only. If you develop your application using Windows 95/98/Me we suggest that you transfer your project to either Window NT/2000/XP or later OS to test it there with WinID.
    
   To test your application regarding resource and memory leaks using WinID do the following:
   • Start WinID and put it into Topmost and Constant Polling Modes;
   • Run your test application (make sure WinID's Readout Pane is also visible). With mouse pointer over your program's window watch the following parameters in the WinID's Readout: HANDLEs, GDI, USER in the Process Info section. Although these parameters may change when you load, open and close controls in your application, none of them should increment with time. If you see that either of these parameters grows steadily when your application is relatively inactive this means that you have a resource leak in it;
   • You can also check memory allocation and memory leaks in general by monitoring WrkSet, PKs, and Usage parameter groups in the Process Extra section in the Readout Pane. These parameters represent memory usage in your application. Although they may change when your application loads, opens and closes controls and performs additional tasks, none of these parameters should increment with time. If you observe that either of these parameters grows steadily when your application is relatively inactive this means that you have a memory allocation problem or memory leak. (INFORMATION: Please note that the abovementioned rule should not be attributed to the values in I/O parameter group, since those parameters can increment gradually to show interaction with I/O devices.)
      
   To have an example of a normally operating process simply run the same test with WinID using any of the system controls, or WinID's window itself.
    
3. Determine what type of program is up on the screen. Very often we may get a pop-up window, or an error message on the screen that leaves us guessing where this window came from. This might be especially important if you suspect virus infection of your system. WinID can easily determine the file path on the hard drive where that pop-up window came from. It won't prevent this window from popping up again but at least it'll give you a clue to supply for your antivirus software.
    
   To determine the path where the program is located check Img: field in the Paths & Priorities section. You can also Capture Shot of the window of interest and retrieve the full file path to it, or open the folder that contains that file in the Files Tab window of the Captured Shots dialog.
    
4. Determine how a program was started. Sometimes you may need to know how a certain process was initiated. You can use WinID for that. Simply Capture Shot of the window of interest and examine the Params Tab of the Captured Shots dialog. The full command line including start-up parameters for the program will be displayed in the Command Line section.
    
5. Check the installation time of a program. To learn when a certain program, component, or control was installed on your system find a window that belongs to it and Capture Shot of it. Then you can examine the Files Tab window of the Captured Shots dialog. Check both Image File and Module File sections. "Created" fields will contain the data of interest. (INFORMATION: Please note that this information is Operating System specific. The accuracy and presence of this information depends directly on the Operating System that you run WinID on.)
    
6. Determine which modules are loaded for the process. There is a good little tool called "Dependency Walker" supplied by Microsoft. It displays all modules that are required for a process to run. But this is a "static" information (simply taken from the PE Header of the image file of the program). The process as well as modules that it loaded can too load modules of their own. WinID will let you retrieve "dynamic" information about modules. This way you may see which modules were loaded into the process at the time you want. To do so, find any window belonging to your program and Capture Shot of it with WinID. Later go to the Modules Tab in the Captured Shots window and examine the module list in it.
    
7. Check parameters of the visual elements in your program. How often do we create ImageLists, or load bitmaps and icons into our programs and then wonder what color depth are they displayed on the screen, whether alpha channel is used, or not, or simply why they look "so bad". By extracting dynamic resources from your program with WinID you can examine all the aspects of your visual elements and see your own "static" resources after they were loaded into your program. Fore more information check description of the Control Tab in the Captured Shots window.

The list of examples above is far from being complete, this is just the most important uses of WinID. In case you want to add any of your ideas on how else to use WinID, or suggest a new option for the future version of WinID we welcome your ideas through the user feedback.