Sign in to follow this  
Followers 0
wraithdu

_MemGlobalAlloc() question

6 posts in this topic

Is memory allocated with _MemGlobalAlloc() freed automatically when the script closes, or must it be freed manually? I'm working on some clipboard things, and noticed that in the Clipboard.au3 UDF's, the memory is never freed. Is this a memory leak, or is it OK?

For example -

Func _ClipBoard_SetData($vData, $iFormat = 1)
    Local $tData, $hLock, $hMemory, $iSize

    Switch $iFormat
        Case $CF_TEXT, $CF_OEMTEXT
            $iSize = StringLen($vData) + 1
            $hMemory = _MemGlobalAlloc($iSize, $GHND)
            If $hMemory = 0 Then Return SetError(-1, 0, 0)
            $hLock = _MemGlobalLock($hMemory)
            If $hLock = 0 Then Return SetError(-2, 0, 0)
            $tData = DllStructCreate("char Text[" & $iSize & "]", $hLock)
            DllStructSetData($tData, "Text", $vData)
            _MemGlobalUnlock($hMemory)
        Case Else
        ; Assume all other formats are a pointer or a handle (until users tell me otherwise) :)
            $hMemory = $vData
    EndSwitch

    If Not _ClipBoard_Open(0) Then Return SetError(-5, 0, 0)
    If Not _ClipBoard_Empty() Then Return SetError(-6, 0, 0)
    If Not _ClipBoard_SetDataEx($hMemory, $iFormat) Then
        _ClipBoard_Close()
        Return SetError(-7, 0, 0)
    EndIf

    _ClipBoard_Close()
    Return $hMemory
EndFunc  ;==>_ClipBoard_SetData

Share this post


Link to post
Share on other sites



On MSDN it says that it's basically the same as allocating something on the local heap, so I would assume it is also freed?

Share this post


Link to post
Share on other sites

Well, when a process is closed all resources are automatically released by the system but that doesn't mean proper resource management should be ignored. In this case, you'll notice that the memory handle is returned so it's the callers (your) responsibility to free it. I don't think the code is leaking I just think it needs documented that you must free the memory yourself after you call the function.

Share this post


Link to post
Share on other sites

If the call was sucess ful, you mustn't free the Memory, because it's now owned by the ClipBoard. It's not yours anymore :)

If SetClipboardData succeeds, the system owns the object identified by the hMem parameter. The application may not write to or free the data once ownership has been transferred to the system, but it can lock and read from the data until the CloseClipboard function is called. (The memory must be unlocked before the Clipboard is closed.) If the hMem parameter identifies a memory object, the object must have been allocated using the function with the GMEM_MOVEABLE flag.


*GERMAN* [note: you are not allowed to remove author / modified info from my UDFs]My UDFs:[_SetImageBinaryToCtrl] [_TaskDialog] [AutoItObject] [Animated GIF (GDI+)] [ClipPut for Image] [FreeImage] [GDI32 UDFs] [GDIPlus Progressbar] [Hotkey-Selector] [Multiline Inputbox] [MySQL without ODBC] [RichEdit UDFs] [SpeechAPI Example] [WinHTTP]UDFs included in AutoIt: FTP_Ex (as FTPEx), _WinAPI_SetLayeredWindowAttributes

Share this post


Link to post
Share on other sites

Ah, very good (obviously I've never used the clipboard stuff).

Share this post


Link to post
Share on other sites

Thanks for finding that! Ok, so in my case if I make my own copy of the clipboard data and don't use it, then I must free the memory. If I later restore that copy back to the clipboard, then the memory is now owned by the clipboard and I do NOT have to free it.

Thanks again!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0