Custom Query


Show under each result:

Results (64 - 66 of 3827)

Ticket Resolution Summary Owner Reporter
#64 Rejected Enhance special description for recognizing controls junkew@…

Actually 2 request(s) to combine and not yet sure whats most logical place to do (part can be done in a UDF)

"[CLASS:Edit; INSTANCE:1]" is a real powerfull way of recognizing controls. I would like to see this enhanced with more possibilities like

  • using any property that is available in Window Info tool
  • using more advanced logic like "[CLASS:*Edit*; INSTANCE:1]" regular expression syntax "[VIRTUALAREA: (Square|Circle) x1,x2,y1,y2 (RelativeWindow|RelativeClient|Desktop)]" If its not a control but a certain area which is hard to recognize (would be nice if you can select the area of interest with window info tool which you then in your script can use just as if its a control but actually is not) "[CLASS:Edit; INSTANCE:1; TABS: n]" where TABS means send n TABS to activate next control (also for lauzy unrecognizable controls due to not beeing native windows controls) n can be negative. "[BITMAP: name" search the window with bitblt or similar function till matching area is found and then use this area to act on just like its a control, name is filename/location of bitmap to use (which was previously saved with capturing tool)).
  • Have a translation table for logical and technical naming Logical name: Notepad text area Technical name: "[CLASS:Edit; INSTANCE:1]"

Then use in ControlSend("Untitled - Notepad", "", "Notepad text area", "This is some text") Where then logical name is translated to technical name

  • Translation table should have ability of grouping/hierarchy of logical names. For example

Logical Technical 01.Calculator screen "[CLASS:SciCalc; INSTANCE:1]" +---> 01.result "[CLASS:Edit; INSTANCE:1]" +---> 02.btnOne "[CLASS:Button; ID:125]" 02.Paint "[CLASS:MSPaintApp; INSTANCE:1]" +---> 01.Paintarea "[CLASS:Afx:1000000:8; INSTANCE:1]" +---> 02.Paintarea duplicate "[CLASS:Afx:1000000:8; INSTANCE:1]" 03.Calculator screen 2 "[CLASS:SciCalc; INSTANCE:1]" +---> 01.result "[CLASS:Edit; INSTANCE:1]"

Duplicates on technical level should be allowed as the main purpose is to have logical names that can be used in the scripting itself. Actually I put something like above now in an array at start of my script and have a lookup UDF but this is a tedious job (but is better maintainable instead of having all the technical names scattered in my script)

  • Integrate this in Window Info tool
  • Have in window info tool a way to predefine for each Class which properties should be combined to create special description.

So if I select notepad text window which is of Class Edit that I immediately can copy "[CLASS:Edit; INSTANCE:1]" instead of typing it in myself in my script.

I think above will be a major enhancement and gives even more possibilities for AutoIt to be used in testautomation situations and will reduce maintenance on scripting

#65 Wont Fix Au3Check gives wrong error with Const ByRef params Valik Valik

The following code:


Func CallNonConst()
	Local $a = 32

Func CallConst()
	Local Const $a = 32

Func TakesConstByRef(Const ByRef $c)
	ConsoleWrite($c & @CRLF)

produces this error:

New AutoIt v3 Script.au3(15,37) : ERROR: TakesConstByRef() previously called with expression on Const ByRef param(s).
Func TakesConstByRef(Const ByRef $c)
New AutoIt v3 Script.au3(6,20) : REF: first call to TakesConstByRef().
New AutoIt v3 Script.au3 - 1 error(s), 0 warning(s)

The error is wrong. The code is perfectly valid. The problem is using a non-const and a const in the same script with the same function. It seems Au3Check is trying to infer something incorrectly. If you modify both examples to be identical (Either add Const to the Local it's missing from or remove it from the one where it's present) then there is no error. All Au3Check needs to worry about is making sure a variable is being passed to the ByRef statement, it doesn't need to concern itself if the variable is Const or not.

#66 Fixed BS_DEFPUSHBUTTON getting lost Valik 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.


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


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("App Version:",10,87,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)


While 1
	$msg = GUIGetMsg()
	Switch $msg
		Case -3,$cancel
		Case $create

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
			Return SetError($lastError[0], $lastError[0], 0)
	Return $handle[0]
Note: See TracQuery for help on using queries.