Modify

Opened 12 years ago

Closed 12 years ago

#66 closed Bug (Fixed)

BS_DEFPUSHBUTTON getting lost

Reported by: Larry Owned by: Valik
Milestone: 3.2.11.1 Component: AutoIt
Version: 3.2.10.0 Severity:
Keywords: GUI button style Cc:

Description

If I tab around or click somewhere and tab I lose the $BS_DEFPUSHBUTTON ability of my button.

When the dialog comes up press [Enter] and it works... tab around and press [Enter] and it works no more.

_Singleton("mdioahffifmffkjkfs")

#include <StaticConstants.au3>
#include <ButtonConstants.au3>
#include <WindowsConstants.au3>

Opt("RunErrorsFatal",0)

Global $sRoot="\\not important\projects\s\stuff\Dev"

$gui = GUICreate("Package File Structure",400,230,-1,-1,BitOR($WS_CAPTION,$WS_SYSMENU));,$WS_EX_TOPMOST)
GUICtrlCreateLabel("Root Dir:",10,12,80,18,$SS_RIGHT)
GUICtrlCreateLabel("Vendor:",10,37,80,18,$SS_RIGHT)
GUICtrlCreateLabel("Application:",10,62,80,18,$SS_RIGHT)
GUICtrlCreateLabel("App Version:",10,87,80,18,$SS_RIGHT)
GUICtrlCreateLabel("Customer:",10,112,80,18,$SS_RIGHT)
GUICtrlCreateLabel("OS:",10,137,80,18,$SS_RIGHT)
GUICtrlCreateLabel("App Language:",10,162,80,18,$SS_RIGHT)

$root = GUICtrlCreateInput($sRoot,95,8,210,22)
$browse = GUICtrlCreateButton("&Browse...",310,8,80,22)

$vendor = GUICtrlCreateInput("",95,33,295,22)
$app = GUICtrlCreateInput("",95,58,295,22)
$appver = GUICtrlCreateInput("",95,83,295,22)
$customer = GUICtrlCreateInput("",95,108,295,22)
$os = GUICtrlCreateInput("",95,133,295,22)
$applang = GUICtrlCreateInput("",95,158,295,22)

$create = GUICtrlCreateButton("C&reate",205,188,185,30,$BS_DEFPUSHBUTTON)
$cancel = GUICtrlCreateButton("&Cancel",10,188,185,30)

GUISetState()

While 1
	$msg = GUIGetMsg()
	Switch $msg
		Case -3,$cancel
			Exit
		Case $create
			MsgBox(4096,"","DEFPUSHBUTTON WORKED")
	EndSwitch
WEnd

Func _Singleton($sOccurenceName, $iFlag = 0)
	Local $ERROR_ALREADY_EXISTS = 183, $handle, $lastError
	
	$sOccurenceName = StringReplace($sOccurenceName, "\", "")
	$handle = DllCall("kernel32.dll", "int", "CreateMutex", "int", 0, "long", 1, "str", $sOccurenceName)
	$lastError = DllCall("kernel32.dll", "int", "GetLastError")
	If $lastError[0] = $ERROR_ALREADY_EXISTS Then
		If $iFlag = 0 Then
			Exit -1
		Else
			Return SetError($lastError[0], $lastError[0], 0)
		EndIf
	EndIf
	Return $handle[0]
EndFunc

Attachments (0)

Change History (7)

comment:1 Changed 12 years ago by Valik

  • Owner set to Valik
  • Status changed from new to assigned

comment:2 in reply to: ↑ description Changed 12 years ago by Jpm

Replying to Larry:

If I tab around or click somewhere and tab I lose the $BS_DEFPUSHBUTTON ability of my button.

When the dialog comes up press [Enter] and it works... tab around and press [Enter] and it works no more.

For me NOBUG, as soon you tab you get a new control which get the new defbutton action see the around button "hightlight". I assume Valik disagree with this behavior that the reason he assign to him.

comment:3 follow-ups: Changed 12 years ago by Valik

I just want to validate that the behavior is correct by comparing it with a standard Windows dialog.

comment:4 in reply to: ↑ 3 Changed 12 years ago by jpm

Replying to Valik:

I just want to validate that the behavior is correct by comparing it with a standard Windows dialog.

In this case I think they are. But well I may be wrong

comment:5 in reply to: ↑ 3 ; follow-up: Changed 12 years ago by Saunders <admin@…>

Replying to Valik:

I just want to validate that the behavior is correct by comparing it with a standard Windows dialog.

I believe that losing the defbutton status is not valid behaviour. I just right-clicked on my taskbar and hit Properties to check that window. The OK button has defbutton status. As I tab through contols it keeps defbutton status except when a different button has focus - which gets the defbutton status at that moment - but when a non-button control again gets focus the OK button regains defbutton status.

comment:6 in reply to: ↑ 5 Changed 12 years ago by Valik

Replying to Saunders <admin@therks.com>:

I believe that losing the defbutton status is not valid behaviour. I just right-clicked on my taskbar and hit Properties to check that window. The OK button has defbutton status. As I tab through contols it keeps defbutton status except when a different button has focus - which gets the defbutton status at that moment - but when a non-button control again gets focus the OK button regains defbutton status.

What you describe sounds like what I thought and why I wasn't ready to mark this as closed. I just haven't had time to check on it. This and the other edit focus/default button bugs are all related to what is essentially a single large change in AutoIt I was going to take a look at all of these issues at once since they are all related.

comment:7 Changed 12 years ago by Valik

  • Milestone set to 3.2.11.1
  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in version 3.2.11.1.

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.