GuiControl speed bug? Topic is solved

Report problems with documented functionality
Posts: 10
Joined: 19 Jan 2018, 03:43

GuiControl speed bug?

19 Jan 2018, 03:57


I'm not sure if this can be considered as a bug. But check this. If we do GuiControl with default speed then we have random effect/or don't work at all when we choose Test 1. (after adding Test 3 - this effect occurs on Test 1 and Test 2 etc...) .
It works, when we add Sleep between Guicontrols.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

just me
Posts: 5460
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: GuiControl speed bug?

19 Jan 2018, 04:12

For some reason it seems to work reliably here if you change the order of the GuiControl commands:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

Posts: 6131
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: GuiControl speed bug?  Topic is solved

20 Jan 2018, 19:34

The issue appears to be WM_SETREDRAW. For instance, this appears to make it work:

Code: [Select all] [Download] GeSHi © Codebox Plus

OnMessage(0xB, "WM_SETREDRAW")
if !wParam
return 0

WM_SETREDRAW is used to prevent incremental redrawing while the individual child controls are being shown or hidden. I think what happens is this:
  • When the first Tab is shown or hidden, its region of the GUI is invalidated.
  • When the second Tab is shown or hidden, it disables redraw by sending WM_SETREDRAW, FALSE.
  • WM_SETREDRAW probably has the effect of clearing out the window's update region (such as by calling ValidateRect()).
  • Only the region occupied by the second Tab is redrawn.
v1.1.27.07 fixes it by using GetUpdateRect() prior to disabling redraw and an additional call to InvalidateRect() after enabling redraw (except in cases where a child control lies partially outside the bounds of the Tab, since in that case the entire GUI is invalidated).

Return to “Bug Reports”

Who is online

Users browsing this forum: 20170201225639 and 2 guests