seangriffin

📢 New: AutoIt extension for VS Code (companion to the CDP UDF) Hi everyone, Alongside the AutoIt CDP UDF I've been building a companion VS Code extension that brings a SciTE-like AutoIt experience into VS Code — with IntelliSense that understands the CDP UDF's Playwright-style objects. It's now at the point where it's genuinely pleasant to work in daily, so I'd like to share it with the community. Editing Syntax highlighting for AutoIt (case-insensitive, as AutoIt itself is), including #cs/#ce block comments (nesting supported) with comments shown in grey italics, SciTE-style A matching dark colour theme ("AutoIt Matte") IntelliSense Completion for AutoIt's built-in functions (parsed from au3.api) with signature help and parameter hints as you type Completion for keywords, all @macros, and #directives / special commands — with documentation shown for each Hover help: point at any function, macro, directive, or keyword to see its signature and description CDP UDF-aware completion: $cdp, browser/page objects, and the full Locator API (.locator(...).click, .fill, .waitFor, getByRole, and friends) with parameter hints Running scripts (SciTE-style) F5 runs the current script: Au3Check runs first (quiet mode), and if it reports errors the script does not run — just like SciTE Look for the "Run AutoIt" button in the VS Code status bar Only one script runs at a time; Stop (Ctrl+Break or the status-bar button) terminates only the script the editor started, nothing else Look for the "Stop" button in the VS Code status bar Console output (including ConsoleWrite) streams live into VS Code's output pane SciTE conveniences Alt+D debug-to-console: highlight an expression and a ConsoleWrite('@@ Debug(...) line with @error reporting is inserted below, correctly indented Ctrl+F1 context help: opens the AutoIt help file at the topic for the word under the cursor (works for functions, macros, and directives; F1 itself is taken by VS Code). Falls back to the online docs if the help file isn't installed It's an early release, so some things (e.g. the go-to-definition or debugging you'd find in mature extensions) aren't there yet. I haven't yet released this to the VS Code marketplace. You will need to install manually into VS Code via the "Install from VSIX..." option. The file in the Github repository is named autoit-lsp-0.0.1.vsix. Here's a direct link: https://github.com/seanhaydongriffin/autoit-cdp-udf/blob/main/autoit-lsp-0.0.1.vsix

And here is another significant architectural change ... 🧭 New Locator Architecture (Playwright‑Style) Locators now resolve elements at method invocation time, not at locator creation time. This matches Playwright’s behaviour and fixes: stale element handles navigation timing issues scrollIntoView misalignment boundingBox failures screenshot coordinate drift Example: $oPage.locator("#login").click() Internally: _locate() (auto‑wait) scrollIntoViewIfNeeded() (fast locate) boundingBox() (fast locate) Input.dispatchMouseEvent() (click) This makes the UDF significantly more reliable and modern.

Thanks gmmg. I can recognise the issues in _CDP_Browser_Launch so I've redesigned it. I hope this helps ... 🚀 New Browser Launch API (Cleaner, Typed, Extensible) The browser launch function has been redesigned to use typed enums for browser selection and a JSON options object for configuration: Func _CDP_Browser_Launch($browser = $CDPBROWSER_CHROME, $jOptions = Null) Browser selection via enums: $CDPBROWSER_CHROME $CDPBROWSER_EDGE $CDPBROWSER_FIREFOX $CDPBROWSER_CHROMIUM $CDPBROWSER_CHROME_BETA $CDPBROWSER_CHROME_DEV $CDPBROWSER_CHROME_CANARY $CDPBROWSER_EDGE_BETA $CDPBROWSER_EDGE_DEV $CDPBROWSER_EDGE_CANARY Optional configuration via JSON: Local $opts = _JsonC_Object() $opts.add("port", 9299) $opts.add("windowSize", "1280,800") $opts.add("version", 119) $chrome = $browser.launch($CDPBROWSER_CHROME, $opts) This design: avoids parameter explosion is self‑documenting supports pre‑installed browsers supports portable browsers supports Selenium Manager for versioned downloads is easy to extend

