Custom Query

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

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.

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.