C / C++ / MFC

26-Jul-11 23:01

Hello
I have the following question.

I am new at MFC (I am using it with VC ++ 6.0).
I am trying to create a very simple window with a PushButton on it, supposed to activate a messagebox whenever it's clicked.
The wizard set the application with a MainFrame class, a View derived class, a Doc derived class (it's a SDI) and the usual App class.
On my behalf I added a simple CButton derived class.
This class has a constructor which receives the button's coordinates, calls the base constructor CButton () and then the Create () method on those coordinates.
I instantiate the button derived object on the InitInstance() method of the App derived class.
This object is a heap object , so I first declare a pointer and then call the contructor with some coordinates.
The pushbutton appears regularly, but when it comes to managing the BN_CLICKED event,things begin to get confusing.
I added the ON_BN_CLICKED () macro to the parent window's message map (which is the View class object), as MSDN suggests, and gave it my personal message handler's overload.
Well it seems that the BN_CLICKED event is never triggered : all I can detect is WM_LBUTTONDOWN
which I can manage, but the problem is, this event is triggered whenever I click on the window, no matter if I click on the button or not.
My question is : why does MSDN state that BN_CLICKED is triggered when a push button is clicked ? What can I do to get that event triggered and possibly managed ?

To avoid misunderstandings, I want to make it clear that I am NOT using a pushbutton in a Dialog , but right in a main window.

Thank you

Richard MacCutchan26-Jul-11 23:11

26-Jul-11 23:11

Have you set the button's parent CWnd to the same window that has the message map?

The best things in life are not things.

tiwal26-Jul-11 23:37

26-Jul-11 23:37

Yes Richard.
Though it wasn't clear at the beginning which one it was, since i had no pointer to the single objects , I figured out it was the MainFrame window object created by te wizard since it's the only one which seems to receive the WM_LBUTTONDOWN when I click the mouse.
I don't know if it is important but, peeking the system messages with Spy++, I couldn't see any BN_CLICKED , when instead I was seeing a lot of BM_SETSTATEs .

Richard MacCutchan26-Jul-11 23:43

26-Jul-11 23:43

You say its parent is the MainFrame but your message map entry is in your view; I suspect this may be wrong. Also note that BN_CLICKED[^] is a notification not a message, and gets sent to your application via a WM_COMMAND message.

The best things in life are not things.

tiwal26-Jul-11 23:56

26-Jul-11 23:56

This is something I am confused about : I see the only message I get is intercepted by the view object /message map but, inquiring the start of the application with the debugger, I came to the comclusion that the only window pointer that the wizard makes available in the application source is the MainFrame's one : I maybe wrong on this but I suspect it creates the CThread object for the current thread, then derives a CApp object from the Cthread class , and then it assignes the m_pMainWnd pointer of the CThread object to the CApp object , then assignes this one to the MainFrame's object.... following all thisnon the debugger is not the best so I could have misunderstod many things ....

I couldn't find any other window pointers related to the Doc, View , and user App objects.

Richard MacCutchan27-Jul-11 2:39

27-Jul-11 2:39

I suspect your problem may lie with where you created your button. From your earlier description of where you want to capture the button click, I think your button should be a child of (and created in) your CView class.

This is one of the issues with using a Wizard, it is not always as flexible as you need in special circumstances. You may also like to rethink the design of your application, particularly with regard to why you want this button. Could it be replaced by a simple toolbar button?

The best things in life are not things.

tiwal27-Jul-11 3:07

27-Jul-11 3:07

This idea slightly surfaced in my mind, but I had rapidly dismissed it on the basis of what I had understood (if well understood) about MCF : I was convinced that the only source code I should put my hands on was the xxxApp class , but ... is it right ? Maybe not .....

Anyway, I'll try to test this : I should redesign my application creating the Push Button in the OnDraw () message handler of the View class, I suppose : right ?

Well you know , this "application" I just made out of curiosity , to skill myself , so I should try to solve as many problems as I can without totally rethinking the architecture, which is already so simple.

Thank you

Richard MacCutchan27-Jul-11 3:19

27-Jul-11 3:19

tiwal wrote:
I was convinced that the only source code I should put my hands on was the xxxApp class

No, that's probably the one class that you won't need to change very much. The majority of actual work in your application will be done, first in the CDocument class, which handles the data that you are to process, and second in your CView class where your data will be presented to the user. Outside these two classes there is only a small bit of administration to link things together.

tiwal wrote:
creating the Push Button in the OnDraw () message handler of the View class

I don't think so! The OnDraw() handler should only be concerned with rendering your data onto the view for the user to read. If you need to have a button on your view then you should make it a member of your view class and create it in the OnCreate() function of the view class.

It is probably worth looking for some introductory MFC articles to get a feel for how these classes fit together, and what each should do during the life of the application.

The best things in life are not things.

tiwal27-Jul-11 3:23

27-Jul-11 3:23

You were right Richard ... now it works perfectly !!

So my mistake was in thinking that all I should modify was the CApp derived class.
Thank you for your precious support, you really dragged me out of a mud pond .....

Thumbs Up | :thumbsup:

greetings and regards,

Leo

Richard MacCutchan27-Jul-11 3:29

27-Jul-11 3:29

Happy to help; good luck in your efforts.

The best things in life are not things.

Re: Managing PushButton notifications under MFC [modified]

Madhu Nair26-Jul-11 23:35

Madhu Nair

26-Jul-11 23:35

Check your PUSHBUTTON is not disabled.For a BN_CLICKED message,
The parent window is notified through WM_COMMAND with control ID and handler.

wParam
The LOWORD contains the button's control identifier. The HIWORD specifies the notification code.

lParam
A handle to the button

tiwal26-Jul-11 23:46

How to compile a file using unicode charset

26-Jul-11 23:46

Following MSDN's instructions, I put the ON_BN_CLICKED() macro in the message map , like this:

ON_BN_CLICKED (IDC_MYBUTTON, OnClicked)

where IDC_MYBUTTON is the ID I give to the button when I create it, and OnClicked is the message handler I defined for the event, in the same file as the message map.
I tried to put this kind of event management everywhere in the project, but it never worked .

When you say "disabled" , what do you mean ? to be disabled,a push button must be created that way, right ?
Anyway if it were disabled, it wouldn't send the WM_LBUTTONDOWN message I guess, right ?

modified on Wednesday, July 27, 2011 6:03 AM

Cold_Fearing_Bird26-Jul-11 21:50

Cold_Fearing_Bird

26-Jul-11 21:50

I want to compile cpp files using unicode charset and functions( like lstrlenW ) in console window. But I don't know the option to turn on the UNICODE.
could someone help me?
cl.exe \U ???

Re: How to compile a file using unicode charset

Madhu Nair26-Jul-11 22:01

Madhu Nair

26-Jul-11 22:01

/D "_UNICODE" /D "UNICODE"

Delete doesn't ^delete^ a reference?

Dean Seo25-Jul-11 20:58

25-Jul-11 20:58

Hi,

I just found that the keyword Delete doesn't mean ^delete^ the way we(or maybe just I) normally think it does.

I thought if you delete a reference, the reference is deleted right after the delete and to have NULL value, which is not so true.

Let me show you an example.

--------------------------------------------
#include <iostream>
class test
{
public:
char ch;
~test() { printf("End!\n"); }
};

class test2
{
public:
char ch2;
~test2() { printf("End!\n"); }
};

int main()
{
test* callFunc = new test();
callFunc ->ch = 'a';

delete callFunc;

test2* callFunc2 = new test2();
printf("%p %p\n",(void*)callFunc,(void*)callFunc2);
callFunc2 -> ch2 = 'b';

printf("%c %c \n",callFunc ->ch ,callFunc2 -> ch2);
}

End!
0395BA8 0395BA8
b b
--------------------------------------------

From this result, I want to theorize that the keyword Delete is just to let the references that you delete be available to be pasted later.

I'd like to know if my idea is correct or if there are some other reasons for this?

Thanks in advance.

Richard MacCutchan25-Jul-11 21:24

25-Jul-11 21:24

This is one of the anomalies of delete in C++. When an object (or block of memory) is deleted then it is marked as free and may be re-used at some later time. However, the actual memory content, and any pointers to it, will not be physically cleared. If you had followed your delete statement with some other statement that needed to allocate memory, then it is likely that the program would have failed, as callFunc would (probably) be pointing at something that was not a test object.

When deleting objects you should always reset any pointers to NULL in order to protect yourself from any potential hazards.

The best things in life are not things.

Dean Seo26-Jul-11 14:11

26-Jul-11 14:11

Thanks. This helps me a lot.

image processing toolkits | batch image processing

C^hris L^osinger26-Jul-11 1:45

C^hris L^osinger

26-Jul-11 1:45

Dean Seo wrote:
if there are some other reasons for this?

a pointer to a block of allocated memory is not set to NULL when you delete that block of memory. you need to pay attention to that fact when deleting memory.

also, in C++ a pointer is not a reference.

int foo(int &a, int *b)
{
...
}

a is a reference. b is a pointer.

Dean Seo26-Jul-11 14:10

26-Jul-11 14:10

Thanks!

jschell26-Jul-11 9:48

jschell

26-Jul-11 9:48

Besides the above comments you might want to read up on what a 'heap' represents in computer science both conceptually and via implementations.

Dean Seo26-Jul-11 14:09

26-Jul-11 14:09

Thanks! I will.

Stefan_Lang27-Jul-11 3:00

Stefan_Lang

27-Jul-11 3:00

new does three things:
1. allocate memory from the heap
2. initialize the object at the resulting memory location
3. return a pointer to this new object.

What it does not do is set the value of your pointer variable - this is done by the assignment operator '='.

delete does the reverse, in reverse order:
1. take a pointer to an existing object
2. destruct the object
3. deallocate the memory it occupied

What it does not is reset the value of your pointer variable.

Technically it wouldn't be so hard to make delete also reset your pointer variable to 0, but since 'cleaning up' is often done at the end of a function or the end of the scope a pointer is defined in, it is usually not neccessary.

Nevertheless it is a good idea to always explicitely set a pointer to 0 after calling delete on it! Even if your delete is the very last line in your code, someone might later add code to that function, past that line.

That said, it might have been better if the C++ standard required the delete operator to also set the pointer to 0. But it doesn't. Of course, it is possible to overwrite delete, if you really want it that way... Wink | ;)