📢 New Feature: Built‑in Video Capture for CDP UDF A new feature has been added to the CDP UDF: automatic video capture of test runs using Chrome’s Page.screencastFrame stream and a lightweight FFmpeg‑based recorder. This makes it easy to record UI behaviour during tests, debug failures, and archive visual evidence of test runs. 🎬 How to enable video capture A new configuration flag has been added: $cdp.config.video = $CDPVIDEO_ON Setting this to ON enables video recording for any test block. 🧪 How video capture works Video capture automatically starts when you enter a test block: With test("Basic Inputs test") ; your test steps here EndWith And automatically stops when the EndWith is reached. No extra commands are required. 📁 Where videos are saved Each test run writes its video to: test-results\<test name>\video.webm For example: test-results\Basic Inputs test\video.webm This keeps videos neatly organised per test. 📟 Console output At the end of each test, the runner prints a message showing the full path of the captured video: 🎥 Video: C:\...\test-results\Basic Inputs test\video.webm This makes it easy to locate and open the recording after the test completes. 📄 Example script included A new example script has been added: Example Video Capture.au3

I expect that would be possible. I know MS Edge is built on chromium so I would expect the underlying devtools protocol is the same. Thanks for the suggestion I'll look into it.

📢 Announcing Enterprise Mode — An extra Automation Architecture for the CDP UDF A major new feature has been added to the CDP UDF: Enterprise Mode, a layered automation model designed for system‑level and acceptance‑level testing. ✔ UI Script Layer Modular page‑level automation under UI\. ✔ Functional Area (FA) Layer Business‑process automation under FA\. ✔ Hierarchical Datapools CSV‑driven test data across Release → Environment → Functional Area tiers. ✔ Enterprise Logging High‑precision datetime stamps and full script call‑chaining logs showing caller script, callee method, and line numbers. Enterprise Mode allows you to build scalable, maintainable automation that mirrors real business workflows while keeping UI automation clean and modular. This is an optional feature you can enable with the line: $cdp.config.enterpriseMode = True Examples are now available in the GitHub repository. Look for: Example Enterprise Mode Acceptance Tests.au3 Example Enterprise Mode System Tests.au3 Documentation will be added in due course.

Good point and sorry I didn't understand the context of your previous post. Makes sense now. Yes the UDF should expand on the many wonderous ways that browsers can be called via different installation paths. 😉 I didn't want to initially get bogged down in those details. But work revisiting now its maturing. Thanks

Management of cookies is an interesting concern. I didn't want to mandate the UDF work one way or the other. In my own use cases of the UDF I need to support both options. Either needing the browser to retain no knowledge of the web application in each run, or in situations where I need cookies and credentials to be retained between test runs but have no want or need to capture those in the script (perhaps for security or privacy reasons). Thus I included the final parameter on the browser launch method - $clearCookies - so you can control this yourself. Which provides the similar functions you are including in your script ... if $clearCookies = True Then FileDelete($profile & "\Default\Cookies") FileDelete($profile & "\Default\Cookies-journal") FileDelete($profile & "\Default\Network\Cookies") FileDelete($profile & "\Default\Network\Cookies-journal") EndIf

Not sure what your question is. Do you want to start chrome from a network path? I've never attempted that. You can try changing the first parameter of the $browser.launch method (in your example Default) to an alternate path for chrome itself (chrome.exe). By default modern chrome instances reside in @ProgramFilesDir & "\Google\Chrome\Application\chrome.exe" and that's what Default currently refers to. I have been meaning to publish a very simple example on the usage of the UDF. I took your example and reduced it to a bare-minimal form that works (with no parameters for launch) ... #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_UseX64=y #AutoIt3Wrapper_Change2CUI=y #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #include "CDP.au3" $chrome = $browser.launch() $page = $chrome.newPage() $page.goto("https://autoit.de/wcf/login/") $page.locator("//*[@id='username']").sendKeys("Username") $page.locator("//*[@id='password']").sendKeys("Password") $page.locator("//*[@id='submitButton']").click()

