Custom Query
Results (7 - 9 of 3866)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#865 | Fixed | winhttp.winhttprequest.5.1 ObjEvent unhandled exception. | Jon | foster74 |
Description |
$oHTTP = ObjCreate("winhttp.winhttprequest.5.1") $EventObject = ObjEvent($oHTTP, "Event_") $oHTTP.open("GET", "http://google.com", True) $oHTTP.send() +>22:41:14 Starting AutoIt3Wrapper v.1.10.1.14 Environment(Language:0409 Keyboard:00000409 OS:WIN_VISTA/Service Pack 1 CPU:X86 ANSI) >Running AU3Check (1.54.14.0) from:C:\Program Files\AutoIt3 +>22:41:14 AU3Check ended.rc:0 >Running:(3.3.0.0):C:\Program Files\AutoIt3\autoit3.exe "C:\Users\blah\tmp.au3" !>22:41:17 AutoIT3.exe ended.rc:-1073741819 +>22:41:18 AutoIt3Wrapper Finished >Exit code: -1073741819 Time: 4.800 |
|||
#139 | Rejected | window identification / fixing current window | _alexei@… | |
Description |
Currently, AutoIt can not guarantee keystrokes sent by Send would go to the particular window. Focus may change because of many reasons (other app. activity, system popup, user interference, etc.) There is no simple way to find a window with particular relation to already known window in terms of child/parent/sibling/owner of any level, also, verifying window class and other properties. That's pretty easy to implement by verifying each window in Z-chain against specified properties and relations. I want to be 100% sure AutoIt clicks the button (or sends keystrokes to the window) it was programmed to. Bottom line: util window identification becomes reliable, AutoIT is just a dangerous toy, unsuitable to serious applications. BTW, "special treatment" of controls creates unnecessary limitations, as controls are just windows with specific relations to the parent/owner. |
|||
#3278 | Rejected | win\print\suffix | anonymous |