Win32 Screen Capture Caveats
A.
Under Win32 screen capture rules, if you tell the CLASS criterion to do a "contains" match instead of an "equal to" match, Dr.Explain currently does not use the STYLE criterion. Apparently the CLASS criterion "contains" match was designed as a "catch-all". If it was me, I would consider this a bug, though indeed it may be an intentional feature.
B.
VB.NET checkbox has exactly the same CLASS and STYLEs as a push-button. Thus, Win32 criteria isn't adequate to determine the difference, whereas the Accessible Objects approach does so nicely.
C.
Dr.Explain currently ships with the "Boundary colors" for Accessible Object analysis approach the same color as the Win32 analysis approach (both orange). Changing colors for the Accessible Object to a unique color (e.g. green) makes it more visible what Dr.Explain is doing when it is analyzing the "window" that is highlighted. The "Capture an object" dialog box also gives information about the area that is highlighted, and this information can be used in the Win32 Screen Capture Rules or Accessible Objects Filters in order to identify controls, though this display does not yet include the Win32 STYLE and EXTENDED STYLE values. If you encounter a control that isn't being correctly identified, use your mouse to get the "Capture an object" dialog box to highlight JUST that object, and look at the "Capture an object" dialog display and write down the criteria it is displaying. If Dr.Explain is using Win32 rules to analyze the window, you can use these critera directly in a new Win32 rule. If it is using Accessible Objects Filters to analyze the window, you can create a new Accessible Objects Filter to identify the object. Note for an Accessible Objects Filter, the "Parse accessible object as" option group determines whether Dr.Explain will produce a callout for the object:
(o) visible control, causes a callout to be created for the object.
(o) invisible control causes no callout to be generated (or if there is one, it is invisible), and
(o) subwindow causes the object to be considered a parent window containing other controls.
D.
Programming languages such as Visual FoxPro produce screens that Dr.Explain is as yet unable to decipher. Indeed, Visual FoxPro is probably an example of a worst-case scenario, because it has its own set of controls all "encased" inside a single COM object, which eludes Spy++ as well as Dr.Explain to identify visible controls. The good news here is that Dr.Explain STILL enables you to deal with this situation easily: simply capture the whole window, enter the "Screen Editor" mode for the captured picture, crop your picture to just what you want to show, and then in the "Designer" mode, click the New Control button in the tool-bar for each callout you want to create.
Voila! And it's STILL fast! This is yet another Very Well Done to the Dr.Explain team.
