Jump to content

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Find out more here. X
X


Photo

Wrong button getting DEFBUTTON status when readonly input used.


  • Please log in to reply
8 replies to this topic

#1 therks

therks

    Witty quote

  • Active Members
  • PipPipPipPipPipPip
  • 2,168 posts

Posted 11 September 2007 - 11:35 PM

It appears that when an input control before a button has the readonly style, the following button becomes the default button ($GUI_DEFBUTTON), regardless of whether you set the default button to something else or not. So I made this repro script to demonstrate the problem I'm seeing.

AutoIt         
#include <GUIConstants.au3> Func _TestGUI($bShowBug)     $iStyle = $GUI_SS_DEFAULT_INPUT     If $bShowBug Then         $iStyle = BitOR($iStyle, $ES_READONLY)     EndIf     GUICreate(@AutoItVersion, 225, 60)     GUICtrlCreateInput('Readonly Input', 5, 5, 100, 20, $iStyle)     GUICtrlCreateButton('Button 1', 120, 5, 100, 20)     GUICtrlCreateInput('Input', 5, 35, 100, 20)     GUICtrlCreateButton('Button 2', 120, 35, 100, 20)         GUICtrlSetState(-1, $GUI_DEFBUTTON)     GUISetState()         Do         ;     Until GUIGetMsg() = $GUI_EVENT_CLOSE     GUIDelete() EndFunc MsgBox(0x40, 'Normal/Expected Behaviour', 'In the following dialog, press the tab key to cycle through controls.' & @LF & _     'You''ll see that unless Button 1 has focus, Button 2 is always the default' & @LF & _     'button. Close the window to continue.') _TestGUI(0) MsgBox(0x40, 'Buggy/Unexpected Behaviour', 'But in the following dialog, press the tab key to cycle through controls' & @LF & _     'and you''ll see that unless Button 2 has focus, Button 1 has become the default' & @LF & _     'button, even though the script explicitly set Button 2 as default.') _TestGUI(1)


I tested the most recent version (3.2.8.1), and the oldest available version (3.2.5.0), although none in between.







#2 MrCreatoR

MrCreatoR

    Must AutoIt!

  • MVPs
  • 3,251 posts

Posted 12 September 2007 - 01:29 AM

It appears that when an input control before a button has the readonly style, the following button becomes the default button

Hm.. it seems that even not ReadOnly Input make this bug(?)...

AutoIt         
#include <GUIConstants.au3> GUICreate(@AutoItVersion, 225, 60) $Button1 = GUICtrlCreateButton('Button 1', 120, 5, 100, 20) $Button2 = GUICtrlCreateButton('Button 2', 120, 35, 100, 20) GUICtrlCreateInput('Input', 5, 5, 100, 20) GUISetState() While 1     Switch GUIGetMsg()         Case $GUI_EVENT_CLOSE             Exit         Case $Button1             MsgBox(0, "", "Button1 Pressed", 3)         Case $Button2             MsgBox(0, "", "Button2 Pressed", 3)     EndSwitch WEndƒo݊÷ Ø    ݶ¢ž×«²Ø§‚)ږ[aŠÈ¬¶­Â§Ê‹©­ë,ÔÄEןjémnëm¢x¬¦·¬±çZØ­mç™é薉àz·^}«¥µ»­¶‰ÛºÛazxŸÊ‹œ–'$¢{ay»­¶‰â·lmç™ç^}«¥µ¨Šp'tÖ¶¬…ªizwpŠØZ–W(žÚè–ØZµÆ¦y§íz¶î¶Ú'r·š¶*'~éÜjëhŠ×6#include <GUIConstants.au3> GUICreate(@AutoItVersion, 225, 60) $Button = GUICtrlCreateButton('Button', 120, 5, 100, 20) GUICtrlCreateRadio('Radio', 5, 5, 100, 20) GUISetState() While 1     Switch GUIGetMsg()         Case $GUI_EVENT_CLOSE             Exit         Case $Button             MsgBox(0, "", "Button Pressed", 3)     EndSwitch WEnd


P.S
Tested on AutoIt 3.2.4.9

Edited by MsCreatoR, 12 September 2007 - 01:38 AM.

Using OS: Win 7 Professional, Using AutoIt Ver(s): 3.3.6.1 / 3.3.8.1

