WebDriver UDF (W3C compliant version) - 2024/09/21

[Danp2]

I split out webdriver.au3 into two separate files --

• wd_core - containing the primary functions for interacting directly with a web driver
• wd_helper - all other functions written for the benefit of the script writer

So, you'll want to include wd_core.au3 instead of webdriver.au3.

HTH, Dan

[Danp2]

12 hours ago, Danp2 said:

Trying to think this through and wondering if we really need separate functions for gathering sets of links, tables, images, etc.

Anyone care to share their opinion on this?

I decided to go a different direction with this and enhanced _WD_FindElement to return an array of element IDs. IMO, this eliminates the need for any of the aforementioned functions to retrieve different element types.

Latest version is up on GH -- https://github.com/Danp2/WebDriver/releases/latest

[junkew]

Lets see if we can make a small wrapper around findelement similar as i did with uiawrappers to have more logical syntax for 

• Match with regular expressions
• Use multiple properties
• Use instance and indexrelative properties

So syntax like

"Title:=*titlename*"

"Value:=((dutch)|(english))"

 

 

[mLipok]

I think this is a good extended feature, 

But there should be also possibility to easy switch from IE.au3 or from FF.au3 to WedDriver.

So I propose to create FindElementEx ...

 

[Danp2]

44 minutes ago, junkew said:

Lets see if we can make a small wrapper around findelement similar as i did with uiawrappers

Sounds good. Look forward to your submission. 

31 minutes ago, mLipok said:

I think this is a good extended feature, 

Yes, this could be a good "helper" function

32 minutes ago, mLipok said:

But there should be also possibility to easy switch from IE.au3 or from FF.au3 to WedDriver.

I don't expect there to be a one-to-one translation for each function in the existing UDFs. As I mentioned in #63 above, _WD_FindElement is supports multiple selection types and you can replace many different function calls from the existing UDFs with this single command.

I am starting to rewrite one of my main scripts, which supports both IE and Firefox, to use this new WD script. As I proceed, I expect to run into issues that will lead me to rewrite some things and also give ideas where additional "helper" functions would be useful.

One example of this is that I started running into issues with COM errors due to the use of the WinHttpRequest object. As such, I am currently replacing related code with calls to @trancexx's WinHttp UDF.

[mLipok]

I'm not talking about one to one conversion.
But at least functions should be comparable in naming, and basic functionality.

btw.
I think @trancexx WInHttp UDF is a great UDF for automating many web sites, but if you want to do UDF for specific webservice then I am an advocate of internal / independent solutions.
You can see what I mean in my TeamViewerAPI UDF, CrowdinAPI UDF, GHAPI UDF.

In case of WebDriver I think the problem is also WinHttp UDF license, which is different then this UDF.

 

Edited January 28, 2018 by mLipok

[Danp2]

@mLipok Is there a way to deal with the situation when there are multiple UDFs that each want to install their own error handler?

Edited January 29, 2018 by Danp2

[mLipok]

1 hour ago, Danp2 said:

@mLipok Is there a way to deal with the situation when there are multiple UDFs that each want to install their own error handler?

You mean COM Error Handler ? >> Yes. Define them locally for each function using COM Object.
Take a look in my XML ADO or other UDF.

 

Edited January 29, 2018 by mLipok

[mLipok]

@Danp2 I would look for this COM error problems but in next few days I will be busy with other projects.

[Danp2]

@mLipok It's all good. I should have an update soon. Appreciate the pointers...

[mLipok]

Here is a quick shot:

expandcollapse popup

Func __WD_Delete($sURL)
    Local Const $sFuncName = "__WD_Delete"
    Local $sResponseText = __WD_HttpSender("DELETE", $sURL, $sFuncName, False, 5)

    Return $sResponseText
EndFunc   ;==>__WD_Delete

Func __WD_HttpSender($sCommand, $sURL, $sFuncName, $bParam, $iWait = 5)
    Local $oErrorHandler = ObjEvent("AutoIt.Error", __WD_ErrFunc)

    Local $oHTTP = ObjCreate("winhttp.winhttprequest.5.1")
    $oHTTP.Open($sCommand, $sURL, $bParam)
    $oHTTP.SetRequestHeader("Content-Type", "application/json;charset=utf-8")
    $oHTTP.Send()

    ; wait until response is ready
    $oHTTP.WaitForResponse($iWait)

    $_WD_HTTPRESULT = $oHTTP.Status

    Local $sResponseText = $oHTTP.ResponseText
    If $_WD_DEBUG Then _
            ConsoleWrite($sFuncName & ': StatusCode=' & $_WD_HTTPRESULT & "; ResponseText=" & $sResponseText & @CRLF)

    If $_WD_HTTPRESULT <> 200 Then _
            SetError(__WD_Error($sFuncName, $_WD_ERROR_Exception, $sResponseText))

    Return $oHTTP.ResponseText
