jchd

If you dump the object you get, you can see it isn't an array: Object Name: SWbemObjectSet Description: A collection of Classes or Instances Associated file: C:\Windows\SysWOW64\wbem\wbemdisp.TLB Owner/marshaller: C:\WINDOWS\system32\wbem\wbemdisp.dll CLSID: {04B83D61-21AE-11D2-8B33-00600806D9B6} InterfaceID: {76A6415F-CB41-11D1-8B02-00600806D9B6} From AutoIt point of view, this is a flat variable, so UBound returns 0.

It was a thinko, not a bug.

Not confusing at all! Every AutoIt Is*() function tests the expression datatype and IsNumber is no exception. This works as well for Magritte's "La trahison des images", see https://en.wikipedia.org/wiki/The_Treachery_of_Images.

Sorry folks, I didn't realize this was an old version of the code I use daily now.

My fault: there was an extra $ there. CW is a function not a variable! $color = Chr(27) & '[31m' $CW($color & "some text" & @LF) Original post fixed. was correct!

Well, this is openning a can of worms! Nowhere in the AutoIt specification of flags is mentionnend whether more than one occurence of a given flag is permitted or acted upon: is "%+++123.0f" the same as "%+123.0f". Seems easy to check in a few cases, but still without clear spec, we can't rely on that being innocuous. We do have a hint that more than one distinct flag is supported (albeit ignored) : If 0 and - appear, the 0 is ignored. the blank is ignored if both the blank and + flags appear. To provide a partial answer we need to test all combinations of flags. From "" to "-+*0#" (where * stands for a 0x20 whitespace for clarirty). Below is some code to do that and reveal that many flags combinations are not supported: ; There are 5 flag specifiers: '-', '+', '0', ' ', '#' in the StringFormat specification. ; If one assumes that a given flag may only appear once in the flags specification ; and given that more than one flag may be specified, the total numbers of flag strings ; is the power set of the set of flag specifiers. There are therefore 2^5 flag strings to ; test. ; This also assumes that the order of flags in a given flag string is irrelevant. ; ; It is easy to build that power set using binary mapping. Local $aFlags = ['-', '+', '0', ' ', '#'] Local $aFlagComb[2^5][2] Local $aComb2 For $i = 0 To 2^5 - 1 $aComb2 = StringSplit(StringFormat("%05s", _IntToString($i, 2)), "", $STR_NOCOUNT) For $j = 0 To 4 $aFlagComb[$i][0] &= ($aComb2[$j] = 1 ? $aFlags[$j] : "") Next Next For $i = 0 To UBound($aFlagComb) - 1 $aFlagComb[$i][1] = StringFormat("%" & $aFlagComb[$i][0] & "10.0f", 123) $aFlagComb[$i][0] = StringReplace($aFlagComb[$i][0], " ", "*") Next _ArrayDisplay($aFlagComb) Func _IntToString($i, $base = 16) Return DllCall("msvcrt.dll", "wstr:cdecl", "_i64tow", "int64", $i, "wstr", "", "int", $base)[0] EndFunc ;==>_IntToString It is also unclear whether the order of individual flags matter inside a given input. To fully answer this new question, one would need to create new entries in $FlagComb where the length of the flag string is > 1, split that string in individual characters and add new entries made from ArrayPermute. If you're cautious, also create new entries to cope with duplicate flags in various position(s) inside the flags strings to see if ever some rule emerges. Making a long answer short: both AI answers are incorrect. (My) conclusion: never trust a pile on unknown hardware fed with social networks toilet noises.

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.