|
Richard MacCutchan wrote: Looking at your code (and I am far from being an expert on MFC) the only time that function will be called is via the TEXT_2 command. How does this command get invoked?
TEXT_2 this is not a command. Its just a Macro constant.
ON_COMMAND macro create a set of code that ensure the call of the function.
|
|
|
|
|
johny10151981 wrote: ON_COMMAND macro create a set of code that ensure the call of the function.
I guess you don't understand what the purpose of the ON_COMMAND macro is. Adding this to your program creates the code that will be called when the TEXT_2 command is invoked by the user. If you do not have any way of invoking the TEXT_2 command then this code will never run.
The best things in life are not things.
|
|
|
|
|
I dont get it..........
Since when
TEXT_2 is a command?
|
|
|
|
|
johny10151981 wrote: Since when
TEXT_2 is a command?
Since you put it in the ON_COMMAND macro.
Another example of an ON_COMMAND macro:
ON_COMMAND(ID_FILE_NEW, OnFileNew)
The ON_COMMAND macro in a message map is a way of telling the message mapper what to do with a WM_COMMAND windows message that has WPARAM=command id. In the case I wrote, wParam equals ID_FILE_NEW.
In the case you wrote, wParam equals TEXT2.
So, unless somewhere else in your code issues WM_COMMAND,wParam==TEXT2, your function will never get called. That other place could be window's menu handler, or the MFC code behind a toolbar, or a dialog button, or...
In another reply, you say TEXT2 is a macro. Do you mean:
#define TEXT2 1234
or something more complex?
Another problem you could be having is message routing. MFC does lots of work behind the scenes to give your objects the ability to response to commands. For example, CDocument never has a window, but it can respond to WM_COMMANDs.
Read this classic article from 1995. The re-read it. Then program a bit, then re-reread it. If you can't absorb it pretty well, you will struggle with MFC, and most windows programs. .Net may do things differently, but many of the principles are the same.
Meandering Through the Maze of MFC Message and Command Routing[^]
Don't forget to bookmark it!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Thanks for the link, I've been looking for a decent explanation of this for years!
The best things in life are not things.
|
|
|
|
|
It really is a great article. It opened my eyes to many possibilities for more self contained objects, and plug in architectures.
It greatly reduced spaghetti.
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Thank you for your reply and the link.
I guess I will get my answer in that link. As I have told, I didn't build that application using MFC Wizard. And I am not using any other class other than CWnd.
Thanks again
|
|
|
|
|
johny10151981 wrote: And I am not using any other class other than CWnd.
I'm finding it hard to believe you have a working MFC application then. MFC's message loop "live"s in CWinThread::Run member class. (CWinApp inherits from CWinApp).
And without a message map, you won't get a working application.
I suppose you could write a "raw" Win32 WinMain, and message pump yourself, and just use MFC's CWnd (and other CWnd based classes, like CEdit) as wrappers around a basic HWND windowa handle, but in that case you won't have any message mapping working, etc.
So, maybe that's the problem! You're not really using MFC!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
I am very much comfortable with win32 application(Non MFC). Even though i am not that experienced. Our Office using several win32 application developed by me(Mostly related with printing).
I am developing the same application that I have developed with PHP and MySQL. Though I am very good at php I dont like working with php. I am just trying to switch to Win32 Development.
So, all I am doing is improving myself(so far for no purpose).
Application is running. I am receiving notification from TreeControl.
If I would have developed this in plain C++ It would be finished 50% by this time. But developing in plain C/C++ has some disadvantages, Developing is slower than MFC. I have started with raw MFC, the reason is to make myself more clear about the behavior of MFC
|
|
|
|
|
johny10151981 wrote: I have started with raw MFC, the reason is to make myself more clear about the behavior of MFC
I must applaud you, it does sound like you have the right idea. You're probably fed up of reading text from me, so I'll try to be brief:
Look at the definition of ON_COMMAND etc, and you'll see they're just filling in a variable for MFC's command routing classes to use. Unless you use those classes, MFC message maps will do *nothing*.
Use the MFC appwizard to make a very simple application. Add a command handler. Put a breakpoint there, and then see just how much work MFC does for even a trivial menu command handler.
The meandering article does cover the evolution from
switch (iMsg)
{
case WM_COMMAND:
switch (LOWORD(wParam))
{
case ID_MY_COMMAND:
to message maps.
Good luck in your explorations!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Thank you all for your efforts,
I will try to figure out according to your suggestions.
|
|
|
|
|
Further to my other reply, Spy++ can help a bit, though it's hard with WM_COMMAND messages. So many other places in MFC use them.
Also, in the past I've put a breakpoint on a command message that does work, go up the stack to MFC's OnCommand handler, then put a conditional breakpoint with "wParam=1234" as the condition.
Iain.
ps, It might help if you told us how the TEXT2 command gets sent, and if you're sure it's WM_COMMAND message also. Maybe you're just not sending it correctly!
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Is there some child control that you're expecting to send WM_COMMAND notifications to your CInsertEdit? If not, then it's certainly not going to get called
*edit* Fixed speling
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: Is there some child control that you're expecting to send WM_COMMAND notifications to your CInsertEdit?
Of course
Well, if you think this way.....
there is more than one child control,
I didn't show them in example that is all.
In fact, The problem I am facing is not in the main window.
I am facing from child window. The Child window class is CInsertEdit. Its being created in another window(Main Application Window).
If it was simple Non MFC Application it was not a big deal for me. But I am confused with MFC
modified on Sunday, June 26, 2011 6:37 PM
|
|
|
|
|
MFC does a lot of custom processing of command messages. Depending on the type of controls generating the WM_COMMAND messages, you may need to use a more specific message map macro, for example ON_BN_CLICKED for button clicks.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I wish I can upload all code.
But I cannot,
First of all even though it is an MFC Application, but I didn't create it with application wizard. I am developing this application by hard coding. So, there is not many Message is being handled. There is few Message is already being handled by custom class window. But It is not processing WM_COMMAND or for MFC ON_COMMAND. Shall I have to do anything special on the mother window so that WM_COMMAND get transferred to child window? or from anywhere Shall I have to assign or define equivalent function of TranslateMessage or DispatchMessage??
|
|
|
|
|
Mark Salsbery wrote: Fixed speling
... and introduced a new 'spelling'
|
|
|
|
|
Here is the situation..
I wanted to do something like this
class B
{
private:
A *a;
public:
B(A *ta)
{
a=ta;
}
};
class A
{
int a;
B *b;
public:
A()
{
b=new B(this);
}
};
But it Seems Its not possible... or may I am missing any point...
Anyway, What I am trying to achieve is
I have Main Window class
class CInsertEdit:public CWnd
{
.....
}
class MainWnd:public CWnd
{
CInsertEdit *m_insertEdit;
public:
MainWnd()
{
Create(NULL,L"/\/\/\/\/\/");
.....
Check=m_pInsertEdit->Create(this,CRect(160,0,500,500), 1, WS_CHILD|WS_VISIBLE|WS_BORDER|WS_TABSTOP);
}
int ReEditTreeContol()
{
......
}
protected:
}
What I want is Call the ReEditTreeContol function after Hitting Save Button which is defined and created in CInsertEdit.
I cannot define a pointer in CInsertEdit class. What Can be done?
|
|
|
|
|
This looks more of a design issue. Why do you need a save button inside an edit class? It would be more sensible for the edit class only to be concerned with editing functions. Saving of your data should be done in your main window, which can get a pointer to the data to be saved from the edit class. If you have this sort of cross dependency in your classes then you need to re-think what each class's purpose is.
The best things in life are not things.
|
|
|
|
|
Hey,
Thank you for your reply.
In fact,
Its a set of Edit Control.
So I created a "CLASS"
That contains all required information
The design pattern is like this
From the Tree Control View User can select "New customer" option(on right mouse button a menu get popped up) or "Edit". In both case It will create the the Custom class. In the Custom class it has 4 edit control, one calender control, one combobox, 6 Static control and two buttons.
After Pressing the Save button first data will be saved to database(postgresql) and then it will send a message(now i am planning) (Custom Message) to Main Window. Then Main window will call the function that will recreate the treeview control. If i could create a variable of
class MainWindow it would not be a problem. anyway, i wish you can tell me a better solution
|
|
|
|
|
I still think your design is wrong, you are recursing between your classes, so you have MainWindow calls Edit calls MainWindow . That is just a recipe for disaster, or at the very least for headaches.
The best things in life are not things.
|
|
|
|
|
Its Not Recursion.
Even If I create the second object thousand time, i will only point the first object. it will not create.
Every time the design is like this...
--------------------------------------------
|....Main.Window...........................|
|...------------------------------------...|
|...|......Child.Window................|...|
|...|..................................|...|.....Child window is just holding mian windows pointer
|...------------------------------------...|
|..........................................|
--------------------------------------------
Everything would go wrong if I do this.
--------------------------------------------
|....Main.Window...........................|
|...------------------------------------...|
|...|......Child.Window................|...|
|...|...----------------------------...|...|
|...|...|..Main.Window.Again.......|...|...|
|...|...|..........................|...|...|
|...|...----------------------------...|...|
|...|..................................|...|
|...|..................................|...|
|...------------------------------------...|
|..........................................|
--------------------------------------------
|
|
|
|
|
Have you tried with a forward declaration?
class A; class B
{
private:
A *a;
public:
B(A *ta)
{
a=ta;
}
};
class A
{
int a;
B *b;
public:
A()
{
b=new B(this);
}
};
|
|
|
|
|
Wow,
It solved the problem
Here what i did
file: A.h
class B;
class A
{
int a;
B *b;
public:
A();
};
file A.cpp
#include "A.h"
#inlcude "B.h"
A::A()
{
{
b=new B(this);
}
}
file: B.h
class A;
class B
{
private:
A *a;
public:
B(A *ta)
};
file: B.h
#include "A.h"
#include "B.h"
B:B()
{
a=ta;
}
|
|
|
|
|
What you need is a 'Callback' mechanism, i. e. a way to tell your main window that something changed. The main point here is that whoever noticed or caused the change should not decide what to do about it - in this case call the ReEditTreeControl function.
You can implement a callback mechanism like this:
class IDocumentStateCallback {
public:
virtual void OnDocumentChanged()=0;
}
class MainWnd : public CWnd, IDocumentStateCallback {
private:
void OnDocumentChanged();
};
void MainWnd::OnDocumentChanged() {
ReEditTreeControl();
}
class CInsertEdit: public CWnd {
class IDocumentStateCallback* parent;
void OnSave();
};
#include "IDocumentStateCallback.h"
#include "InsertEdit.h"
void CInsertEdit::Create(CWnd* p, ) {
parent = dynamic_cast<IDocumentStateCallback*>(p);
}
void CInsertEdit::OnSave() {
p->OnDocumentChanged();
}
As you can see the callback mechanism prevents the cyclic dependency, since you now only refer to the interface class rather than the main window class. You can also easily add more kinds of state changes and implement the reaction to each change inside your main window class, rather than in any of the other dependent classes.
|
|
|
|