Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Edit control not redrawing upon gaining focus.


  • Please log in to reply
4 replies to this topic
Xander
  • Members
  • 140 posts
  • Last active: Nov 13 2007 08:31 PM
  • Joined: 23 Sep 2007
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
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
I tried it with the following script but couldn't reproduce the problem:
gui, add, edit, w100 r10, 1`n2`n3`n4`n5`n6`n7`n8`n9`n10`n

gui show

return



GuiClose:

ExitApp
I put a calculator in front of the GUI and then clicked the scroll bar, but it seemed to redraw okay. Maybe it only affects certain desktop themes.

Xander
  • Members
  • 140 posts
  • Last active: Nov 13 2007 08:31 PM
  • Joined: 23 Sep 2007
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:
gui, add, tab, , Tab
gui, add, edit, w100 r10, 1`n2`n3`n4`n5`n6`n7`n8`n9`n10`n 
gui show 
return 

GuiClose: 
ExitApp

I don't think this is a high priority bug if there isn't a simple fix..

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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