C / C++ / MFC

David Crow24-Apr-12 6:04

David Crow

24-Apr-12 6:04

JohnCz wrote:
WM_CTLCOLORBTN does not work for buttons, since it draws face and borders.

So MSDN's "The parent window can change the button's text and background colors" statement is wrong?

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous

JohnCz24-Apr-12 7:42

24-Apr-12 7:42

This is out of context. Can you send me a link to the full statement?

JohnCz

enhzflep24-Apr-12 8:13

enhzflep

24-Apr-12 8:13

Here[^]

JohnCz24-Apr-12 10:55

24-Apr-12 10:55

MSDN states also (below the line you have quoted):

"By default, the DefWindowProc function selects the default system colors for the button. Buttons with the BS_PUSHBUTTON, BS_DEFPUSHBUTTON, or BS_PUSHLIKE styles do not use the returned brush. Buttons with these styles are always drawn with the default system colors. Drawing push buttons requires several different brushes-face, highlight, and shadow-but the WM_CTLCOLORBTN message allows only one brush to be returned. To provide a custom appearance for push buttons, use an owner-drawn button. For more information, see Creating Owner-Drawn Controls."

This is also incorrect, as you can see from the sample code at the bottom.
Radio and check boxes use static background color. If you change styles to "push like" color of the face will also not change. As you can see parent window is not able to change button’s face color of the pushbutton.

In conclusion, MSDN is incorrect (not the first time).

JohnCz

002comp24-Apr-12 20:31

24-Apr-12 20:31

Hello

I used CButon class to create button and then i override the DrawItem in Window class.
But its not Coming on Drawitem,where I am updating the color of Button.

Thanks

002comp24-Apr-12 21:34

24-Apr-12 21:34

Hey Friends
i got something That is working but need some help from you.
Here is the way.I created a new class CColorButton inherit from CButton.
And override functions paint and draw to set color.

But when I am attaching my ButtonId to object of CCOlorbutton,it is giving some assertion.

I am trying like this

CColorbutton* pBtn = new CColorButton();
pBtn->Attach(GetDlgItemId( IDC_BUTTON_ID + ndx )->GetSafeHwnd());

Regards
Yogesh

JohnCz25-Apr-12 0:31

25-Apr-12 0:31

yogeshs,
I think you are confusing two things: Windows window with MFC object that is not a window.
MFC object encapsulates window handle and only after window handle is valid, such an object represent Windows window. There are three ways to make MFC object alive (assign a valid handle):

Calling member function Create for a given class
Calling Attach
Subclassing window

Only calling Create and Subclassing will allow MFC object handling messages of the attached window.
Calling Attach will not allow process any messages processing, since window procedure has not been replaced by the object’s window procedure.

You should post a snippet that shows a function where it assert. Your code snippet does not make much sense since the meaning of the GetDlgItemId is unknown. Regardless, it looks like you are trying to attach an object that is already alive, meaning Windows window has MFC object attached to it. MFC code does it for you.

Please answer one question that I have already asked: What version of Visual Studio you are using? Maybe taking it from here will be more beneficial for you.

JohnCz

002comp25-Apr-12 3:05

25-Apr-12 3:05

I am using Vs2008 professional.

Thanks For Your Reply.
Trying To Understand.

Thanks
Yogesh

JohnCz25-Apr-12 3:47

25-Apr-12 3:47

OK, that is good so far. If you have SP1 installed, why not to follow my previous advice (from my earlier response):

If you are using VS 2008 with feature pack or with SP1 use CMFCButton class. To set button face color, call SetFaceColor member. You have to set m_bTransparent to FALSE anf disable teaming by calling EnableWindowsTheming member and passing FALSE as parameter.

This is much easier than reinventing a wheel.

JohnCz

002comp25-Apr-12 7:51

25-Apr-12 7:51

Hello JohnCz
I tried to use CMFCButton but there is no class in VS2008 prof.
Do i need to link up something?

Thanks Again.
Regards
Yogesh

David Crow25-Apr-12 8:09

David Crow

25-Apr-12 8:09

yogeshs wrote:
I tried to use CMFCButton...

How? When you added a button to the dialog template and went to assign a variable to it, the Add Member Variable Wizard defaulted to CButton. All you need to do is change that to CMFCButton. The appropriate header file (i.e., afxbutton.h) would have been added automatically, if it was not already included.

