jchd

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.

wchar_t is not a valid type. Use wchar instead and test result of function calls.

For a more or less detailed history of timescales, see https://www.ucolick.org/~sla/leapsecs/timescales.html About timezones, rules, regions are changing so fast theat it's impossible in practice to be correct in the general case. Just for recent years: https://time.is/fr/time_zone_news

From the mid 70's the Acronym GMT doesn't have any precise scientific definition. Use UTC instead, including leap seconds!

Unicode codepoint 0x0275A (❚ HEAVY VERTICAL BAR) has no special effect on subsequent text. In other codepages, it's difficult to determine out of the blue what the character renderer will do.

The string supplied to Execute is AutoIt code, which is then executed. This is the way to execute dynamically created code.

Regex school: Local $text = FileRead(@ScriptDir & "\" & "source.txt") Local $hex = Execute('"' & StringRegExpReplace($text, '(?m)(?<=[[:xdigit:]]{5})([[:xdigit:]])(?=[[:xdigit:]]{2})', '" & _IncHex() & "') & '"') ConsoleWrite($hex) Func _IncHex() Local Static $Inc = 15 $Inc += 1 Return Hex(Mod($Inc, 16), 1) EndFunc I added two extra line in the source file, yielding: X0 00112033 X1 AABBC1DD X2 22446288 X3 BBDDF300 X4 11335477 X5 AACCE5FF X6 11AA26BB X7 CC33D744 X8 55EE68FF X9 ABCD9988 X10 8800AADD X11 EEFF3B44 X12 6622ACEE X13 5599CDFF X14 AAFF2E00 X15 0099AFCC X16 FD5A00B6 X17 10E51194

Never ever store a key, password, login, ... in clear in a program. Store a strong hash of the value, let user enter value, compute its hash and compare hashes.

After 18 years, all of them are dead or alike.

I don't know why. It would take to dig inside the source code to find the answer, or maybe ask on their support forum (if any). None of the win64 versions installs correctly here.

Post edited: I did see the * -1 part (and didn't expect it), just the > 0 caught my (olding) eyes.

@Deye you got the comparison wrong: if a match is found, the index of the found array element is returned, which is >= 0, else no match returns -1, which as you know is < 0. EDIT: sorry I looked too fast, focussing on the > 0 only. My bad.

Read the documentation about these two functions.