Custom Query (3931 matches)

This function causes a memory leak (GDI objects) in combination with STM_SETIMAGE or STM_SETICON messages send directly to the control. Seems this function destroys images assigned only by a previous call to itself (or those set when creating the control). If some image is set with GUICtrlSendMsg it won't be destroyed. I guess there is nothing wrong with that logic except it's, in described situation, setting new image without destroying the old one, therefore incrementing overall GDI Objects count only because it's not aware of the already assigned image. More proper would be to destroy previously assigned image regardless of how it's set.

This can be concluded by carefully(!) examining the effects of e.g. this code:

#include <WinAPI.au3>
#include <GUIConstantsEx.au3>
Opt('MustDeclareVars', 1)
Opt("GUIOnEventMode", 1)


Global $hIconNew, $hIconOld

Global $hGUI = GUICreate("GUICtrlCreateIcon")

GUISetOnEvent($GUI_EVENT_CLOSE, "_Quit")
Global $hIcoControl = GUICtrlCreateIcon("", "", 20, 75, 32, 32) ; no icon
GUISetState()




While 1

	$hIconNew = _GetIcon("shell32.dll", 8, 32)
	ConsoleWrite("$hIconNew = " & $hIconNew & @CRLF)
	;GUICtrlSendMsg($hIco, 368, $hIcon, 0) ; STM_SETICON version, or:
	$hIconOld = GUICtrlSendMsg($hIcoControl, 370, 1, $hIconNew) ; STM_SETIMAGE
	ConsoleWrite("$hOld = " & Ptr($hIconOld) & @CRLF)
	; _WinAPI_DestroyIcon($hIconOld) ; I can omit this because GUICtrlSetImage will do it for me on the next call

	Sleep(700)

	;_WinAPI_DestroyIcon(GUICtrlSendMsg($hIcoControl, 369, 0, 0)) ; STM_GETICON. Ommiting this on the other hand causes a leak
	; Btw, that's the same as:
	;_WinAPI_DestroyIcon($hIconNew)

	ConsoleWrite("Assigned icon before GUICtrlSetImage = " & Ptr(GUICtrlSendMsg($hIcoControl, 369, 0, 0)) & @CRLF) ; STM_GETICON
	ConsoleWrite("GUICtrlSetImage returns " & GUICtrlSetImage($hIcoControl, "shell32.dll", 5) & @CRLF)
	ConsoleWrite("Assigned icon after GUICtrlSetImage = " & Ptr(GUICtrlSendMsg($hIcoControl, 369, 0, 0)) & @CRLF) ; STM_GETICON

	ConsoleWrite(@CRLF)

	Sleep(700)

WEnd



Func _GetIcon($sModule, $iName, $iSize) ; for loaded modules
	Local $hModule = _WinAPI_GetModuleHandle($sModule)
	If @error Then Return SetError(1, 0, 0)
	Local $hIcon = _WinAPI_LoadImage($hModule, $iName, 1, $iSize, $iSize, 0) ; IMAGE_ICON, LR_DEFAULTCOLOR
	If @error Then Return SetError(2, 0, 0)
	Return $hIcon
EndFunc   ;==>_GetIcon

Func _Quit()
	Exit
EndFunc   ;==>_Quit

GDI Objects count can be monitored with task manager.

The following code should release the iTunes object so a dialog about scripting being in use by iTunes will not appear. However it does not seem the object is released properly as iTunes still complains.

Global $oiTunes=ObjCreate("iTunes.application")
ObjEvent($oiTunes,"_Event_")

While 1
	Sleep(100)
WEnd

Func _Event_OnAboutToPromptUserToQuitEvent()
	Global $oiTunes=0
EndFunc   ;==>_Event_OnAboutToPromptUserToQuitEvent

From the iTunes documentation

The ITEventAboutToPromptUserToQuit event is fired when iTunes is about prompt the user to quit.

This event gives clients the opportunity to prevent the warning dialog prompt from occurring.

If the user attempts to quit iTunes while a client still has outstanding iTunes COM objects instantiated, iTunes will display a warning dialog. This event is fired just before the warning dialog is shown. iTunes will then wait up to 5 seconds for clients to release any outstanding iTunes COM objects. If all objects are released during this time, the warning dialog will not be shown and iTunes will quit immediately.

Otherwise, the warning dialog will be shown. If the user chooses to quit iTunes anyway, the ITEventQuitting event is fired. See _IiTunesEvents::OnQuittingEvent() for more details.

AutoIt:3.3.6.1 Os:WIN_XP/X86/Service Pack 3 Language:0409 Keyboard:00000809 Cpu:X64 When DirCreate() is passed certain invalid paths, for example "C:xxx\zzz", it returns 1 indicating success even though no path has been created.

$Result = DirCreate("C:ZZZ\XXX")
MsgBox(0,"DirCreate", "DirCreate returned " & $Result)