seangriffin

📢 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.

Hi everyone, After months of development, testing, and refinement, I’m excited to share something new with the AutoIt community: AutoIt CDP UDF A modern, high‑performance automation library for controlling Chromium‑based browsers directly through the Chrome DevTools Protocol (CDP) — with a clean, Playwright‑inspired API. This UDF communicates with the browser directly over WebSockets, with no WebDriver, no Selenium, no ChromeDriver, no Node.js, and no external dependencies. If you’ve ever used Playwright or Puppeteer, the API will feel instantly familiar — but now it’s native AutoIt. ⭐ Why CDP? Why this UDF? CDP gives you direct, low‑level control over Chromium. That means: No WebDriver overhead No Selenium flakiness No external processes No drivers to match versions No Python/Node/npm stack No installation required Just AutoIt + Chrome (CDP). This UDF aims to bring a modern, fluent, reliable automation experience to AutoIt — something closer to Playwright than to traditional WebDriver UDFs. 🔥 Key Features Direct CDP communication (no WebDriver, no Selenium) Playwright‑inspired API (locators, assertions, steps, test object) Extremely fast (no driver layer, no IPC overhead) Extremely lightweight (no external runtimes required) Auto‑waiting for elements and conditions (planned) Built‑in assertion system (expect()) Object‑driven, test‑aware scripting Event‑driven architecture Network request/response interception (planned) JavaScript evaluation (planned) Automatic browser download via Selenium Manager Portable, dependency‑free executables that run on any Windows machine Works with Chrome, Edge, Brave, Chromium — (currently only Chrome is fully supported) 🧪 Playwright‑Style Test Output Here’s a real output from the included “Basic Web Page” test: ▶ Test: Basic web page test ▶ Step: Verify Basic Web Page navigation ▶ Step: Navigate to evil tester test pages ▶ Step: Verify the main page ✓ Expect: expected [Software Testing Practice Pages, Apps, and Challenges] and got [Software Testing Practice Pages, Apps, and Challenges] (line 29) ✓ Expect: expected [Software Testing Practice Pages, Apps, and Challenges] and got [Software Testing Practice Pages, Apps, and Challenges] (line 31) ✓ Expect: object [-5136690175131552945.1.1] is hidden (line 32) ✓ Expect: expected [False] and got [False] (line 33) ✓ Expect: expected [True] and got [True] (line 34) ▶ Step: Verify navigation to Pages ✓ Expect: expected [Pages] and got [Pages] (line 39) ✓ Expect: object [-5136690175131552945.1.2] is visible (line 40) ✓ Expect: expected truthy and got [True] (line 41) ✓ Expect: expected falsy and got [False] (line 42) ▶ Step: Navigate to Pages ▶ Step: Verify navigation to Basics ✓ Expect: expected [Basics] and got [Basics] (line 50) ▶ Step: Navigate to Basic Web Page ▶ Step: Verify Basic Web Page ▶ Step: Page elements ✓ Expect: actual text contains [Elements] (line 63) ✓ Expect: expected [Tags: Elements Locators Categories: Basics] to contain [Elements] (line 64) ✓ Expect: expected [Tags: Elements Locators Categories: Basics] to match regex [.*Categor.*] (line 65) ✓ Expect: expected [A paragraph of text] and got [A paragraph of text] (line 66) ✓ Expect: expected [Another paragraph of text] and got [Another paragraph of text] (line 67) ▶ Step: Click Me functionality ✓ Expect: expected [You clicked the button!] and got [You clicked the button!] (line 72) ✓ Expect: expected defined value and got [defined] (line 73) ✓ Expect: expected length [23] and got [23] (line 74) ▶ Step: Verify invalid locator ✓ Expect: expected Null and got [Null] (line 80) > BasicWebPageWithStandardBrowser() took n ms. 📦 Included Examples The repo includes a full suite of example scripts: Basic Web Page test Headless mode Auto‑installed Chrome v119 Playwright Chromium Element attributes Multiple elements Basic inputs Number inputs API tests (HTTP GET, DELETE, POST) These examples demonstrate the API, locators, assertions, and CDP interactions. 📥 Download & GitHub Repository You can find the full source, examples, documentation, and comparison tables here: 👉 https://github.com/seanhaydongriffin/autoit-cdp-udf 🛠️ Requirements AutoIt v3.3.16.0+ AutoItObject UDF (already included) JsonC UDF (already included) Chrome with remote debugging enabled 🎉 Final Thoughts This UDF is still evolving — but it already provides a fast, modern, CDP‑native automation experience that AutoIt has never had before. If you’re interested in: modern browser automation Playwright‑style scripting CDP exploration building a new generation of AutoIt test tools …then I’d love your feedback and ideas.

I am very excited about the jq UDF now. It looks so fast. Thanks @TheXman. I'll definitely check it out.

I created this UDF for JSON using JSON-C because I needed high performance parsing of JSON data in my script. I needed to query large data arrays of several thousand entries and other UDFs were taking many seconds to do so. With this UDF a query of 5,000 array entries takes me about 600ms (see Example2.au3). This UDF executes JSON functions through a JSON-C DLL to achieve better performance. The JSON-C project is https://github.com/json-c/json-c. To download this UDF please visit https://github.com/seanhaydongriffin/JsonC-UDF. Two examples are provided (Example1.au3 and Example2.au3) that demonstrate all the functions.

Any reason for having $s_String as "ByRef" in _JSON_Parse ? I have a use case for minimal script, and wish to embed the JSON string directly in the _JSON_Parse such as $search = _JSON_Parse('{"name":"Sean"}') $s_Type = $search.name I took the "ByRef" keyword out of _JSON_Parse and seems to work?

A huge thank you InunoTaishou 💗 This is a very helpful example that I am adopting for use in a new Jira client. Your script is easy to read and follow with plenty of comments. The best example of working with RichEdit that I've found.