C / C++ / MFC

Ravi Bhavnani2-Aug-04 7:53

Ravi Bhavnani

2-Aug-04 7:53

The right (imho) approach to solving this common problem is to make the GUI an "observer" of the "worker" DLL. The worker notifies its observers of various "events" (typically progress) as it does its thing. The observer can choose to ignore these events or respond to them in any way it sees fit.

An "event" is anything that describes an action - it can be as simple as an int or as complex as a class containing several members such as event type, percentage progress, and other information describing the worker's current state.

An observer is nothing but an interface that exposes a method like:

bool handleEvent
 (Event* pEvent);

The observer returns false if it wants the worker to stop further processing. Using this simple design pattern, you could implement a user-friendly task timer/progress dialog as described in this[^] article. What could be cooler? Smile | :)

/ravi

My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com

palbano2-Aug-04 8:17

2-Aug-04 8:17

Isn't that somewhat re-inventing the wheel since the Win32 Progress Control already implements the pattern? Unsure | :~

"No matter where you go, there your are." - Buckaroo Banzai

-pete

Ravi Bhavnani2-Aug-04 8:33

Ravi Bhavnani

2-Aug-04 8:33

palbano wrote:
the Win32 Progress Control already implements the pattern?

Huh? Confused | :confused:

/ravi

My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com

palbano2-Aug-04 10:59

2-Aug-04 10:59

Ravi Bhavnani wrote:
Huh?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/common/refs.asp[^]

See the constant PROGRESS_CLASS Smile | :)

"No matter where you go, there your are." - Buckaroo Banzai

-pete

Ravi Bhavnani2-Aug-04 11:25

Ravi Bhavnani

2-Aug-04 11:25

I think you may have misunderstood my point.

It's good design to dissociate a worker (whether it's a thread or just a helper function) from the GUI. A worker simply relays information about its state to interested parties, at significant points in time.

The observer pattern abstracts the mechanism of event delivery. An observer can be anything - a GUI (i.e. a CView or CDialog class which will likely update a progress control), a logger (which could log events to a persistent store), an alterter (which could terminate the worker under certain conditions), a profiler (which instruments the worker's operation), etc. The observer/event mechanism I alluded to is OS-agnostic. It doesn't post Windows messages - it simply relays events.

/ravi

My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com

palbano2-Aug-04 11:44

2-Aug-04 11:44

Ravi Bhavnani wrote:
I think you may have misunderstood my point.

No, but i understand why it looks that way Smile | :)

I don't acutally disagree with your point.

It just seems that posting windows messages is the same as relaying events and the relationship between a progress control and a worker thread is very similar to the Pattern.

So i thought i would post the question and see what others thought about it. I am certainly not implying your post was wrong. I apologize if it looked that way.

Smile | :)

"No matter where you go, there your are." - Buckaroo Banzai

-pete

PJ Arends2-Aug-04 9:35

PJ Arends

2-Aug-04 9:35

http://www.codeproject.com/threads/usingworkerthreads.asp[^]

I think what Ravi had in mind was you placing a worker thread function in your DLL. Have that thread post progress messages back to your main GUI app. The main GUI app will update the progress bar.

"You're obviously a superstar." - Christian Graus about me - 12 Feb '03

"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04

Within you lies the power for good - Use it!

palbano2-Aug-04 11:03

Will the following code cause memory leakage?

2-Aug-04 11:03

PJ Arends wrote:
The main GUI app will update the progress bar.

By sending messages to it. Thus my question about re-inventing the wheel? Wink | ;)

So... lets dance! Jig | [Dance]

"No matter where you go, there your are." - Buckaroo Banzai

-pete

ting6682-Aug-04 5:50

ting668

2-Aug-04 5:50

LPWSTR a_string1 = _T("abcde");<br />
LPWSTR a_string2 = _T("fghij");<br />
a_string1 = a_string2;<br />

Will the string which is pointed by a_string1 become zombie and cause memory leakage?

Thanks

Nitron2-Aug-04 6:01

Nitron

2-Aug-04 6:01

No. When the string goes out of scope, it's memory will be free (99.9% sure).

~Nitron.

ññòòïðïðB A start

palbano2-Aug-04 6:01

2-Aug-04 6:01

No. String literals are not allocated on the heap.

"No matter where you go, there your are." - Buckaroo Banzai

-pete

vcplusplus2-Aug-04 6:04

vcplusplus

2-Aug-04 6:04

