Modify

Opened 10 years ago

Closed 10 years ago

#975 closed Bug (Fixed)

GUICtrlCreateCheckbox() on tabs.

Reported by: GEOSoft Owned by: Valik
Milestone: 3.3.1.6 Component: AutoIt
Version: 3.3.1.0 Severity: Blocking
Keywords: Checkbox, Tab, color Cc:

Description

The code is pretty self explanatory. Black areas (desktop color) where the checkbox text should be. If You comment out the Tab items then it changes to gray and if you further comment out the tab itself everything is fine.


$Frm_Main = GUICreate("Test Form", 400, 300)
$Tab = GUICtrlCreateTab( 0, 0, 400, 300)
$hTab_1 = GUICtrlCreateTabItem("Tab 1")
$hCheck = GUICtrlCreateCheckBox("Demonstartion", 10, 30, 150, 20)
GUICtrlCreateTabItem("")
GUISetState()
While 1
   $Msg = GUIGetMsg()
   Switch $Msg
      Case -3
         Exit
   EndSwitch
WEnd

Also if you comment out the tab items (leave the tab in) and set the GUI background color to 0xFFFFFF then it doesn't show the grey area.

Attachments (0)

Change History (11)

comment:1 follow-up: Changed 10 years ago by jchd

There's a very similar problem with radio buttons inside tabs, but then their text area show up as grey, not black like checkboxes. Both glitches are easily overcome by explicitely setting items' background color once, e.g. right after creation.

comment:2 in reply to: ↑ 1 Changed 10 years ago by GEOSoft

Replying to jchd:

There's a very similar problem with radio buttons inside tabs, but then their text area show up as grey, not black like checkboxes. Both glitches are easily overcome by explicitely setting items' background color once, e.g. right after creation.

Not a very workable solution when a tab can not be painted. The tabs color is dependent on the theme and color scheme in use so setting the controls background to 0xFFFFFF is going to look horrible on some systems. And with over 140 checkboxes in a script it's inconceivable that they will be changed now and then changed again later when a proper fix is in place.

comment:3 follow-up: Changed 10 years ago by Jpm

  • Resolution set to Works For Me
  • Status changed from new to closed

I don't understand the pb as if you remove the tabitem the checkbox is created not on the tab whatever you think it is as an ctrl over the tab control.
the bkcolor if defined just make the ctrl on the gui having the gui color.
For me there is no problem just difficulty on overlayed controls understanding which is point out in the doc to be a difficult problem !!!

comment:4 in reply to: ↑ 3 Changed 10 years ago by GEOSoft

Replying to Jpm:

I don't understand the pb as if you remove the tabitem the checkbox is created not on the tab whatever you think it is as an ctrl over the tab control.
the bkcolor if defined just make the ctrl on the gui having the gui color.
For me there is no problem just difficulty on overlayed controls understanding which is point out in the doc to be a difficult problem !!!

The problem is checkboxes can no longer be properly used on tabs. If you remove the Tab and TabItem from the code, the checkbox is correct. If you leave them in then the checkbox is totally unusable. It would seem totally ridiculous that we have to set the color for each checkbox because of what I pointed out about styles above. If that kind of behavior seems okay to the devs then perhaps you should consider rolling back the transparency changes made in the Beta.
Since the Tab color is set by Windows it makes no sense to preset the background color of each checkbox to 0xffffff. Example, when using the XP theme with the silver scheme, what appears ro be a white background for the tab is actually 0xfcfcfe. If you change the color scheme to olive green, the tab color may still appear to be white but in reality is 0xf4f3ee. A control background of 0xFFFFFF is noticable on either of these.

comment:5 Changed 10 years ago by Jpm

  • Resolution Works For Me deleted
  • Status changed from closed to reopened

It was not clear to me which script reproduce your problem.
In fact run the following script under Vista/Scite is OK but Vista only not !!!

$Frm_Main = GuiCreate("Test Form", 400,300)
$Tab = GUICtrlCreateTab(0,0,400,300)
$hTab_1 = GUICtrlCreateTabItem("Tab 1")
$hCheck = GUICtrlCreateCheckBox("Demonstration", 10, 30, 150, 20)
$hRadio = GUICtrlCreateRadio("Monopolistic Radio", 10, 60, 150, 20)
GUICtrlCreateTabItem("")
GUISetState()

Do
Until GuiGetMsg() = -3

The problem seems to come from the fact that the bk color tab is retrive with the pixel 0,0 of the tab ...
I work on the subject now

comment:6 Changed 10 years ago by Jpm

  • Milestone set to 3.3.1.1
  • Owner set to Jpm
  • Resolution set to Fixed
  • Status changed from reopened to closed

Fixed in version: 3.3.1.1

comment:7 Changed 10 years ago by jchd

Bug reappeared in 3.3.1.4 and 3.3.1.5 (OS:WIN_XP/Service Pack 3 CPU:X86). Here's another script to demo: run from Scite or compile. MessageBox says it all.

$Form1 = GUICreate("Form", 633, 450, 193, 125)
$Tab1 = GUICtrlCreateTab(32, 32, 553, 393)
GUICtrlCreateTabItem("First Tab")
$Checkbox1 = GUICtrlCreateCheckbox("Checkbox1", 96, 176, 177, 25)
$Checkbox2 = GUICtrlCreateCheckbox("Checkbox2", 96, 224, 177, 25)
$Group1 = GUICtrlCreateGroup("Group1", 328, 72, 217, 329)
$Radio1 = GUICtrlCreateRadio("Radio1", 352, 104, 161, 25)
$Radio2 = GUICtrlCreateRadio("Radio2", 352, 152, 161, 33)
$Radio3 = GUICtrlCreateRadio("Radio3", 352, 208, 161, 33)
GUICtrlCreateGroup("", -99, -99, 1, 1)
$Group2 = GUICtrlCreateGroup("Group2", 72, 272, 217, 129)
$Checkbox3 = GUICtrlCreateCheckbox("Checkbox3", 96, 296, 169, 25)
$Checkbox4 = GUICtrlCreateCheckbox("Checkbox4", 96, 336, 169, 33)
GUICtrlCreateGroup("", -99, -99, 1, 1)
GUISetState()

MsgBox(0, "Control background repaint issue with beta and release", _
          "Move this box (or any other window or dialog) around Form to demonstrate" & @LF & @LF & _
		  "Move from right to left or bottom to top: controls get dirty" & @LF & _
		  "Move from left to right or top to bottom: wipes all dust out" & @LF & @LF & _
		  "Release: radio text and labels get black background" & @LF & _
		  "Beta:    they get grey background")
Do
Until GuiGetMsg() = -3

comment:8 follow-up: Changed 10 years ago by Valik

  • Milestone 3.3.1.1 deleted
  • Resolution Fixed deleted
  • Status changed from closed to reopened

Undoubtedly a regression caused by the "fix" for #1087.

comment:9 in reply to: ↑ 8 Changed 10 years ago by anonymous

Replying to Valik:

Undoubtedly a regression caused by the "fix" for #1087.

Most probably indeed. Sorry I missed the link to this later one.

comment:10 Changed 10 years ago by Valik

  • Severity changed from None to Blocking

comment:11 Changed 10 years ago by Valik

  • Milestone set to 3.3.1.6
  • Owner changed from Jpm to Valik
  • Resolution set to Fixed
  • Status changed from reopened to closed

Fixed by revision [5418] in version: 3.3.1.6

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain Valik.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.