Custom Query (3926 matches)
Results (64 - 66 of 3926)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #3999 | Completed | _WinAPI_OemToChar - improved implementation | ||
| Description |
The current implementation of the function The following alternative implementation is now proposed instead: Func _WinAPI_OemToChar($sStr) ; input string Local $tIn = DllStructCreate("CHAR[" & StringLen($sStr) + 1 & "]") DllStructSetData($tIn, 1, $sStr) ; output buffer Local $tOut = DllStructCreate("CHAR[" & StringLen($sStr) + 1 & "]") Local $aCall = DllCall("user32.dll", "BOOL", "OemToCharA", "PTR", DllStructGetPtr($tIn), "PTR", DllStructGetPtr($tOut)) If @error Or Not $aCall[0] Then Return SetError(@error + 10, @extended, '') Return DllStructGetData($tOut, 1) EndFunc ;==>_WinAPI_OemToChar By manually creating the buffer in the correct size, memory wastage is prevented for small strings and multiple executions of DllCall are eliminated for large strings. This results in advantages over the previous implementation in terms of memory efficiency and performance without any recognizable disadvantages. The following script demonstrates a performance comparison of the two implementations: #include <WinAPIConv.au3> #include <String.au3> Global Const $aN = [1e1, 1e2, 1e3, 1e4, 1e5, 1e6, 1e7, 1e8] Global Const $iRUNS = 10 Global $iT, $iT1, $iT2 Global $sMeasureFormat = "%15.3f ms", $dFormLen = StringLen(StringFormat($sMeasureFormat, 0)) Global $sHeader = StringFormat("\n% 11s\t% " & $dFormLen & "s\t% " & $dFormLen & "s% 13s\n", "String size", "_WinAPI_OemToChar", "_WinAPI_OemToChar2", "Speedup") ConsoleWrite($sHeader & _StringRepeat("-", 64)) For $iN In $aN ; put some preparation stuff here Global $sString = _StringRepeat("ß", $iN) ConsoleWrite(StringFormat("\n% 11d", StringLen($sString))) ; the original _WinAPI_OemToChar() $iT = TimerInit() For $i = 1 To $iRUNS _WinAPI_OemToChar($sString) Next $iT1 = TimerDiff($iT) ConsoleWrite(StringFormat("\t" & $sMeasureFormat, $iT1 / $iRUNS)) ; the modified _WinAPI_OemToChar $iT = TimerInit() For $i = 1 To $iRUNS _WinAPI_OemToChar2($sString) Next $iT2 = TimerDiff($iT) ConsoleWrite(StringFormat("\t" & $sMeasureFormat, $iT2 / $iRUNS)) ConsoleWrite(StringFormat("\t%10.1f %%", (1 - $iT2 / $iT1) * 100)) Next ConsoleWrite(@CRLF & @CRLF) Func _WinAPI_OemToChar2($sStr) ; input string Local $tIn = DllStructCreate("CHAR[" & StringLen($sStr) + 1 & "]") DllStructSetData($tIn, 1, $sStr) ; output buffer Local $tOut = DllStructCreate("CHAR[" & StringLen($sStr) + 1 & "]") Local $aCall = DllCall("user32.dll", "BOOL", "OemToCharA", "PTR", DllStructGetPtr($tIn), "PTR", DllStructGetPtr($tOut)) If @error Or Not $aCall[0] Then Return SetError(@error + 10, @extended, '') Return DllStructGetData($tOut, 1) EndFunc ;==>_WinAPI_OemToChar |
|||
| #3997 | Completed | Improvement of _WinAPI_RegisterShellHookWindow example | ||
| Description |
Quote only Switch statement from the example: Local $sTitle = WinGetTitle($lParam) Switch $wParam Case $HSHELL_REDRAW If IsString($sTitle) Then ConsoleWrite('Redrawn: ' & $sTitle & @CRLF) EndIf Case Else If BitAND($wParam, $HSHELL_WINDOWACTIVATED) = $HSHELL_WINDOWACTIVATED And IsString($sTitle) Then ConsoleWrite('Activated: ' & $sTitle & @CRLF) ConsoleWrite(" $wParam: " & $wParam & @CRLF) EndIf EndSwitch The above case-else statement seems a bit misleading. Windows Hook Types are not for bit flag, just sequential integers. So BitAND($wParam, $HSHELL_WINDOWACTIVATED) matches not only HSHELL_WINDOWACTIVATED(4) but also HSHELL_GETMINRECT(5), HSHELL_APPCOMMAND(12), HSHELL_WINDOWREPLACED(13) and more. When I tried to run this example with SciTE, I got 'Activated' outputs twice if I clicked window minimize button. One for real activating and one for minimizing. In addition, IsString($sTitle) returns always True because WinGetTitle function returns a window title (on success) or "" (on failure). The below changes seems worked well for me. Case $HSHELL_WINDOWACTIVATED, $HSHELL_RUDEAPPACTIVATED |
|||
| #3996 | No Bug | Unexpected silent conversion of several AutoIt types when used as keys in maps | ||
| Description |
(this applies to all versions from 3.3.15.0 to 3.3.16.1) In maps, when we use a float, a pointer, or a keyword (any of default/null/true/false) as a key, then the following unexpected (i.e. this behaviour is undocumented) conversion happens:
What would be the most best, is to allow these additional sensible types to be used as keys. The additional sensible types are of course pointers/handles (i use them all the time when working with windows and GUIs as keys in a map; super useful!), floats, and (in my opinion) keywords. And at the very least, this should be documented in the helpfile. Thank you for consideration! :) PS. Well well well.. while researching this bug, i found even more unexpected things! the following snippet works perfectly fine in 3.3.15.0 and 3.3.15.1, but starting from 3.3.15.2 to 3.3.16.1 AutoIt completely crashes on it! Global $m[], $p1 = ptr(0xCAFE), $p2 = ptr(0xCAFEBABE) ConsoleWrite('setting Ptr('&$p1&') to 2357' & @CRLF) $m[$p1] = 2357 ConsoleWrite('retrieving: '&$m[$p1] & @CRLF) ConsoleWrite('setting Ptr('&$p2&') to 777' & @CRLF) $m[$p2] = 777 ConsoleWrite('retrieving: '&$m[$p2] & @CRLF) ConsoleWrite('-----now do the same, but via MapKeys in For..in..next loop---------' & @CRLF) for $key in MapKeys($m) ConsoleWrite('key '&VarGetType($key)&' : '& $key & @CRLF) ConsoleWrite('data '&VarGetType($m[$key]) &' : '& $m[$key] & @CRLF) next |
|||
