jchd

Yes: you received a string of bytes (each UTF8 character is 1 to 4 bytes) which needs converting into UCS2 for AutoIt processing. No, it's a remnant of displaying the thing. My bad. In BinaryToString and StringToBinary, the part String refers to "native UCS2 AutoIt string", Binary refers to "string of bytes using this or that codepage". You may find clearer the code exemple found just before showing _StringToCodepage() and _CodepageToString() in that help text.

You are confusing two situations: 1) a string in an UTF8 source file: it will be decoded and stored as UCS2 in memory at runtime, then processed as UTF16-LE by OS primitives. 2) an UTF8 string stored in memory, possibly sent by or to be fed to an external process: this is a string of bytes, not UCS2 encoding units. To be correctly decoded and processed by OS string primitives and rendered, it needs to be converted to UCS2 and then seen as UTF16-LE. Alternatively, if you need to send a native AutoIt string to an external process requiring UTF8 data, then the conversion is applicable. I'm the author of this text in help and I'm not a native english speaker; if you find that some wording needs rework/clarification, just propose.

In the source file, the string "こんにちは" is UTF-8. At runime, the string is read and converted to UCS-2 for memory storage and use by Windows primitives. UCS-2 is the restriction of UTF16-LE to the first 64K codepoints aka BMP (but doesn't handle surrogates per se). Yet you can still compose a native AutoIt3 string having codepoints beyond U+FFFF by entering UTF8 sequences with surrogates embedded. The UTF16-LE Windows renderer will detect them and render the upper-planes codepoints, well provided the font chosen provides data for those codepoints. The caveat is that the couple surrogate+codepoint counts for 2 characters in AutoIt string functions. For instance, this is a string of Phoenician codepoints which can be rendered correctly using DejaVu or Segoe UI Historic fonts. You can see that the string is seen by AutoIt functions as 56 "characters", while it has only 28 codepoints (each with its surrogate). The Phoenician codepoint range is U+10900 - U+1091F. Local $s = "𐤐𐤁𐤕𐤃𐤈𐤊𐤂𐤒𐤀𐤖𐤚𐤛𐤎𐤆𐤑𐤔𐤇𐤏𐤄𐤗𐤘𐤙𐤌𐤍𐤅𐤓𐤋𐤉" _ArrayDisplay(StringToASCIIArray($s), "Length = " & StringLen($s))

For those who need an AU3-only solution for decoding entities: HTMLentities.au3

First, SQLite is a simple library, not a client-server design. SQLite can only proceed with ONE SQL transaction at any given time. Also SQLite locks the entire DB file, not a specific table or row. When SQLite detects a BUSY situation when transaction A enters execution (another SQL transaction B in being processed, plus possible other transactions C, D, ... in BUSY state as well) and a non-zero timeout is in place for A, it continues processing B and repeatedly checks if A, C, D, ... are still in BUSY state until their respective timeout value exipres or B terminates and clears the way for others. SQLite doesn't queue BUSY transactions waiting for clearance in a FIFO or like. It randomly selects one of the waiting transaction and gives it a chance to process. That means that with the previous enumeration, when B terminates, SQLite is free to randomly select D to run, then F, then C, then E, until it selects A. That's why I mean "the longest possible sequence of transactions issued by all users of the library", because you may be unlucky and have your thing clear to run way after what you'd expect. That's also why it should be forbiden to group in a single transaction something like: select for change a number of rows, wait for user to chose the ones they need change, take the lunch break, update some data and finish the transaction. Some client-server designs can cope with this but at the expense of serious internal complexity to deal with parallel updates. About autoincrement: you ever need this except if your application can't cope with duplicate use of rowid over time. Example without autoincrement: create table T (id integer primary key, name text); insert into T (name) values ('Alice'), ('Bob'), ('Charlie'), ('Dom'), ('Elon'); delete from T where name glob '*o*'; insert into T (name) values ('Eve'); You obtain: id name 1 Alice 3 Charlie 4 Eve Instead, with this: create table T (id integer primary key autoincrement, name text); insert into T (name) values ('Alice'), ('Bob'), ('Charlie'), ('Dom'), ('Elon'); delete from T where name glob '*o*'; insert into T (name) values ('Eve'); You get: id name 1 Alice 3 Charlie 6 Eve With autoincrement, once a given rowid has been used, you're sure it won't be reused ever. This a very rare use case and forces SQLite to maintain sqlite_sequence for this table.

I"ve currently very little free time yet I just had a quick look at the SQLite part. Setting PRAGMA busy_timeout = 2000; may be too short in practice. In multi-user context, this parameter should be way larger than the longest possible sequence of SQL statements transactions issued by the maximum concurent users, all of this as worst case. I can expand on this if needed. I set that to 10 minutes. Why do you make the IDs autoincrement? Don't, unless you really have a compelling reason to do so.

Didn't look further but the source of the include should show what the issue is

AutoIt functions can be passed either as string: TrayItemSetOnEvent($trayID_reload, "ReloadMenu") or as function: TrayItemSetOnEvent($trayID_reload, ReloadMenu) The latter form allows AutoIt to detect errors at check/compile time, rather than runtime. Local $stINFO = DllStructCreate("long;long;long;ptr;ptr;ptr;ptr;long;long;long;ptr;long;long;long;long") Local $stVerb = DllStructCreate("wchar[15];wchar") Local $stPath = DllStructCreate("wchar[255];wchar") Local $stArgs = DllStructCreate("wchar[255];wchar") Local $stWDir = DllStructCreate("wchar[255];wchar")

Never care about Defender hallucinations.

@TomTheGeek I only took a quick eye to your code. I have 3 remarks: 1) prefer pass function names as such instead as string. E.g. TrayItemSetOnEvent($trayID_reload, ReloadMenu) 2) shouldn't text arguments to ShellExecuteEx use wchar instead of char? Else, if e.g. a path contains Unicode characters outside current codepage, expect failure. 3) Beware of changing global variables locally. Func LaunchTask() Local $i = ...

