Leaderboard

Here is SciTE Editor in full Mica: It obviously needs some new icons for other color modes. But we can color the entire SciTE window in any color possible. I used the SciTE dark theme from @ioa747 and modified it a bit to ensure that any background part was #000000 for full effect.

I use something like this in SMF internally, not tested on other processes. #include <GUIConstantsEx.au3> #include <WinAPISysWin.au3> #include <WindowsConstants.au3> Local $hGUI = GUICreate("Example", 400, 400) GUISetState(@SW_SHOW, $hGUI) Sleep(1000) __WinAPI_Set_Window_Style($hGUI, $WS_SIZEBOX, True, False) Sleep(5000) __WinAPI_Set_Window_Style($hGUI, $WS_SIZEBOX, False, False) Sleep(1000) __WinAPI_Set_Window_Style($hGUI, $WS_EX_TOOLWINDOW, True, True) Sleep(5000) __WinAPI_Set_Window_Style($hGUI, $WS_EX_TOOLWINDOW, False, True) While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd Func __WinAPI_Set_Window_Style($hWnd, $i_Style, $b_Add, $b_exStyle = False) If $b_exStyle = False Then Local $i_Style_Old = _WinAPI_GetWindowLong($hWnd, $GWL_STYLE) Else Local $i_Style_Old = _WinAPI_GetWindowLong($hWnd, $GWL_EXSTYLE) EndIf If $b_Add Then ; Style already applied If BitAND($i_Style_Old, $i_Style) Then Return Else ; Style not set If Not BitAND($i_Style_Old, $i_Style) Then Return EndIf If $b_exStyle = False Then If $b_Add Then _WinAPI_SetWindowLong($hWnd, $GWL_STYLE, BitOR($i_Style_Old, $i_Style)) Else _WinAPI_SetWindowLong($hWnd, $GWL_STYLE, BitXOR($i_Style_Old, $i_Style)) EndIf Else If $b_Add Then _WinAPI_SetWindowLong($hWnd, $GWL_EXSTYLE, BitOR($i_Style_Old, $i_Style)) Else _WinAPI_SetWindowLong($hWnd, $GWL_EXSTYLE, BitXOR($i_Style_Old, $i_Style)) EndIf EndIf _WinAPI_SetWindowPos($hWnd, $HWND_TOP, 0, 0, 0, 0, BitOR($SWP_FRAMECHANGED, $SWP_NOACTIVATE, $SWP_NOMOVE, $SWP_NOSIZE)) EndFunc ;==>__WinAPI_Set_Window_Style

