Custom Query
Results (4 - 6 of 3866)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #4001 | Fixed | $tagNMITEMACTIVATE is used with wrong parameter names in many examples | Jpm | YuTang |
| Description |
Link:https://www.autoitscript.com/autoit3/files/beta/autoit/docs/libfunctions/$tagNMITEMACTIVATE.htm Quote Syntax: Global Const $tagNMITEMACTIVATE = $tagNMHDR & ";int Index;int SubItem;int NewState;int OldState;" & _ "int Changed;int X;int Y;int lParam;int KeyFlags" The above syntax clearly stated "X" and "Y" for its coordinates. But many ListView examples refer them as "ActionX" and "ActionY". A few of them listed below: Link:https://www.autoitscript.com/autoit3/files/beta/autoit/docs/libfunctions/_GUICtrlListView_Create.htm Link:https://www.autoitscript.com/autoit3/files/beta/autoit/docs/libfunctions/_GUICtrlListView_HitTest.htm Link:https://www.autoitscript.com/autoit3/files/beta/autoit/docs/libfunctions/_GUICtrlListView_GetEditControl.htm |
|||
| #3999 | Completed | _WinAPI_OemToChar - improved implementation | Jpm | AspirinJunkie |
| Description |
The current implementation of the function _WinAPI_OemToChar() uses "str" as the string parameters for DllCall() as the data type for the strings. This means that the size of the buffer for the output string is fixed at 65536 characters. With small strings, this leads to unused memory and large strings no longer fit into the buffer. The second problem was solved in the current implementation by splitting the input string into pieces of 65536 characters, processing them individually and then reassembling them. 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 | Jpm | YuTang |
| 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 |
|||