Grab the content of the clipboard with ClipGet() or use _ClipBoard_GetData($CF_UNICODETEXT). Also if you insist on using _ClipBoard_GetDataEx, then also use $CF_UNICODETEXT and $data = DllStructCreate("wchar Text[8192]", $clipCF_TEXT) Else you're requesting Windows to convert the (native) Unicode text in the clipboard to the default 8-bit codepage, making "special" characters (as you name them) either emasculated or lost in translation.

As @Jos already told you, there is no such thing as "a3x files for AutoIt3_x64.exe". Any a3x file can be run as X86 by AutoIt3.exe or run as X64 by AutoIt3_x64.exe. Of course if the source code relies on X64 features, then the resulting a3x has to be run by AutoIt3_x64.exe.

SQLite v3.25.2 is dated 2018-09-25, so yes it's terribly outdated. Official current version of DLL (v3.47.2) and tools available from https://www.sqlite.org/download.html SQLite team takes backward compatibility very seriously, so I don't get what your problem is. A program working with v3.25.2 will surely work under v3.47.2 but won't make use of all the new features added/fixed in between. OTOH, a program coded for using the recent features may obviously fail to work with older versions of the DLL.

FYI, a pedestrian way using regex is also pretty fast: Local $s = FileRead("events.xml") Local $t = StringRegExpReplace($s, "(?is)(\s*<ComplexData .*?</ComplexData>)", "") ConsoleWrite($t & @LF)

True. The only way to get rid of all these unsolvable TZ+DST issues would be to use only UTC everywhere for all purposes. Of course it would need that almost all humans change their "clock" habits, and accept that their "normal" wake up time is no more e.g. 06:30 but 01:00 or 17:45 depending on where they are.