Hi @jchd As you master RegEx & StringFormat, could you please have a look at these 2 answers just made by ChatGPT ? Thanks 1st question to ChatGPT Hello, please have a look at this regular expression ^([LRClrc]|[0-9]|%[\-+0\x20#]?\d*(?:\.\d+)?[diouxXeEfgGs])$ Is the third part of the alternation fully compatible with the AutoIt StringFormat function ? 1st answer from GPT-4o mini The regular expression you provided is designed to match specific patterns, and the third part of the alternation is: %[\-+0\x20#]?\d*(?:\.\d+)?[diouxXeEfgGs] This part is intended to match format specifiers similar to those used in C-style string formatting functions, which is also relevant for the AutoIt StringFormat function. Breakdown of the Third Part: %: Indicates the start of a format specifier. [\-+0\x20#]?: Matches an optional flag character: -: Left-justify the output. +: Forces to include a sign for numeric types. 0: Pads the output with zeros instead of spaces. \x20: Represents a space character. #: Used for alternate form (e.g., for o, x, X). \d*: Matches an optional width specifier, which can be one or more digits. (?:\.\d+)?: Matches an optional precision specifier, which starts with a dot followed by one or more digits. [diouxXeEfgGs]: Matches the conversion specifier, which can be: d: Decimal integer. i: Integer. o: Octal. u: Unsigned decimal. x: Hexadecimal (lowercase). X: Hexadecimal (uppercase). e: Scientific notation (lowercase). E: Scientific notation (uppercase). f: Floating-point. g: General format (lowercase). G: General format (uppercase). s: String. Compatibility with AutoIt StringFormat: The AutoIt StringFormat function uses a similar syntax for format specifiers. The format specifiers in your regex are compatible with AutoIt, as it supports: Numeric types (d, i, u, o, x, X, e, E, f, g, G). Flags (-, +, 0, #). Width and precision specifiers. Conclusion: Yes, the third part of the alternation in your regular expression is fully compatible with the AutoIt StringFormat function. It correctly captures the format specifiers that AutoIt can interpret for string formatting. 2nd question to ChatGPT Hello, in the preceding regular expression [\-+0\x20#]? corresponds to the optional flag character of the AutoIt StringFormat function. Is it correct to use "?" as the repeating character (0 or 1 time) or should we use "*" as the repeating character (0 or more times) to make it fully compatible with the C-style string formatting functions ? 2nd answer from GPT-4o mini In the context of the AutoIt StringFormat function and C-style string formatting functions, the use of ? for the optional flag character is correct. The ? quantifier means that the preceding element (in this case, the character class [\-+0\x20#]) can appear either 0 or 1 time, which is appropriate for optional flags. Using * instead of ? would mean that the flag characters could appear 0 or more times, which is not correct for format specifiers in C-style formatting. In these formats, the flags are typically limited to a single occurrence (or none), so ? is the appropriate choice. Summary The third part of the regular expression is compatible with AutoIt StringFormat. Using ? for the optional flag character is correct, as flags should appear 0 or 1 time, not 0 or more times. ============================================== So jchd, could you please confirm that the optional flag should appear only once in the AutoIt StringFormat function ? Because in AutoIt help file (topic StringFormat function) we can read this kind of sentence in the optional flag section... "If 0 and - appear, the 0 is ignored" "the blank is ignored if both the blank and + flags appear" ...which seems to indicate that several characters are possible as flags ? Do we have useful cases where several characters are really needed in the optional flag section ? ^([LRClrc]|[0-9]|%[\-+0\x20#]?\d*(?:\.\d+)?[diouxXeEfgGs])$ For the record, this Regex pattern is related to @ioa747 thread _StringToTable() as we're working on it, allowing the user to have the possibility to indicate not only [LRClrc] or [0-9] but also a valid StringFormat expression (starting with %) . The final tests look great, fingers crossed. Thanks for reading and have a great evening

(albeit ignored) is important in your answer, because indicating these 2 flags at same time will output same as if only 1 flag had been picked up. Your code is instructive as _ArrayDisplay shows the result of the 32 possible cases (combination of any number of elements in an ensemble composed of 5 elements => 31+1 possibilities) What we notice is that only 8 combinations (out of 32) display correctly the number 123 1 = no flag at all +5 = each flag picked up separately (123. is ok when # is applied to 123 with a "f" type, help file) +1 = "-0" flags ("If 0 and - appear, the 0 is ignored", help file) +1 = "+0" flags (sign is correctly displayed and 0's are correctly added) We note that "+-" or "-+" don't work (align to left and show sign) Also "0+10" doesn't work while "+010" works, same for "0#10x" which doesn't work while #010x" works (previous post) These tests push me to keep the ? quantifier, which seems easier to manage than the * quantifier (no need of a complementary test to make sure that a flag is not duplicated, no need to test that 2 'incompatible' flags will create an issue, for example "+-") then the flags class could stay like this... [\-+0\x20#]? ...and the final pattern for ioa747 script could stay unchanged : ^([LRClrc]|[0-9]|%[\-+0\x20#]?\d*(?:\.\d+)?[diouxXeEfgGs])$ We note that the valid input combination "+0" will be treated like this: "+" will be captured from the flags class then "0" will be captured from the \d* token. And well... if an issue should appear with this pattern, then it will be time to reopen this discussion Thanks jchd for your help

2025-May-18, Changelog v17 > v18 Updated - Ported SMF to x64 Info - Some DLLs like 7Zip, TRiD and some hashes only work in the x86 version Fixed - Long-standing startup bug be gone (hopefully) Updated - Improved visual experience of report, it now runs much more smoothly Updated - Implemented @UEZ's excellent WEBP UDF for icons and thumbnails Info - WEBP now preferred image format (good compression and supports transparency) Updated - Report icons and thumbnails now cached by default (as WEBP) Updated - Added encryption for cached thumbnails and icons Updated - Lots of other small bug fixes and style changes Source and Executable are available at https://funk.eu Best Regards Updated first Post... Enjoy ...

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.

Related to this thread, this is the 1st time I use ChatGPT, here are the question & answer My question : Hello, I don't understand. One hour ago, I asked you if the AutoIt RegExp ^([+\-]?(?:\d*\.\d+|\d+\.?))$ could match a numeric input .5 and you answered "No it doesnt" . A few minutes ago, I asked you the same question and you answered "Yes it does" . Why did you change your answer ? Answer from GPT-4o mini The confusion likely stems from the interpretation of the regular expression and the specific input being evaluated. The regular expression ^([+\-]?(?:\d*\.\d+|\d+\.?))$ is designed to match numeric inputs, including integers and decimal numbers. Here's a breakdown of the regex: ^ asserts the start of the string. [+\-]? allows for an optional sign (either '+' or '-'). (?:\d*\.\d+|\d+\.?) is a non-capturing group that matches either: \d*\.\d+: zero or more digits followed by a decimal point and one or more digits (e.g., .5, 1.5, 0.5). \d+\.?: one or more digits followed optionally by a decimal point (e.g., 5, 5., 10). Given this breakdown, the input .5 should indeed match the regex, as it fits the pattern of zero digits before the decimal point followed by one or more digits after it. If I initially stated that it does not match, that was incorrect. The correct answer is that .5 does match the regex. I apologize for the inconsistency in my responses. Thank you for your understanding!