|
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.
|
|
|
|
|
Hello Everyone. I'm new here to both codeproject.com and VC++. I'm running VC++ 6 on an XP system. I happen to own a version of c++ 6 so I installed it on my severely limited resource machine. My issue in my code is with SetTimer and the way the system processes the time expired notification. I think I have figured out through trial and lots of error that when the time has expired a message enters the message queue and the code gets to process it when Windows says so. Initially, I was under the impression that SetTimer was giving me a "code interrupt" kind of service when the time expired. I set up this WHILE(Time_Out_Flag == FALSE){} kinda thing in one particular scope and waited patiently for the OnTimer process to set the Time_Out_Flag to TRUE to escape from the WHILE loop--An event that ultimately would never happen (Ctl+Alt+Del got me control again).
My question is... Is there some way to poll a SetTimer event for timer expiry within my WHILE loop?
Thanks in advance,
John
|
|
|
|
|
You cannot use SetTimer for your purpose.
You must use the CreateWaitableTimer and SetWaitableTimer functions.
You can then poll the timer using the WaitForSingleObject function by specifying a timeout value.
|
|
|
|
|
Thank you. I'll better research on how to implement that for my purpose.
|
|
|
|
|
Member 8012013 wrote: I happen to own a version of c++ 6
I would suggest you dump it as soon as possible, and get a copy of Visual C++ Express[^]. It's free and contains support for the latest levels of C++. You can also look at the other Express products (C#, WebDeveloper) which may be of interest.
The best things in life are not things.
|
|
|
|