JohnCz26-Apr-12 2:28

26-Apr-12 2:28

Hi yogeshs,
You have to learn how to be patient and read all answers and documentation without skipping some parts.
I have already mentioned twice:

If you are using VS 2008 with feature pack or with SP1 use CMFCButton class.
You need Visual Studio SP1 installed.

Web installer[^]

ISO image[^]

Than you can subclass button using CMFCCustButton.
Subclassing is easy if you use wizard:
Right click on the button in the resource editor and choose Add Variable.
The only option you have is CButton, so select it.
After wizard closes, open dialog’s header file and change CButton to CMFCMenuButton.

JohnCz

David Crow25-Apr-12 2:39

David Crow

25-Apr-12 2:39

yogeshs wrote:
CColorbutton* pBtn = new CColorButton();
pBtn->Attach(GetDlgItemId( IDC_BUTTON_ID + ndx )->GetSafeHwnd());

It's highly unlikely that you would need to do this. Why not just replace CButton with CColorbutton in your dialog's .h file?

002comp25-Apr-12 7:55

Reference return vs Pointer return

25-Apr-12 7:55

Hello david
I didnt get your point.

Regards
Yogesh

Aragtey24-Apr-12 0:05

Aragtey

24-Apr-12 0:05

Hi all,

i was just wondering if what are the advantages/disadvantages of a reference return vs a pointer return?

Suppose if we have a large vector of objects in terms of performance there is any difference between returning a pointer to a object or the object reference.

Thanks

CPallini24-Apr-12 0:56

CPallini

24-Apr-12 0:56

What do you mean with 'reference' return?
Usually you obtain 'out' parameters as arguments passed by reference.
Moreover, there is no performance penalty in passing values by reference.

Veni, vidi, vici.

enhzflep24-Apr-12 1:10

enhzflep

24-Apr-12 1:10

In terms of performance, they're identical.

In practise, references mean you can use the . operator instead of the -> operator to access member functions/variables.

While there are a considerable number of differences between the two (look into operator overloading - it relies on references), I've just concentrated on the difference as it relates to your question.

[EDIT:] What CPallini said, above.

Aescleal24-Apr-12 1:55

Aescleal

24-Apr-12 1:55

There are loads of different rules you can apply here...

- Are you writing a member operator? Return *this by reference

- Are you writing a non-member operator? Return by value and either do your damnedest to trigger NRVO/RVO or write a move constructor in C++11

- Are you transferring ownership of something? Return a std::unique_ptr

- Do you want to read something that legitimately might or might not exist? Use a const pointer using 0 as an error value

- Do you want to read something that should exist and if it doesn't then the whole program's sunk? Return a const reference and throw if something goes wrong

- Are you returning a writable address or a reference to one or more of an object's data members? You are insane, please report to the funny farm

- Do you want to return a reference to an object to an automatic variable? See previous answer for details.

One thing to remember though is that sometimes you'll want to do something that's a bit unusual and you'll have to do something unusual to implement it.

Cheers,

Ash

Aragtey24-Apr-12 5:37

Aragtey

24-Apr-12 5:37

Thanks for all the answers.

Giving an example:

C++

vector<int> my_vec;

int* get_int(int positon) {
   int* value = my_vec.at[position]
   return value;
}

int& get_int(int positon) {

   return my_vec.at[position];
}

So both cases will avoid a copy of the object and will be fast them passing by value but besides that what are the differences.

References cant be null so probably returning by reference will have to assure that case, but im more concern in vantages of one side to the other (if there are any).

Thanks

Aescleal24-Apr-12 6:31

Aescleal

24-Apr-12 6:31

In both those case I'd return a value, not a reference or pointer. Unless you want to directly modify what's in the vector in which case you'd just use operator[].

Basically return by value first, if that's not what you want use pointers when failure isn't critical, references otherwise.

Cheers,

Ash

Aragtey24-Apr-12 6:36

Aragtey

24-Apr-12 6:36

The example is for a vector<int> and in this case its better returning by value, but in cases where we have a vector<my_object> and the object class is big its better returning a reference or a pointer. Just would like to know in those cases which one is better?

Thanks