Visual C++ classes communicating with main window

Hi all, I am in need of a suggestion. My problem is a simple one, but it's long to explain. If you have a little time please read, it won't be a large brain-consuming problem.


My application has a dialog (single modal dialog box) with a lot of controls in it. For every button in the dialog, the application has to perform a different task (which is encapsulated into classes).

So for every task, a function allocate a C++ class like

Code:

---

Button1()
{

// Task 1
CClassTask1 *m_task1 = new CClassTask1(parameters..);

..


delete m_task1;

}

---

My problem is: These classes must log their activity with strings like

CClassTask1:

Code:

---

....

cout << "I am working, 43% of work done" << std::endl;

...

---

How to communicate back to main window? I'd prefer not using forward declarations because these classes may mess up something with the main window using MFC (while these classes do not)


I need something like

Trace("I am working, 43% of work done");

callable from classes, and that string must show in a edit box (log box) in the main window.


If I was not clear, please feel free to ask me to be more "understandable".

Thank you

This all looks like a single custom message is enough to be posted to main window. WPARAM or LPARAM may be just a percent number to show, and the text may be added by message handler itself..

Code:

---

UINT percentage = 43;
AfxGetMainWnd()->PostMessage(WM_MYPERCENTAGE, (WPARAM)percentage);

---

You mean using PostDlgMessage or something like that?

The window is MFC though

See above what I mean.

Uhm I see, but AfxGetMainWnd() requires MFC involved. The application uses mfc, but these classes do not. Some of them are even plain C incorporated into a C++ application. Don't know how they would react using such function in the code...

maybe with a majestic load of errors?

Okay, let's get rid of MFC:

Code:

---

UINT percentage = 43;
PostMessage(hwndMain, WM_MYPERCENTAGE, (WPARAM)percentage, 0);

---

Might be an idea... Can i pass an entire string with that right? Just a pointer..

No, it's not very good idea for PostMessage (the string may be deallocated before message being handled). Instead, it's better pass a string resource ID (of course if your strings are of fixed content) in LPARAM. Or go with SendMessage.

Okay, I think the string resource ID is not a good solution (too messy), maybe I'll go for the SendMessage. It is synchronous isn't it?

Quote:

---

string resource ID is not a good solution (too messy)

---

With gaining some experience people change their opinion about what "messy" is. :)

Quote:

---

SendMessage. It is synchronous isn't it?

---

Yes, it is.

I think using ResourceID's and PostMessage is a great idea.

That way when you find out you need to put the task work into separate threads (because the main thread keeps locking up), you won't have to change this part of the program.

I guess this is what Igor meant by "change their opinion about what 'messy' is".

Got it, but this time the application needs one task at time to be performed at full speed and cpu work

Anyway I suppose I'll use PostMessage and resource Ids.

By the way, if I can figure out how to include a public function like

"WriteOut(char *str)"

in every class to let them write in the log edit box of the main window, that would be great. Otherwise, your solution seems the best. Thank you.

Yes, Arjay, exactly. :)

Another disgusting thing, not very rare one, now about SendMessage: after next development cycle you discover it appears deadlocking due to last changes.

Quote:

---

Originally Posted by pm44xl22

Got it, but this time the application needs one task at time to be performed at full speed and cpu work.

---

Then you probably want to put the task into a thread. The reason being is if you let the task run inside the main thread, then the user can interrupt the task by simply doing a user task like moving the mouse. Most devs aren't aware of this, but moving the mouse creates hundreds of mouse messages being sent to the app and each one of these messages will get processed by the app - thus stealing time away from processing. On the other hand, if you put your task in a dedicated thread (and maybe bump up the thread priority a little bit) then the task is going to be able to run pretty much uniterrupted.

Quote:

---

Originally Posted by pm44xl22

in every class to let them write in the log edit box of the main window, that would be great. Otherwise, your solution seems the best. Thank you

---

You can create a singleton logger class that can be accessed anywhere inside your program. Along with the logging class, you can have a log listener that would listen for log messages (via a callback) and write the logs to the edit box. The syntax to call the logging class could be something like:

Code:

---

Logger.GetInstance().WriteOut( ... );

---