Run the program in Debug mode.
If there is a memory leak, it will be displayed in the output window.

palbano2-Aug-04 6:08

2-Aug-04 6:08

Can a string literal cause a leak? Confused | :confused:

"No matter where you go, there your are." - Buckaroo Banzai

-pete

wb2-Aug-04 6:19

2-Aug-04 6:19

of course, this CAN'T make a memory leak. the strings are alocated on the stac and cleared automaticly.

palbano2-Aug-04 7:43

2-Aug-04 7:43

thank you

Hopefully vcplusplus is reading Big Grin | :-D

"No matter where you go, there your are." - Buckaroo Banzai

-pete

ting6682-Aug-04 6:23

ting668

2-Aug-04 6:23

it is a dll
cannot be debug

anyway, i believe it will be cause memory leakage as the friendly guys who are replying me ^^.

Not always...

Navin2-Aug-04 6:50

Navin

2-Aug-04 6:50

Visual misses a lot of memory leaks.. especially if they are in a DLL loaded by the process being debugged.

An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.

Navin2-Aug-04 6:53

Navin

2-Aug-04 6:53

As written, it will not be a memory leak. String literals are more like constants - not dynamically allocated memory.

General rule: if you allocate memory with "new" (or "malloc" for old-school C code), and do not deallocate it with "delete" (or "free" for old-school C code), you will get a memory leak. Otherwise, the memory will be allocated on the stack and you won't get a memory leak.

There is an emperical way to try it... take the code you have written, and put it in an infinite loop. Do no optimisations. Run it for a while, and see if your memory usage slowly and gradually goes up in Task Manager. If it then goes back down when you quit the program, then you have a memory leak. Smile | :)

An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.

Downcasting?

0v3rloader2-Aug-04 5:35

0v3rloader

2-Aug-04 5:35

Hello,

I have some Edit controls layed out on a dialog, which are created automatically when the dialog loads up. Now I have a class which is derived from CEdit and I need to subclass it from the precreated Edit controls. I've tried subclassing them but all I got was message (AND NOT COMMAND) notification through DefWindowProc.

My question is: do I have to downcast it? And if so, how do I do that?

Re: Downcasting?

palbano2-Aug-04 5:58

Better Description of the Problem:

2-Aug-04 5:58

dNimrod#X wrote:
My question is: do I have to downcast it?

My guess would be no, that you have problems elsewhere. I am only guessing because i don't completely understand your post.

For instance:

dNimrod#X wrote:
which are created automatically when the dialog loads up

I don't know what you mean by that or this either:

dNimrod#X wrote:
I need to subclass it from the precreated Edit controls

"No matter where you go, there your are." - Buckaroo Banzai

-pete

0v3rloader2-Aug-04 6:13

0v3rloader

2-Aug-04 6:13

I have some CEdit controls layed out on a dialog template resource. They are created automatically when the dialog box is (dynamically) created.

What I need to do is force my CEdit-derived class to attach itself to the already created control(s).

Consider this:

class CMyEdit : public CEdit
{
protected:
	virtual LRESULT DefWindowProc(...);
	.
	:
	.
};

Example of implementation:

int CMyDialog::OnInitDialog()
{
	CMyEdit *pEdit;

	pEdit = new CMyEdit;
	pEdit -> SubclassDlgItem(IDC_VAL, this);	// not enough!
	.
	:
	.
}

Subclassing seems to not solve my problem because, although I still receive OnPaint, ... notifications, I can't seem to receive the EN_CHANGE command nor the WM_UNDO, to just name a few.

How do I do about solving this?

Re: Better Description of the Problem:

alex.barylski2-Aug-04 7:11

alex.barylski

2-Aug-04 7:11

If I understand your problem correctly, you won't need to downcast.

All you need to do in order for MFC to automatically subclass your edit control for you is:

1) Right click on edit control
2) Select class wizard
3) Click "Member variables" tab
4) Find control ID for edit control you wish to subclass
5) Double click on it
6) Under category pick control
7) fill in details as required and if your edit control isn't available and only a generic CEdit is displayed you can:

I believe remove your *.clw file and regenerate it when VC as you to selecting all your project files (including CEdit derived (h and cpp files).

OR

Go with a generic CEdit and later just modify it changing it to CPhoneEdit (or whatever)

Cheers Smile | :)

How do I print my voice mail?

Re: Better Description of the Problem:

palbano2-Aug-04 7:46