This UDF does not use or require a WebDriver (meaning chromedriver for Chrome)

If the only features you use in this UDF are chrome automation features then the only FileInstall that should be required is libcurl-x64.dll. If you use any of the API features and security related functions in those features like SSL then you may additionally need FileInstall for curl-ca-bundle.crt. FileInstall for selenium-manager.exe is only required if you use that feature in the launch method for a browser. FileInstall for sqlite3.exe and sqlite3_x64.dll is for an upcoming feature named "Enterprise Mode" which takes the UDF into features beyond that of Playwright, such as test data management. This UDF does not use or require WebDriver at all.

Ohhh great pickup thanks! I recently embedded the json-c.dll directly inside the JsonC.au3 so json-c.dll isn't required anymore. But I forgot to remove it from the FileInstall command at the top of the UDF ... #AutoIt3Wrapper_UseX64=y FileInstall(".\json-c.dll", ".\") FileInstall(".\libcurl-x64.dll", ".\") FileInstall(".\selenium-manager.exe", ".\") Nice pickup. I have made this fix to CDP.au3 and uploaded to Github. >Running:(3.3.18.0):C:\Program Files (x86)\AutoIt3\aut2exe\aut2exe.exe /in "C:\dwn\autoit-cdp-udf\temp_example.au3" /out "C:\Users\SGriffin\AppData\Local\AutoIt v3\Aut2exe\~AU6DF5.tmp.exe" /nopack /comp 2 /Console /x64 +>21:37:17 Aut2exe.exe ended.C:\Users\SGriffin\AppData\Local\AutoIt v3\Aut2exe\~AU6DF5.tmp.exe. rc:0 +>21:37:17 Created program:C:\dwn\autoit-cdp-udf\temp_example.exe +>21:37:18 AutoIt3Wrapper Finished. Doh! I forgot to upload selenium-manager.exe to Github 😔 Sorry. Have uploaded it now. Your next download should work. Thanks for the update!

📢 JsonC‑UDF Updated — Now using json‑c v0.18 + Embedded x86/x64 DLLs I’ve pushed a major update to the JsonC‑UDF. The UDF now uses json‑c v0.18 (the latest stable release) and no longer requires you to supply an external DLL. ✔ Embedded DLLs (x86 + x64) Both 32‑bit and 64‑bit builds of json‑c v0.18 are now embedded directly inside the UDF. The UDF automatically detects the running AutoIt architecture and loads the correct DLL at runtime. No more: _JsonC_Startup("json-c.dll") The startup function is now completely automatic: Func _JsonC_Startup() Local $bBinaryImage If @AutoItX64 Then $bBinaryImage = __JsonC_Dll_X64() Else $bBinaryImage = __JsonC_Dll() EndIf $__g_hDll_JsonC = __JsonC_LoadBinaryDll($bBinaryImage, "explorer.exe") If @error Then $__g_hDll_JsonC = 0 Return SetError(1, 0, "") EndIf EndFunc This means the UDF is now zero‑dependency — just include it and go. ✔ Faster, safer, more stable json‑c v0.18 brings: faster parsing faster array/object operations better UTF‑8 handling lower memory usage more predictable behavior fewer crashes due to internal API exposure The UDF benefits from all of this automatically. The updated UDF is available now on GitHub.

