jchd

Using the above changes, run this: $s = "Большая проблема 大问题 बड़ी समस्या مشكلة كبيرة Test Title 😭" & @LF $s &= "Our familly " & ChrW(0xD83D) & ChrW(0xDC68) & ChrW(0xD83C) & ChrW(0xDFFB) & ChrW(0x200D) & ChrW(0xD83D) & ChrW(0xDC69) & ChrW(0xD83C) & ChrW(0xDFFF) & ChrW(0x200D) & ChrW(0xD83D) & ChrW(0xDC66) & ChrW(0xD83C) & ChrW(0xDFFD & @LF) CW($s) Result: Большая проблема 大问题 बड़ी समस्या مشكلة كبيرة Test Title 😭 Our familly 👨🏻‍👩🏿‍👦🏽

@Nine, I fixed that by 1) setting this In SciTeUserProperties: code.page=65001 output.code.page=65001 and using a good Unicode font: font.monospace=font:DejaVu Sans Mono,size:11 Then I use CW() instead of ConsoleWrite(): Func CW($s = "") If @Compiled Then _CUI_ConsoleWrite($s) Else _ConsoleWrite($s) EndIf EndFunc ;==>CW Func _CUI_ConsoleWrite(ByRef $s) Local Static $hDll = DllOpen("kernel32.dll") Local Static $hCon = __CUI_ConsoleInit($hDll) DllCall($hDll, "bool", "WriteConsoleW", "handle", $hCon, "wstr", $s & @LF, "dword", StringLen($s) + 1, "dword*", 0, "ptr", 0) Return EndFunc ;==>_CUI_ConsoleWrite ; internal use only Func __CUI_ConsoleInit(ByRef $hDll) DllCall($hDll, "bool", "AllocConsole") ;~ The following 2 lines don't work for compiled scripts due to a MS bug ;~ see last post in thread https://developercommunity.visualstudio.com/t/setconsoleoutputcpcp-utf8-results-in-code-page-850/413190 ;~ where MS support acknowledges it's a (still unfixed) bug in Windows itself ;~ So you can only display current locale codepage using current console font in a console when your script is compiled ;~ When running your script from SciTE, the UTF8 setting of SciTE overrides this bug and Unicode can be displayed ;~ DllCall("Kernel32.dll", "bool", "SetConsoleCP", "uint", 65001) ;~ DllCall("Kernel32.dll", "bool", "SetConsoleOutputCP", "uint", 65001) Return DllCall($hDll, "handle", "GetStdHandle", "int", -11)[0] EndFunc ;==>__CUI_ConsoleInit ; Unicode-aware ConsoleWrite Func _ConsoleWrite(ByRef $s) ConsoleWrite(BinaryToString(StringToBinary($s & @LF, 4), 1)) EndFunc ;==>_ConsoleWrite

FYI, on my system (Win10 x64 20h2) checking this setting has side effects: when I run a very simple piece of code from Scite, random strings are displayed in Scite console.

If you're certain that the format of your data is always a series of tokens enclosed in double quotes separated by columns, you can make it simple: Local $s = '{"Test":"test:test":"\"test:test\"":"Test:Test:Test":"Test"}' Local $t = StringRegExpReplace($s, '(?<!"):(?!")', '')

Ah yes, HH mod 12 is smarter.

You can also use a one-liner: Local $a = [" 12:0am", "12:12 AM", "2:3 aM", "11:59 am", "12:00 pm", "12:45pm ", "03:15 PM", "11:59 Pm"], $t For $s In $a $t = Execute((StringRegExpReplace($s, "(?i)(\d{1,2}):(\d{1,2})\h*([AP])M", "StringFormat('%02i', Mod(Execute('(( ((''$3'' & ''$1'' = ''A12'') OR (''$3'' = ''P'' AND ''$1'' < 12)) ? 12 : 0) + $1)'), 24)) & ':' & StringFormat('%02i', '$2')"))) ConsoleWrite($s & @TAB & $t & @LF) Next Beware that the OP code (even when fixed) gets 12 AM and 12 PM wrong!

Finally I found what was the culprit: a very old FF window which got shifted at the extreme corner of a desktop, making it essentially invisible. The only tab it carried was the one I was after in another tab of another FF window, but was set to a different part of the website. I confess having permanently 15-30 FF windows and many tabs each, all always open. Hard for me to do with much less. So everything works with the initial simple code and I flatly apologize for the noise and for wasting your time.

Oops, my bad, this works for finding all text or all edit controls. Now I guess all I need is find how to iterate within the edit array to find the relevant one(s). Digging in the UI threads...

Right, but still no! ; --- Find all edit controls --- ConsoleWrite("--- Find all edit controls ---" & @CRLF) $oUIAutomation.CreatePropertyCondition($UIA_ControlTypePropertyId, $UIA_EditControlTypeId, $pCondition) If Not $pCondition Then Return ConsoleWrite("$pCondition ERR" & @CRLF) ConsoleWrite("$pCondition OK" & @CRLF) Local $pEditAll, $oEditAll $oWindow.FindAll($TreeScope_Descendants, $pCondition, $pEditAll) $oEditAll = ObjCreateInterface($pEditAll, $sIID_IUIAutomationElement, $dtag_IUIAutomationElementArray) If Not IsObj($oEditAll) Then Return ConsoleWrite("$oEditAll ERR" & @CRLF) ConsoleWrite("$oEditAll OK" & @CRLF) $oEditAll ERR

I first thought I could go with a series of Send, but sending Tab to switch to the next edit applies to the menu and things break down. This page is nothing fancy: it's French post form to create packets shipment forms. I can't believe they use anything to protect against automation, since this would be contrary to their business!

There are a number of Text controls, but FindAll fails on them.

Also tried x64 code as FF is x64, but still no joy. .../... ; --- Find all edit controls --- ConsoleWrite("--- Find all edit controls ---" & @CRLF) $oUIAutomation.CreatePropertyCondition($UIA_ControlTypePropertyId, $UIA_EditControlTypeId, $pCondition) If Not $pCondition Then Return ConsoleWrite("$pCondition ERR" & @CRLF) ConsoleWrite("$pCondition OK" & @CRLF) Local $pEditAll, $oEditAll $oWindow.FindAll($TreeScope_Descendants, $pCondition, $pEditAll) $oEditAll = ObjCreateInterface($pEditAll, $sIID_IUIAutomationElement, $dtag_IUIAutomationElement) If Not IsObj($oEditAll) Then Return ConsoleWrite("$oEditAll ERR" & @CRLF) ConsoleWrite("$oEditAll OK" & @CRLF) Still error, whether parent is Window or Document: $oUIAutomation OK $oDesktop OK --- Find window --- $pCondition OK $oWindow OK --- Find document --- $pCondition OK $oDocument OK --- Find all edit controls --- $pCondition OK $oEditAll ERR Also tried $TreeScope_Children instead of $TreeScope_Descendants (I don't know if that should make a difference).

Old stock desktop Win10 version 22H2 x64, AutoIt v3.3.16.1 code running as x32, 16Gb RAM.

That's what I tried first, without success either. I tried to get to the first level Group under Document (which is found OK every time), but the group isn't found! Subsequent tries show that no Group (tried all having non-empty $UIA_AutomationIdPropertyId) below Document can be found. Searching from Windows also fails, but takes more time that from Document, unsurprisingly. Is the current UDF able to detect Group controls at all? Here's the ancestors tree from the first Edit I want to set data into:

Thanks, but do you have any idea why the Edit isn't found? The $UIA_AutomationIdPropertyId of that edit control is correct: addressFormDestPart.lastName