AutoHotkey Community

[Xander]

When I click the scroll bar of an edit control in an AHK GUI, the portion of the edit that was hidden behind another window is not drawn when it comes to the front.

[Chris]

I tried it with the following script but couldn't reproduce the problem:

[Xander]

Your example works for me as well (it draws correctly). I've been able to narrow it down a bit further.. the edit control must be part of a tab control to reproduce this. Adding a tab control to your code produces the drawing error:

[Chris]

Thanks for the example; I can reproduce this behavior now.

There only solutions I see for this are:
(1) Redesigning tab controls to be more traditional. This would be a lot of coding and testing and would have a high risk of breaking existing scripts.
(2) Putting tab controls lower in the z-order than the controls they contain (this is already done for tab controls that contain list-views). This has the drawback of changing the tab-key navigation order so that the tab control is after vs. before the controls it contains. This is less ergonomic, but more importantly it would break any existing script that relies on tab-key navigation order (e.g. scripts that send tab keystrokes to a GUI window).

Since option #1 should probably be implemented later as a new/improved type of tab control (keeping the old control for backward compatibility), it's probably best to go with option #2.

Comments are welcome, especially about the likelihood of breaking existing scripts. Is it worth it?

[Chris]

Since the tab control has been a part of the language for so long, backward compatibility seems important (namely the order of tab-key navigation). So I decided to keep the existing tab control and add a "tab2" control that doesn't have these redrawing issues (e.g. activating a GUI window by clicking certain parts of its controls, such as scrollbars, might redraw improperly).

Future scripts should use Tab2 instead of Tab whenever possible. For example:
Gui, Add, Tab2,, General|View|Appearance|Settings