📢UDF Update — New HTTP API Support (GET, POST, DELETE) Hi everyone, I’m excited to share a new feature update for the CDP UDF: built‑in HTTP API support for GET, POST, and DELETE requests. This makes it much easier to integrate REST API testing directly into your CDP automation workflows. The API layer is lightweight, uses the JsonC UDF for request/response handling, and keeps your scripts clean and expressive. Three new example scripts are included (Github link in the top post): Example API GET.au3 Example API POST.au3 Example API DELETE.au3 Below are the same examples inlined for quick reference. HTTP GET Example $jHeaderData = _JsonC_Object().add("Accept", "application/json") $jResp = $api.get('https://apichallenges.eviltester.com/simpleapi/items', $jHeaderData) HTTP DELETE Example $jResp = $api.delete("https://apichallenges.eviltester.com/simpleapi/items/" & $firstId) HTTP POST Example $jPostData = _JsonC_Object().add("type", "blu-ray").add("isbn13", $isbn).add("price", 97.99).add("numberinstock", 0) $jHeaderData = _JsonC_Object().add("Content-Type", "application/json") $jResp = $api.post('https://apichallenges.eviltester.com/simpleapi/items', $jPostData, $jHeaderData)

Major Update: AutoItObject Integration + Full Object/Array Enumeration Support I’ve pushed a significant update to the JsonC UDF on GitHub, introducing a new high‑level wrapper layer (JsonCEx.au3) built on AutoItObject. This update makes working with json‑c in AutoIt dramatically more natural, modern, and expressive. What’s new Full AutoItObject wrappers for JSON objects and arrays Dot‑notation access for child properties Native AutoIt For…In enumeration over JSON arrays Automatic reconstruction of nested objects/arrays via JsonC_FromHandle() Linked‑list backed array iteration (fast, predictable, and AutoIt‑friendly) Cleaner, modern API for building JSON structures New Example3.au3 demonstrating real‑world usage Example output from the new Example3.au3 The new example shows: Creating objects and arrays Nesting them Serializing to JSON Iterating arrays both standalone and when nested Accessing values with dot‑notation Using .at() for indexed access The script looks like: $jObject = JsonC_Object().add("demographic", "young adults") $jArrOfValues = _JsonC_Array().add("Paula").add("Cindy").add("Dorothy") $jArrOfObjects = _JsonC_Array() $jArrOfObjects.add(JsonC_Object().add("name", "Alice").add("age", 20).add("height", 175.8).add("isEmployed", True)) $jArrOfObjects.add(JsonC_Object().add("name", "Roger").add("age", 22).add("height", 165.3).add("isEmployed", False)) $jAllObjects = JsonC_Object().add("general", $jObject).add("person", $jArrOfValues).add("personDetails", $jArrOfObjects) $jstr = $jAllObjects.toString() For $oObject In $jArrOfObjects ConsoleWrite(" > name: value = " & $oObject.name.value() & ", type = " & $oObject.name.type() & ", age: value = " & $oObject.age.value() & ", type = " & $oObject.age.type() & ", height: value = " & $oObject.height.value() & ", type = " & $oObject.height.type() & ", isEmployed: value = " & $oObject.isEmployed.value() & ", type = " & $oObject.name.type() & @CRLF) Next For $oObject In $jAllObjects.personDetails ConsoleWrite(" > person name = " & $oObject.name.value() & @CRLF) Next $oGeneralDemographic = $jAllObjects.general.demographic.value() $oFirstPersonsName = $jAllObjects.personDetails.at(0).name.value() The output looks like: JSON data to string: > { "general": { "demographic": "young adults" }, "person": [ "Paula", "Cindy", "Dorothy" ], "personDetails": [ { "name": "Alice", "age": 20, "height": 175.80000000000001, "isEmployed": true }, { "name": "Roger", "age": 22, "height": 165.30000000000001, "isEmployed": false } ] } Iterate over the JSON array as a standalone object: > name: value = Alice, type = string, age: value = 20, type = int, height: value = 175.8, type = double, isEmployed: value = 1, type = string > name: value = Roger, type = string, age: value = 22, type = int, height: value = 165.3, type = double, isEmployed: value = 0, type = string Iterate over the JSON array as an object from the complete JSON: > person name = Alice > person name = Roger Extract the value of a child object: > general.demographic.value() = young adults Extract the value of an item from an array: > personDetails.at(0).name.value() = Alice The updated UDF, AutoItObject integration, and new example script are all available now on GitHub.