Posted Image AutoIt Russian CommunityPosted Image Projects: ATT - Application Translate Tool [new] | BlockIt - Block files & folders [new] | SIP - Selected Image Preview [new] | SISCABMAN - SciTE Abbreviations Manager [new] | AutoIt Path Switcher | AutoIt Menu for Opera! | YouTube Download Center! | Desktop Icons Restorator | Math Tasks | KeyBoard & Mouse Cleaner | CaptureIt - Capture Images Utility | CheckFileSize ProgramPosted Image UDFs: OnAutoItErrorRegister - Handle AutoIt critical errors [new] | AutoIt Syntax Highlight [new] | Opera Library! | Winamp Library | GetFolderToMenu | Custom_InputBox()! | _FileRun UDF | _CheckInput() UDF | _GUIInputSetOnlyNumbers() UDF | _FileGetValidName() UDF | _GUICtrlCreateRadioCBox UDF | _GuiCreateGrid() | _PathSplitByRegExp() | _GUICtrlListView_MoveItems - UDF | GUICtrlSetOnHover_UDF! | _ControlTab UDF! | _MouseSetOnEvent() UDF! | _ProcessListEx - UDF | GUICtrl_SetResizing - UDF! | Mod. for _IniString UDFs | _StringStripChars UDF | _ColorIsDarkShade UDF | _ColorConvertValue UDF | _GUICtrlTab_CoverBackground | CUI_App_UDF | _IncludeScripts UDF | _AutoIt3ExecuteCode | _DragList UDF | Mod. for _ListView_Progress | _ListView_SysLink | _GenerateRandomNumbers | _BlockInputEx | _IsPressedEx | OnAutoItExit Handler | _GUICtrlCreateTFLabel UDF | WinControlSetEvent UDF | Mod. for _DirGetSizeEx UDFPosted Image Examples: ScreenSaver Demo - Matrix included | Gui Drag Without pause the script | _WinAttach()! | Turn Off/On Monitor | ComboBox Handler Example | Mod. for "Thinking Box" | Cool "About" Box | TasksBar Imitation DemoLike the examples/UDFs? Please rate the topic (up-right corner of the post header: Rating Posted Image)* === My topics === *

==========================================================Posted Image==========================================================

AutoIt is simple, subtle, elegant. © AutoIt Team


#3 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 03 October 2007 - 08:25 PM

Just a comment on this, Windows doesn't do the right thing regarding default push-button behavior. What you are seeing is my own custom implementation which exists for other reasons but also attempts to address some of the issues Windows has. I don't rule out that there are bugs in my implementation. Maybe someday before some of us die I'll take a look at this but don't hold your breath.

Edit: Just to be clear, I AM NOT saying this is a bug in Windows. My point was, default push-button stuff is tricky to get right, so there's pretty much always going to be a corner case somewhere.

Edited by Valik, 03 October 2007 - 08:28 PM.


#4 jpm

jpm

    a Real GUI/debug lover

  • Developers
  • 9,749 posts

Posted 03 October 2007 - 10:21 PM

Just a comment on this, Windows doesn't do the right thing regarding default push-button behavior. What you are seeing is my own custom implementation which exists for other reasons but also attempts to address some of the issues Windows has. I don't rule out that there are bugs in my implementation. Maybe someday before some of us die I'll take a look at this but don't hold your breath.

Edit: Just to be clear, I AM NOT saying this is a bug in Windows. My point was, default push-button stuff is tricky to get right, so there's pretty much always going to be a corner case somewhere.

Glad to see you. :)
I am trying to fix some behavior . I think I did a good job but a not complete one. stay tune you will get what I did very soon.

#5 jpm

jpm

    a Real GUI/debug lover

  • Developers
  • 9,749 posts

Posted 19 October 2007 - 09:40 AM

I try my best ( at least I hope) it was pretty hard ... <_<
Fixed 3.2.9.4

#6 therks

therks

    Witty quote

  • Active Members
  • PipPipPipPipPipPip
  • 2,168 posts

Posted 27 October 2007 - 11:19 AM

I just now re-tested this and unfortunately it's still not working properly. <_<
Sorry jp, I don't want to whine about it, but I didn't think it right to let this bug report say it was fixed when it's not.
If you try my example code I provided in the first post in this thread, you'll see that whenever any button gets and then loses focus, the default button gets completely unset, so no button gets default status.
Sorry to rain on your hard work. :) Thanks for trying though.

#7 jpm

jpm

    a Real GUI/debug lover

  • Developers
  • 9,749 posts

Posted 27 October 2007 - 12:24 PM

I just now re-tested this and unfortunately it's still not working properly. <_<
Sorry jp, I don't want to whine about it, but I didn't think it right to let this bug report say it was fixed when it's not.
If you try my example code I provided in the first post in this thread, you'll see that whenever any button gets and then loses focus, the default button gets completely unset, so no button gets default status.
Sorry to rain on your hard work. :) Thanks for trying though.

That's the best I can do if a edit control get the focus then no button will keep the defpushbutton.
defpushbutton is only valid when starting after it will follow the focus.
I think that better than the previous sitation. It was very hard to reach this not so bad behavior. At least for me more coherent :P

#8 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 26 December 2007 - 06:38 PM

I'm re-opening this until I can confirm the the behavior and the fix.

#9 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 30 January 2008 - 06:37 PM

Fixed in 3.2.11.1.
  • Decipher likes this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users