Custom Query
Results (142 - 144 of 3870)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#918 | Completed | GUICtrlSetFont() and related | Jpm | trancexx |
Description |
Would it be possible to get another parameter to functions GUICtrlSetFont() and GUISetFont() to be used to select font quality. Or maybe to add more values to attribute parameter? This appears to be most useful for XP. Here's the script that shows the difference (is seen on most of the XPs that I could test with - that's a lot actually): ;#NoTrayIcon #include <WinApi.au3> #include <WindowsConstants.au3> Opt('MustDeclareVars', 1) Global Const $DEFAULT_QUALITY = 0 Global Const $DRAFT_QUALITY = 1 Global Const $PROOF_QUALITY = 2 Global Const $NONANTIALIASED_QUALITY = 3 ; WINVER >= 0x0400 Global Const $ANTIALIASED_QUALITY = 4 ; WINVER >= 0x0400 Global Const $CLEARTYPE_QUALITY = 5 ; _WIN32_WINNT >= _WIN32_WINNT_WINXP Global Const $CLEARTYPE_COMPAT_QUALITY = 6 ; _WIN32_WINNT >= _WIN32_WINNT_WINXP Global $iToggled Global $sFontName = "Arial";"Trebuchet MS" Global $sText = "Environment = 3.3.0.0 under WIN_XP/Service Pack 3 X86" & @CRLF & @CRLF _ & "Pointer to a null-terminated string that specifies the typeface name of the font." & @CRLF _ & "The length of this string must not exceed 32 characters, including the terminating null character." & @CRLF _ & "...blah, blah, blah..." Global $hGui = GUICreate("My GUI") GUISetBkColor(0xFFFFFF) Global $hFont = _CreateFontWithDifferentQualityValue() Global $hButton = GUICtrlCreateButton("Change label font quality", 115, 300, 170, 25) Global $hLabelInfo = GUICtrlCreateLabel("- AutoIt font", 170, 350, 100, 25) GUICtrlSetColor($hLabelInfo, 0xFF0000) Global $hLabel = GUICtrlCreateLabel($sText, 110, 30, 180, 180) GUICtrlSetFont($hLabel, 8.5, 400, 2, $sFontName) GUISetState() While 1 Switch GUIGetMsg() Case - 3 ExitLoop Case $hButton _ToggleFont($hLabel, $hFont) EndSwitch WEnd ;cleaning If $hFont Then ConsoleWrite("! On exit delete custom font: " & _WinAPI_DeleteObject($hFont) & @CRLF) EndIf ; The end Func _ToggleFont($hControl, $hFont) If $iToggled Then GUICtrlSetFont($hControl, 8.5, 400, 2, $sFontName) GUICtrlSetData($hLabelInfo, "- AutoIt font") $iToggled = 0 Else GUICtrlSendMsg($hControl, $WM_SETFONT, $hFont, 1) GUICtrlSetData($hLabelInfo, "- custom font") $iToggled = 1 EndIf EndFunc ;==>_ToggleFont Func _CreateFontWithDifferentQualityValue() Local $tLOGFONT = DllStructCreate("int Height;" & _ "int Width;" & _ "int Escapement;" & _ "int Orientation;" & _ "int Weight;" & _ "ubyte Italic;" & _ "ubyte Underline;" & _ "ubyte Strikeout;" & _ "ubyte CharSet;" & _ "ubyte OutPrecision;" & _ "ubyte ClipPrecision;" & _ "ubyte Quality;" & _ "ubyte PitchAndFamily;" & _ "char FaceName[32]") Local $hDC = _WinAPI_GetDC($hGui) Local $LOGPIXELSY = 90 Local $iDCaps = _WinAPI_GetDeviceCaps($hDC, $LOGPIXELSY) _WinAPI_ReleaseDC($hGui, $hDC) DllStructSetData($tLOGFONT, "Height", -8.5 * $iDCaps / 72) DllStructSetData($tLOGFONT, "Weight", 400) DllStructSetData($tLOGFONT, "Italic", 1) DllStructSetData($tLOGFONT, "Quality", $CLEARTYPE_QUALITY) ; CLEARTYPE_QUALITY for example DllStructSetData($tLOGFONT, "FaceName", $sFontName) Local $hFont = _WinAPI_CreateFontIndirect($tLOGFONT) Return SetError(@error, 0, $hFont) EndFunc ;==>_CreateFontWithDifferentQualityValue
|
|||
#935 | No Bug | WinSetState() lags | trancexx | |
Description |
I tested this on various systems and the result is the same. This function lags for some reason. I read the documentation and couldn't find explanation for this strange behaviour. So, if someone would check if this is intended because it's really unexpected and kind of weird (probably there is some better word to describe it). I wrote a little script to demonstrate it. Did try to be as far away as I could from native functions made for making guis to eliminate possible shortcuts and still to be compact: Global $hGui = GUICreate("Test", 300, 300, 20, 100) GUICtrlCreateLabel("WinSetState functions:", 15, 70, 130) Global $hButtonShowWindow_AutoIt = GUICtrlCreateButton("ShowWindow", 20, 100, 100, 25) Global $hButtonHideWindow_AutoIt = GUICtrlCreateButton("HideWindow", 20, 150, 100, 25) GUICtrlCreateLabel("DllCall:", 190, 70, 130) Global $hButtonShowWindow_DllCall = GUICtrlCreateButton("ShowWindow", 170, 100, 100, 25) Global $hButtonHideWindow_DllCall = GUICtrlCreateButton("HideWindow", 170, 150, 100, 25) ;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Global $bDialog = "0x0100FFFF00000000000004004C0ACC80040000000000A2005F00000000004100" & _ "750074006F0049007400200049006E00700075007400200042006F0078000000" & _ "0800000000014D00530020005300680065006C006C00200044006C0067000000" & _ "0000000000000000000002500700070093002C00EA030000FFFF820050007200" & _ "6F006D0070007400000000000000000000000000800081500700380093000C00" & _ "E9030000FFFF8100000000000000000000000000010001501000490032000E00" & _ "01000000FFFF80004F004B000000000000000000000000000000015057004900" & _ "32000E0002000000FFFF8000430061006E00630065006C0000000000" Global $tDialog = DllStructCreate("byte[" & BinaryLen($bDialog) & "]") DllStructSetData($tDialog, 1, $bDialog) Global $aCall = DllCall("user32.dll", "hwnd", "CreateDialogIndirectParamW", _ "hwnd", 0, _ "ptr", DllStructGetPtr($tDialog), _ "hwnd", $hGui, _ "ptr", 0, _ "lparam", 0) Global $hDialog = $aCall[0] ;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX GUISetState() While 1 Switch GUIGetMsg() Case - 3 Exit Case $hButtonShowWindow_AutoIt WinSetState($hDialog, 0, @SW_SHOW) Case $hButtonShowWindow_DllCall DllCall("user32.dll", "int", "ShowWindow", "hwnd", $hDialog, "int", @SW_SHOW) Case $hButtonHideWindow_AutoIt WinSetState($hDialog, 0, @SW_HIDE) Case $hButtonHideWindow_DllCall DllCall("user32.dll", "int", "ShowWindow", "hwnd", $hDialog, "int", @SW_HIDE) EndSwitch WEnd I did manage to find out that WinSetState() eventually calls ShowWindow function the same way I did in that script and that the lag is likely with what comes after that. Thanks. |
|||
#1300 | Fixed | DllCall() unloads the loaded module | Valik | trancexx |
Description |
There is a possible situation with freeing loaded modules that are not initially loaded (load-time dynamic linking). Modules loaded only by call to LoadLibrary function -DllCall(), are unloaded unintentionally (user perspective) in some situations. Script demonstrates this behavior: Global $hWINHTTP = DllOpen("winhttp.dll") ; for example ConsoleWrite("Internal handle of the module: ") ConsoleWrite($hWINHTTP & @CRLF) ConsoleWrite("Real handle of the module: ") ConsoleWrite(_GetModuleHandle("winhttp.dll") & @CRLF) ; Calling the 'wrong' function will unload the module. Why? DllCall($hWINHTTP, "none", "Blahblah") ; There is no "Blahblah" function exported from winhttp.dll ; But there is no change with internal handle. That's ok for now. ConsoleWrite("Internal handle of the module: ") ConsoleWrite($hWINHTTP & @CRLF) ; Get real handle again. This time it will fail because AutoIt called FreeLibrary internally already. ConsoleWrite("Real handle of the module: ") ConsoleWrite(_GetModuleHandle("winhttp.dll") & @CRLF) ; will cause error because the module is unloaded ; Check internal handle again: ConsoleWrite("Internal handle of the module: ") ConsoleWrite($hWINHTTP & @CRLF) ; DllOpen again to check internal count of handles. This should be 1 because the module is unloaded by AutoIt internally, but it's 2 in this case. $hWINHTTP = DllOpen("winhttp.dll") ConsoleWrite("Internal handle after reopening the module: ") ConsoleWrite($hWINHTTP & @CRLF) ; it's increased by one, like there were no unloading happening Func _GetModuleHandle($sModule) Local $aCall = DllCall("kernel32.dll", "ptr", "GetModuleHandleW", "wstr", $sModule) If @error Or Not $aCall[0] Then Return SetError(1, 0, -1) ; just to show error EndIf Return $aCall[0] EndFunc ;==>_GetModuleHandle This is bad because effectively it disables us from declaring dll handles on global scope (as constant even more): ; Load module and get handle Global Const $hWINHTTP = DllOpen("winhttp.dll") ; Unload it unintentionally DllCall($hWINHTTP, "none", "Blahblah") ; comment this line out for script to work properly ; Call some function from that dll Global $aCall = DllCall($hWINHTTP, "int", "WinHttpCheckPlatform") ; http://msdn.microsoft.com/en-us/library/aa384089(VS.85).aspx ConsoleWrite("! WinHttpCheckPlatform @error = " & @error & @CRLF) ; will be 3 ConsoleWrite("WinHttpCheckPlatform return value = " & $aCall[0] & @CRLF) It's clearly intentional, therefore it's not a bug, but still it would be nice if someone could share some light on the matter. Is declaring dll handles on global scope ok, or is it more proper to open handle prior actual call (and close it afterwards), or maybe to call by string and DllOpen() it once at top of the script if necessary, or whatever? Thanks in advance. |