• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 574
  • Last Modified:

change brush color

OK, I have CBrush myBrush, then I put:
myBrush.CreateSolidBrush(RGB(100,200,10));
 Now, the problem is, how to change myBrush to another color. It popped up an error when I try to use CreateSolidBrush again on that object.?? Any clue. Thanks.
0
quanghoc
Asked:
quanghoc
  • 6
  • 5
1 Solution
 
fl0ydCommented:
You have to select it out of the current device context and call myBrush.DeleteObject before you can call myBrush.CreateSolidBrush(...) again.

A basic note: Posts like 'an error popped up' aren't really helpful if you don't tell us what error it was.
0
 
quanghocAuthor Commented:
The error was Debug assertion failed!
0
 
fl0ydCommented:
That's what I guessed -- but I'm sure it said more than just some debug assertion, right? I probably said that CBitmap::m_hObject != NULL
0
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

 
quanghocAuthor Commented:
yes, ASSERT(someobject==NULL) return false and that made the error. I found out when I choose "debug". So, what I don't understand is what actually wrong with it? Can someone explain?
0
 
fl0ydCommented:
ASSERT is there to help you. In general it follows this syntax:
ASSERT( some_condition )
if some_condition is false, this dialog comes up. It is there to give you runtime-diagnostics. It is there to check whether an assumption you made is correct. In the case of your CBrush it ensures that the object isn't attached to any GDI-object when you call any of the creation functions. This prohibits any memory leaks within your application's drawing functions.
Btw: You can put as many ASSERT's in your code as you like -- in the Release build they are not compiled into your executable. With this in mind, you should never change any variables or call functions that change them inside an ASSERT. If you need to call such functions use the VERIFY-macro instead.
0
 
quanghocAuthor Commented:
Okey, I kinda got that ASSERT is to check memory leaks, but how come doing myBrush.CreateSolidBrush(RGB(100,200,10)) twice is wrong?? And I already tried myBrush.DeleteObject, not work either.
0
 
fl0ydCommented:
No, ASSERT isn't to check for memory leaks but to make sure some condition that is crucial for your application is met. In the CBrush class it is used to prevent memory and resource leaks not to see if there are any.
To understand why applying CreateSolidBrush twice is wrong you have to understand what CBrush actually is. An object of class CBrush never contains a GDI brush -- all it does is control the way you interact with it. So if you call a creation function for the second time, the GDI object still exists -- I'm not sure, but a CBrush::Detach() could help after you called CBrush::DeleteObject(); I thought a DeleteObject() was enough though, noone is perfect...
Basically, my opinion is that using MFC without having a strong win32-background is making things more complicated than necessary. This usually becomes apparent when dealing with drawing routines, CDC's, CGdiObject's and the likes.
0
 
fl0ydCommented:
I just checked it: you don't need to call CBrush::Detach() -- it is called in CBrush::DeleteObject(). This means that you can call CreateSolidBrush() after calling DeleteObject() and there should be no error. You should check the return value of CBrush::DeleteObject() -- it can return FALSE. Also, make sure that the brush is *NOT* selected into any device context when calling DeleteObject() -- otherwise it will fail and not reset CBrush::m_hObject thus the
ASSERT( m_hObject == NULL )
will be false the second time you try to create a brush and the dialog will pop up.
0
 
quanghocAuthor Commented:
----------
make sure that the brush is *NOT* selected into any device context when calling DeleteObject() --
----------
sorry, what does it mean?
0
 
fl0ydCommented:
Somewhere in your code you have something like

CBrush* pOldBrush = static_cast<CBrush*>( cdc.SelectObject( &myBrush ) );

or maybe

CBrush* pOldBrush = (CBrush*)cdc.SelectObject( &myBrush );

This line of code selects the brush into the device context to make it available for drawing. As long as the brush is selected into the device context it cannot be deleted. So you have to call

cdc.SelectObject( pOldBrush );

before going on to delete your brush using

BOOL success = myBrush.DeleteObject();

This is a bit of inverse logic here: You cannot select a CGdiObject-derived object (CPen, CBrush, ...) out of a device context. However, at any given time there can only be ONE object of any type selected into the device context, thus if you select your old brush back into the device context, the currently used brush is deselected.

Don't get me wrong here, but I think you should definately do some reading on win32-/gdi-programming before going on using mfc. I'm not trying to discourage you, but from my own experience I know that it was pure luck, that my first mfc experiments did work at all. Once you have a somewhat solid understanding of the windows gdi you will find your way around those mfc-anomalies a lot more easily. Believe me, it is surely not all that complex as it presents itself to you at the moment.
0
 
griesshCommented:
Dear quanghoc

I think you forgot this question. I will ask Community Support to close it unless you finalize it within 7 days. You can always request to keep this question open. But remember, experts can only help you if you provide feedback to their questions.
Unless there is objection or further activity,  I will suggest to accept

     "fl0yd"

comment(s) as an answer.

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
======
Werner
0
 
quanghocAuthor Commented:
Sorry, actually, I got it worked. The reason this question has forgotten because there was a bug in this forum preventing me from submitting any response. Thanks all.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now