hbr=CreateSolidBrush(RGB(255,200,200));
来改变界面底色，但在调试时提示：
Resource leak: allocated by CreateSolidBrush in D:\Programe\ProgrameView.cpp (247), HANDLE: 0x27104081
而且每次调OnCtlColor都会导致程序占用内存增加，最后出现异常，程序界面无法正常显示，这时怎么回事？
7 个解决方案
#1
OnCtlColor 会被多次调用。
创建画刷 最好在构造函数，或是初始化函数里做。在析构函数里进行 释放
创建画刷 最好在构造函数，或是初始化函数里做。在析构函数里进行 释放
#2
使用全局变量或成员变量来保存 Brush ，不用每次都创建，在Destroy窗口的时候 DeleteObject 就行了。
#3
When you no longer need the brush, call the DeleteObject function to delete it.
(in MSDN)
在onctrlcolor的最后删除它啊。
(in MSDN)
在onctrlcolor的最后删除它啊。
#4
在初始化时创建一个保存在类里面，OnCtlColor中直接返回类中的对象句柄就可以，销毁窗口的时候删除对象。
#5
像这一句，我在CreateMutex(NULL,TRUE,"NoRepeat")后接下来就DeleteObject(hmutex)，为什么还有：
Resource leak: allocated by CreateMutexA in D:\Programming\TestPrograme\TestPrograme.cpp (62), HANDLE: 0x00000724
并且出现：
Invalid argument
DeleteObject, argument 1, HGDIOBJ: 0x00000724
hmutex=CreateMutex(NULL,TRUE,"NoRepeat");
if(GetLastError()==ERROR_ALREADY_EXISTS){
::MessageBox(NULL,"程序已经运行","提示",MB_OK);
return FALSE;
}
DeleteObject(hmutex);
Resource leak: allocated by CreateMutexA in D:\Programming\TestPrograme\TestPrograme.cpp (62), HANDLE: 0x00000724
并且出现：
Invalid argument
DeleteObject, argument 1, HGDIOBJ: 0x00000724
hmutex=CreateMutex(NULL,TRUE,"NoRepeat");
if(GetLastError()==ERROR_ALREADY_EXISTS){
::MessageBox(NULL,"程序已经运行","提示",MB_OK);
return FALSE;
}
DeleteObject(hmutex);
#6
用ReleaseMutex(hmutex)
然后CloseHandle(hmutex)
然后CloseHandle(hmutex)
#7
多用msdn哦。
The handle returned by CreateMutex has MUTEX_ALL_ACCESS access to the new mutex object and can be used in any function that requires a handle to a mutex object.
Any thread of the calling process can specify the mutex-object handle in a call to one of the wait functions. The single-object wait functions return when the state of the specified object is signaled. The multiple-object wait functions can be instructed to return either when any one or when all of the specified objects are signaled. When a wait function returns, the waiting thread is released to continue its execution.
The state of a mutex object is signaled when no thread owns it. The creating thread can use the bInitialOwner flag to request immediate ownership of the mutex. Otherwise, a thread must use one of the wait functions to request ownership. When the mutex's state is signaled, one waiting thread is granted ownership, the mutex's state changes to nonsignaled, and the wait function returns. Only one thread can own a mutex at any given time. The owning thread uses the ReleaseMutex function to release its ownership.
The thread that owns a mutex can specify the same mutex in repeated wait function calls without blocking its execution. Typically, the thread would not wait repeatedly for the same mutex, but this mechanism prevents a thread from deadlocking itself while waiting for a mutex that it already owns. However, to release its ownership, the thread must call ReleaseMutex once for each time that the mutex satisfied a wait.
Two or more processes can call CreateMutex to create the same named mutex. The first process actually creates the mutex, and subsequent processes open a handle to the existing mutex. This enables multiple processes to get handles of the same mutex, while relieving you of the responsibility of ensuring that the creating process is started first. When using this technique, set the bInitialOwner flag to FALSE; otherwise, it can be difficult to be certain which process has initial ownership.
Multiple processes can have handles of the same mutex object, enabling use of the object for interprocess synchronization. To provide object sharing, a process can specify the name of a mutex object in a call to the CreateMutex function.
Use the CloseHandle function to close the handle. The system closes the handle automatically when the process terminates. The mutex object is destroyed when its last handle has been closed.
The handle returned by CreateMutex has MUTEX_ALL_ACCESS access to the new mutex object and can be used in any function that requires a handle to a mutex object.
Any thread of the calling process can specify the mutex-object handle in a call to one of the wait functions. The single-object wait functions return when the state of the specified object is signaled. The multiple-object wait functions can be instructed to return either when any one or when all of the specified objects are signaled. When a wait function returns, the waiting thread is released to continue its execution.
The state of a mutex object is signaled when no thread owns it. The creating thread can use the bInitialOwner flag to request immediate ownership of the mutex. Otherwise, a thread must use one of the wait functions to request ownership. When the mutex's state is signaled, one waiting thread is granted ownership, the mutex's state changes to nonsignaled, and the wait function returns. Only one thread can own a mutex at any given time. The owning thread uses the ReleaseMutex function to release its ownership.
The thread that owns a mutex can specify the same mutex in repeated wait function calls without blocking its execution. Typically, the thread would not wait repeatedly for the same mutex, but this mechanism prevents a thread from deadlocking itself while waiting for a mutex that it already owns. However, to release its ownership, the thread must call ReleaseMutex once for each time that the mutex satisfied a wait.
Two or more processes can call CreateMutex to create the same named mutex. The first process actually creates the mutex, and subsequent processes open a handle to the existing mutex. This enables multiple processes to get handles of the same mutex, while relieving you of the responsibility of ensuring that the creating process is started first. When using this technique, set the bInitialOwner flag to FALSE; otherwise, it can be difficult to be certain which process has initial ownership.
Multiple processes can have handles of the same mutex object, enabling use of the object for interprocess synchronization. To provide object sharing, a process can specify the name of a mutex object in a call to the CreateMutex function.
Use the CloseHandle function to close the handle. The system closes the handle automatically when the process terminates. The mutex object is destroyed when its last handle has been closed.
#1
OnCtlColor 会被多次调用。
创建画刷 最好在构造函数，或是初始化函数里做。在析构函数里进行 释放
创建画刷 最好在构造函数，或是初始化函数里做。在析构函数里进行 释放
#2
使用全局变量或成员变量来保存 Brush ，不用每次都创建，在Destroy窗口的时候 DeleteObject 就行了。
#3
When you no longer need the brush, call the DeleteObject function to delete it.
(in MSDN)
在onctrlcolor的最后删除它啊。
(in MSDN)
在onctrlcolor的最后删除它啊。
#4
在初始化时创建一个保存在类里面，OnCtlColor中直接返回类中的对象句柄就可以，销毁窗口的时候删除对象。
#5
像这一句，我在CreateMutex(NULL,TRUE,"NoRepeat")后接下来就DeleteObject(hmutex)，为什么还有：
Resource leak: allocated by CreateMutexA in D:\Programming\TestPrograme\TestPrograme.cpp (62), HANDLE: 0x00000724
并且出现：
Invalid argument
DeleteObject, argument 1, HGDIOBJ: 0x00000724
hmutex=CreateMutex(NULL,TRUE,"NoRepeat");
if(GetLastError()==ERROR_ALREADY_EXISTS){
::MessageBox(NULL,"程序已经运行","提示",MB_OK);
return FALSE;
}
DeleteObject(hmutex);
Resource leak: allocated by CreateMutexA in D:\Programming\TestPrograme\TestPrograme.cpp (62), HANDLE: 0x00000724
并且出现：
Invalid argument
DeleteObject, argument 1, HGDIOBJ: 0x00000724
hmutex=CreateMutex(NULL,TRUE,"NoRepeat");
if(GetLastError()==ERROR_ALREADY_EXISTS){
::MessageBox(NULL,"程序已经运行","提示",MB_OK);
return FALSE;
}
DeleteObject(hmutex);
#6
用ReleaseMutex(hmutex)
然后CloseHandle(hmutex)
然后CloseHandle(hmutex)
#7
多用msdn哦。
The handle returned by CreateMutex has MUTEX_ALL_ACCESS access to the new mutex object and can be used in any function that requires a handle to a mutex object.
Any thread of the calling process can specify the mutex-object handle in a call to one of the wait functions. The single-object wait functions return when the state of the specified object is signaled. The multiple-object wait functions can be instructed to return either when any one or when all of the specified objects are signaled. When a wait function returns, the waiting thread is released to continue its execution.
The state of a mutex object is signaled when no thread owns it. The creating thread can use the bInitialOwner flag to request immediate ownership of the mutex. Otherwise, a thread must use one of the wait functions to request ownership. When the mutex's state is signaled, one waiting thread is granted ownership, the mutex's state changes to nonsignaled, and the wait function returns. Only one thread can own a mutex at any given time. The owning thread uses the ReleaseMutex function to release its ownership.
The thread that owns a mutex can specify the same mutex in repeated wait function calls without blocking its execution. Typically, the thread would not wait repeatedly for the same mutex, but this mechanism prevents a thread from deadlocking itself while waiting for a mutex that it already owns. However, to release its ownership, the thread must call ReleaseMutex once for each time that the mutex satisfied a wait.
Two or more processes can call CreateMutex to create the same named mutex. The first process actually creates the mutex, and subsequent processes open a handle to the existing mutex. This enables multiple processes to get handles of the same mutex, while relieving you of the responsibility of ensuring that the creating process is started first. When using this technique, set the bInitialOwner flag to FALSE; otherwise, it can be difficult to be certain which process has initial ownership.
Multiple processes can have handles of the same mutex object, enabling use of the object for interprocess synchronization. To provide object sharing, a process can specify the name of a mutex object in a call to the CreateMutex function.
Use the CloseHandle function to close the handle. The system closes the handle automatically when the process terminates. The mutex object is destroyed when its last handle has been closed.
The handle returned by CreateMutex has MUTEX_ALL_ACCESS access to the new mutex object and can be used in any function that requires a handle to a mutex object.
Any thread of the calling process can specify the mutex-object handle in a call to one of the wait functions. The single-object wait functions return when the state of the specified object is signaled. The multiple-object wait functions can be instructed to return either when any one or when all of the specified objects are signaled. When a wait function returns, the waiting thread is released to continue its execution.
The state of a mutex object is signaled when no thread owns it. The creating thread can use the bInitialOwner flag to request immediate ownership of the mutex. Otherwise, a thread must use one of the wait functions to request ownership. When the mutex's state is signaled, one waiting thread is granted ownership, the mutex's state changes to nonsignaled, and the wait function returns. Only one thread can own a mutex at any given time. The owning thread uses the ReleaseMutex function to release its ownership.
The thread that owns a mutex can specify the same mutex in repeated wait function calls without blocking its execution. Typically, the thread would not wait repeatedly for the same mutex, but this mechanism prevents a thread from deadlocking itself while waiting for a mutex that it already owns. However, to release its ownership, the thread must call ReleaseMutex once for each time that the mutex satisfied a wait.
Two or more processes can call CreateMutex to create the same named mutex. The first process actually creates the mutex, and subsequent processes open a handle to the existing mutex. This enables multiple processes to get handles of the same mutex, while relieving you of the responsibility of ensuring that the creating process is started first. When using this technique, set the bInitialOwner flag to FALSE; otherwise, it can be difficult to be certain which process has initial ownership.
Multiple processes can have handles of the same mutex object, enabling use of the object for interprocess synchronization. To provide object sharing, a process can specify the name of a mutex object in a call to the CreateMutex function.
Use the CloseHandle function to close the handle. The system closes the handle automatically when the process terminates. The mutex object is destroyed when its last handle has been closed.