|
Well, one way is the following:
- Change Client class constructor to accept a Dialog class reference. Store the passed reference as member of Client class
- Make Dialog class public methods to allow access to relevant class data. (a brutal alternative to this step is declaring Client class friend of Dialog class).
For instance:
// Client
class Client
{
Dialog & m_dlg;
public:
Client( Dialog & dialog):m_dlg(dialog){}
...
}
class Dialog
{
public:
setLabelText(LPCTSTR szText)
{
...
}
...
}
and then, somewhere in your code:
Dialog dlg;
...
Client client(dlg);
...
and, finally, somewhere in Client code:
m_dlg.setLabelText(_T("packet received"));
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Yes, but Dialog needs Client too... They both need each other, and with the include guards that's not possible. And if I remove the include guards I get infinite error messages by the compiler... 
Any more ideas? Thanks!
Windows Calculator told me I will die at 28. 
|
|
|
|
|
You can do stuff like this...
<br />
class CClient;<br />
<br />
class CDialog<br />
{<br />
public:<br />
CDialog(CClient* pClient);<br />
private:<br />
CClient* m_pClient;<br />
};<br />
<br />
#include "Dialog.h"<br />
class CClient<br />
{<br />
<br />
CClient(CDialog& aDialog) : m_Dialog(aDialog)<br />
{<br />
}<br />
private:<br />
CDialog& m_Dialog<br />
};<br />
<br />
#include "Client.h"
CDialog::CDialog(CClient* pClient)<br />
{<br />
m_pClient = pClient;<br />
}<br />
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Matthew Faithfull wrote: You can do stuff like this...
Yeah I could also create a function that takes as a parameter a reference to a pointer to a pointer of a structure that contains a union that has a member that is a pointer to a pointer to a structure that contains a member that is a pointer to a function that takes as a parameter....
Not everything you can do is something you should do. Take a clue from best practices and principles of object oriented design and software design patterns. Or don't .... whatever, but try not to give bad advice to beginners that may still have a hope of becoming capable of creating something other than technical debt.
|
|
|
|
|
Or you could take your own advice
The technique I described of forward declaring a related class and using only the declaration in the header so that both classes can 'know' about each other is both standard, as in used everywhere, and extremely useful as in you're pretty stuffed wihtout it.
I don't know or care what the OPs objects do I only know about the interface he's given me, the question. by all means post a better solution, more appropriate to a beginner, easy to understand, more general, more useful and wiser in every way. I'd certainly suggest doing so before criticising the perfectly reasonable advice already posted or no one including the OP is likely to take any notice.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Matthew Faithfull wrote: by all means post a better solution
I already did before I replied to your post.
Matthew Faithfull wrote: Or you could take your own advice
If you were at all familiar with my posts you would not have made that statement. I am one of the few people on the site that attempt to introduce people to the benefits of object oriented design.
Matthew Faithfull wrote: I don't know or care what the OPs objects do
You really didn't need to say that, it was very clear from your original post.
I now return you to your regularly scheduled activity of manufacturing technical debt.
|
|
|
|
|
led mike wrote: I already did before I replied to your post.
 Strangely it seems to be absent form the forum.
led mike wrote: If you were at all familiar with my posts you would not have made that statement. I am one of the few people on the site that attempt to introduce people to the benefits of object oriented design.
That wasn't the part of your advice I was refering to. I'm sure your OOP skills are second to none and you frequently point people in the right direction.
led mike wrote: I now return you to your regularly scheduled activity of manufacturing technical debt.
 Don't assume I know less than you'd like me to just because we understand the OPs needs differently. I haven't manufactured any technical debt in years.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Matthew Faithfull wrote: Strangely it seems to be absent form the forum.