EndFunc   ;==>__WD_HttpSender

Func __WD_ErrFunc(ByRef $oError)
    If $_WD_DEBUG Then ConsoleWrite( _
            @ScriptName & " (" & $oError.scriptline & ") : ==> COM Error intercepted !" & @CRLF & _
            @TAB & "err.number is: " & @TAB & @TAB & "0x" & Hex($oError.number) & @CRLF & _
            @TAB & "err.windescription:" & @TAB & $oError.windescription & @CRLF & _
            @TAB & "err.description is: " & @TAB & $oError.description & @CRLF & _
            @TAB & "err.source is: " & @TAB & @TAB & $oError.source & @CRLF & _
            @TAB & "err.helpfile is: " & @TAB & $oError.helpfile & @CRLF & _
            @TAB & "err.helpcontext is: " & @TAB & $oError.helpcontext & @CRLF & _
            @TAB & "err.lastdllerror is: " & @TAB & $oError.lastdllerror & @CRLF & _
            @TAB & "err.scriptline is: " & @TAB & $oError.scriptline & @CRLF & _
            @TAB & "err.retcode is: " & @TAB & "0x" & Hex($oError.retcode) & @CRLF & @CRLF)
EndFunc   ;==>__WD_ErrFunc

 

EDIT: Snippet is changed.

btw.
ObjCreate("winhttp.winhttprequest.5.1") should be also local - look in my proposal.

Edited January 29, 2018 by mLipok

[NguyenLe]

@Danp2

Does it work when the screen is off?

[mLipok]

It should work as far as you not get any POP UP window, but I want to ask you did you try ?

 

[Danp2]

@NguyenLe By "screen off", do you mean a hidden window? If so, I have yet to test this scenario. Please let us know your results if you decide to check it out.

[Danp2]

23 hours ago, mLipok said:

Here is a quick shot:

 I have some reservations about implementing this method. AFAIK, there's no way to prevent other UDFs from trampling on the error handler or to properly restore error handling setup by a prior UDF or the main application.

[mLipok]

28 minutes ago, Danp2 said:

there's no way to prevent other UDFs from trampling on the error handler or to properly restore error handling setup by a prior UDF or the main application.

This was just a quick shot.

Did you look in my ADO UDF ?

 

[Danp2]

@mLipok No, I'll take a look at it now. I did briefly look at two others (TV and GH).

I also reviewed this thread.

 

[mLipok]

TVAPI UDF is a good concept/exmaple how to manage HTTP statuses...

_TVAPI_GET_Status()
_TVAPI_GET_StatusText()
_TVAPI_GET_ResponseText()
 

But TVAPI UDF and GHAPI UDF is bad if you look how I manage COM Errors
 

Global $oErrorHandler = ObjEvent("AutoIt.Error", "_TVAPI_ErrFunc")

 

For COM Error Handling example with feature / possibility of transferring the error handling from the internal error handling in user own way (manage from main script), look in ADO UDF for:

Local $oADO_COM_ErrorHandler = ObjEvent("AutoIt.Error", __ADO_ComErrorHandler_InternalFunction)

and:
 

Func __ADO_ComErrorHandler_InternalFunction(ByRef $oCOMError)
    ; Do nothing special, just check @error after suspect functions.
    #forceref $oCOMError
    Local $sUserFunction = _ADO_COMErrorHandler_UserFunction()
    If IsFunc($sUserFunction) Then $sUserFunction($oCOMError)
EndFunc   ;==>__ADO_ComErrorHandler_InternalFunction

 

 

Edited January 30, 2018 by mLipok

[NguyenLe]

@Danp2 Its most does not work if I turn off the display

[Danp2]

@NguyenLe Please define "turn off the display". I interpret that to mean that you turned off the computer monitor. However, it could also mean hiding the browser window like I mentioned here --

Which of these is the correct interpretation? Also, post some code showing the issue so that we can try it on our end.