Dr.Explain looks at the application your are doing screenshots for and determines one of four approaches for analyzing screenshots, based on what language the program was written in.  The guidance for this decision, as well as subsequent analysis decisions (part of which I cover in detail below) is provided by a part of Dr.Explain's configuration called a "Screen Capturing Scenario". 

 

For most users, the Screen Capturing Scenario that ships with Dr.Explain covers most of the needs you will ever have as a technical writer documenting Windows applications.

 

However, one of the less documented, but extremely powerful features of Dr.Explain is the fact that you can create your own custom Screen Capture Scenarios, and control what Dr.Explain does during screen analysis down to a very fine detail IF YOU WANT TO.

 

The four approaches for analyzing screenshots are:

 

Java (has its own unique set of screen controls)

 

HTML (for web-based applications)

 

Accessible Objects (for the last decade or so, Microsoft provides programming features that enable programmers to make it easier for people with visual, hearing, or other physical limitations, to use software -- these features also provide a robust means for Dr.Explain to analyze the screen and find and identify controls -- targets for callouts)

 

Win32 Windows (before a decade or so ago, most commercial Windows applications were written in C/C++ and used the "core" set of Windows controls, which are still present in all versions of windows today)

 

Since I have extensive experience with the Win32 Windows approach for screen analysis, I decided to "dive into" what Dr.Explain provides the end user regarding how you can control its decision-making process during screen analysis when the Win32 Windows approach is the one being used.

 

 

 

If I build an application or an application framework with its own set of custom controls with their own "class" names (e.g. HMbutton, HMtextbox, HMcheckbox, HMradiobutton, etc. all customized for this application or for the company I write software for), then I can "educate" Dr.Explain through its set of screen-capturing scenario rules so it knows how to recognize my new set of controls!

 

If I were controlling how Dr.Explain works in this area, this is exactly how I would have set it up!  Very, very well done to the Dr.Explain team!

 

 

 

For the average help author who is not and has no need to be a low-level windows application programmer, if some company creates a whole new programming language for building Windows applications (this happens every few years), and builds its own set of custom controls, then the good technicians at Dr.Explain can create a screen-capturing scenario file for this and send it to anyone who needs it, or indeed incorporate it easily into their next Dr.Explain release.

 

In summary:  the Dr.Explain team has tackled an area (screen capturing) that has a LOT of detail in it and is susceptible to change from time to time, and made it so that it is easy to adapt to those changes, thus making it easier to keep the product "up to the times" with modern Windows applications, thus reducing costs for them and their customers.  Additionally, they accomplished a remarkable result as well:  they put it within reach of the customer to do his/her own customizations (which I have!).