I can see it. I'm afraid to even try the Permalink feature on the "new and destroyed" version of CP! 
Matthew Faithfull wrote: I haven't manufactured any technical debt in years.
So you haven't developed any software in years? It's all but impossible to keep from creating technical debt when developing software. It's just a matter of degrees and managing risk in most cases.
Matthew Faithfull wrote: just because we understand the OPs needs differently.
Fair enough, I read the OP as being interested in the design aspects of his problem. It's very rare to see anyone posting something here that even hints at an interest in design issues.
|
|
|
|
|
led mike wrote: So you haven't developed any software in years?
Sometimes it feels like it on this project but no, I reckon I've removed as much technical debt as I've added certainly in the last few years, 2 working on a great product where it's easy enough to add code with an absolute minimum of the usual risks. Before that the previous product I worked on was so bad that pretty much every change I made removed more problems that it created.
Fair enough, I read the OP as being a C programmer doing nothing resembling actual OOP but wanting to use C++, to head in the right direction and needing a bridge from C to C++ thinking before diving in with patterns. I am quite familiar with the GOF and all their works. I've even posted a patterns article[^] which you're very welcome to shred if you so wish.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
IMHO there is nothig bad in his proposed solution.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Don't bother trying to convince me, just go right to someone like Kent Beck with your opinion.
|
|
|
|
|
led mike wrote: Don't bother trying to convince me
Oh, I don't need (and don't want) to do that.
I just expressed my own opinion (maybe ad (dis)advantage  of other people reading the thread)
led mike wrote: just go right to someone like Kent Beck with your opinion
Good designs depend on a lot of factors, the less important being authority.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: Good designs depend on a lot of factors, the less important being authority.
I see, so you are someone that is so accomplished at software development that you do not need to heed the advice of well established experts in the industry. Ok well good luck with that. Happy Holidays and all. 
|
|
|
|
|
led mike wrote: I see, so you are someone that is so accomplished at software development that you do not need to heed the advice of well established experts in the industry.
Of course I really need to heed their advice. This doesn't mean I'm not able to have an independent opinion.
led mike wrote: Ok well good luck with that
Thank you, I need it.
led mike wrote: Happy Holidays and all.
Happy Holidays to you!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Well, this is not a big problem.
For instance, you can use pointers instead of references and avoid including headers inside each other exploiting class deferred declaration:
#pragma once
class A;
class B
{
A * _pA;
public:
B(A * pA):_pA(pA){}
public:
~B(void){};
};
Note I've not included A.h in the class B header. Of course you have to include A.h inside B.cpp to do something useful with the _pA pointer, but this will be not a problem anymore.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Really, that's your advice? Are you kidding me!  
|
|
|
|
|
led mike wrote: Really, that's your advice?
Yes.
led mike wrote: Are you kidding me!
Why do you think that?
OK you're right, in my proposal there is (almost  ) no way to avoid the troublesome interdependency of the headers.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
modified on Tuesday, December 11, 2007 11:12:43 AM
|
|
|
|
|
As cedric said, you can set the parameters to be accesed with public or leave them private and create some SetParameter () // GetParameter () , to write // read the variables. Then just including the header you should have access to them through a pointer to the dialog.
Greetings.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
Lord Kixdemp wrote: C++ doesn't allow Client to know anything about Dialog.
Here's the clue. C++ allows Client only to know that Dialog is a Dialog, i.e the public interface of the Dialog class. This is painful because it restricts what Client knows and you have to make everything about Dialog you want accessible available as part of the public interface but it's great in the long term because Client doesn't care which Dilaog it is or even what sort of Dialog as long as it is a Dialog class the code will work. Do it in C and it'll be done in half the time and obselete and unmaintainable in months. In C++ it might take a while to do but you'll still be using bits of it when you're old and grey. 
I port a lot of C code to C++ so here's a method you might be able to simulate if you find it easier to think in C.
I take each C source file and turn it into a class.
Every file static variable becomes a member variable, every function extern(ed) in any other file becomes a public member function.
Every little utility function not extern(ed) becomes a private member function.
Then I create one single file static instance of the class. This gets me a half way house between C and C++ and by the time a whole project has been tranformed like this I can see what the public interfaces need to be and how the instancing of each class should be controlled. What owns what. Eventually all the file level statics disappear and the large classes are reworked into objects that match the required instancing pattern. OOP is not so hard after all.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I deserve harsh punishment for not Googling first. 
|
|
|
|
|
|
Lord Kixdemp wrote: I deserve harsh punishment for not Googling first.
And you will likely receive harsh punishment if you tightly couple a business object to a view. Your punishment will be in the form of dealing with the technical debt[^] of a poor design. OOD is a tool that can solve problems of software development like hard to maintain and inflexible code. Notice I said it "can" solve those problems, or a sub optimal design, like one that would tightly couple business classes to view classes, could result in "creating" those same problems.
There is much information available on the subject of Object Oriented Design. I strongly suggest you take some time to become familiar with things like best practices and principles of object oriented design. You might try some articles or tutorials and for sure get introduced to Software Design Patterns[^].
Good luck
|
|
|
|
|
|
Lord Kixdemp wrote: would you mind pointing out which of those is the best to start with?
It's almost impossible to know which one is better suited to your needs. Everyone is different. I will tell you that from my experience I have been a student of Object Oriented Design for years and I see no end to that on the horizon. So if your intention is continual improvement buckle up for a long ride of reading and trying to understand OOD. And if that wasn't enough there is Aspect Oriented and a new resurgence of Functional Programming that is being added to the .NET platform.
If you do spend time reading on the subject you will eventually come upon some of the leading experts in the industry. They have Wiki's, Blogs whatever that discuss OOD. A couple of them are Kent Beck and Ward Cunningham. Cunningham maybe invented the Wiki[^], not sure, where he started the Portland Pattern Repository. Anyway that site is so full of information I doubt you could ever read it all.
Hope that helps.
|
|
|
|
|
One possible solution is to send messages to the dialog. Your client needs the target Window (CWnd*) and you can use the SendMessage() , or I suggest the PostMessage() API because it is non blocking.
Another way are global objects and structures or callbacks.
Interesting and important is to use the Timer-function to execute regurarly some actions!!!
Search for WM_TIMER
Greetings from Germany
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
