Communiting between .cpp file and widgets
Hi all,
I have a problem while i was doing programming in KDevelop in Linux.
The problem is as follows:
I am creating a GUI with widgets, forms etc in KDevelop.
I have a separate .cpp file that contains all my core functions.
I need to communicate between the .cpp file and the widgets in the GUI. For example, when a button is clicked, a clicked() event occurs and it should send a signal (or some indication) to the .cpp file to initiate some function in the .cpp file. Also, the functions in the .cpp file need to be able to access widgets in the GUI. For example, a function in the .cpp file may need to update a list box in the GUI.
In essence, I need two way communication between the .cpp file and the widgets .cpp file. May I know how that can be done?
Please help and thanks in advanced.
Thank you.
Regards,
Simon
[904 byte] By [
teo_simon] at [2007-11-19 10:04:16]
# 1 Re: Communiting between .cpp file and widgets
That's why you would normally use a header file to declare all the functions. Then you can call the functions defined in one .cpp file from another one.
You probably do not need a two-way connection. Your widgets might depend on the objects they are representing but the converse should not normally be the case.
(Is that what you wanted?)
# 2 Re: Communiting between .cpp file and widgets
Have you checked-out this tutorials already?
http://www.kdevelop.org/index.html?filename=3.2/tutorials.html
# 3 Re: Communiting between .cpp file and widgets
Those who program or have programmed with MFC would know the Doc/View architecture.
Now I dislike MFC and used to find this very complex in the past, but the basis behind it is that the "Doc" which contains the data should not have to know about the implementation of the "View". It may know of the existence of views as a whole, and there is a command to update all its views when it is modified.
The concept can be applied to any GUI platform, except that I generally feel that the concept of a "view" should be outside of any particular GUI framework, which therefore ends up being the downfall of MFC (among many).
Incidentally, that is fine when you are writing a document editor and your document has multiple views, but a lot of the time you are not writing a document editor, and there is only one GUI window for your data, and it is a lot simpler if that window simply had a pointer to an object and would call methods on the object. (Added to that, there is no reason why such an application should not have a menu, yet the only MFC option for the above type of application is a dialog application which doesn't have a menu). Oh, and I can have a database-based application without having to specify the source before I start writing it. (End of my MFC rant).
# 4 Re: Communiting between .cpp file and widgets
That's why you would normally use a header file to declare all the functions. Then you can call the functions defined in one .cpp file from another one.
You probably do not need a two-way connection. Your widgets might depend on the objects they are representing but the converse should not normally be the case.
(Is that what you wanted?)
hi are you referring to a single header file that contains both class definitions of both the widget and that of the other .cpp file?
I have tried it but i still can't get it to work
# 5 Re: Communiting between .cpp file and widgets
Those who program or have programmed with MFC would know the Doc/View architecture.
Now I dislike MFC and used to find this very complex in the past, but the basis behind it is that the "Doc" which contains the data should not have to know about the implementation of the "View". It may know of the existence of views as a whole, and there is a command to update all its views when it is modified.
The concept can be applied to any GUI platform, except that I generally feel that the concept of a "view" should be outside of any particular GUI framework, which therefore ends up being the downfall of MFC (among many).
Incidentally, that is fine when you are writing a document editor and your document has multiple views, but a lot of the time you are not writing a document editor, and there is only one GUI window for your data, and it is a lot simpler if that window simply had a pointer to an object and would call methods on the object. (Added to that, there is no reason why such an application should not have a menu, yet the only MFC option for the above type of application is a dialog application which doesn't have a menu). Oh, and I can have a database-based application without having to specify the source before I start writing it. (End of my MFC rant).
Yes i am thinking of something similar to doc/view of MFC where i can gain control in both directions... now i'm stuck with passing the control to each other... anyone knows how to do it? for example, in MFC, we use GetDocument() in the view file to get control of the doc part so that i can call methods in doc.cpp file... so how do i do this in kdevelop? thanks
# 6 Re: Communiting between .cpp file and widgets
I am guessing you are doing this in qt. Have you done the tutorials.
Alongside the KDevelop ones linked above, there is the official two:
http://doc.trolltech.com/3.3/tutorial.html
http://doc.trolltech.com/3.3/tutorial2.html
and the excellent docs: http://doc.trolltech.com/3.3/
as well an excellent tutorial at: http://www.digitalfanatics.org/projects/qt_tutorial/
Also a qt forum at: http://www.qtforum.org
It sounds to me like you have completely missed signals/slots, and that is by far the most important aspect of qt.
The basic of qt is this:
1. You design you qt widgets/gui in QtDesigner. You create whatever slots there should be, and you connect appropriate signals to slots. So lets say you have a button and you want something to happen when its clicked. You create a slot slotClicked() (for example, a more appropriate name in your case is better), and you connect the button's clicked() signal to this slot. Do NOT write any implementation in Qt designer.
2. Once you have created the gui, add it to your KDevelop project, and subclass it. This will create a .h and .cpp files for a class that inherits the Widget's class. In here you do your implementation. So toy would implement the slotClicked() slot.
That's the quicky of it. The KDevelop tutorial (http://women.kde.org/articles/tutorials/kdevelop3/) explains all this really well.
Also read the docs. Qt has the best documentation i've ever had to deal with.
Good luck,
Latem
Latem at 2007-11-9 0:50:36 >
# 7 Re: Communiting between .cpp file and widgets
I am guessing you are doing this in qt. Have you done the tutorials.
Alongside the KDevelop ones linked above, there is the official two:
http://doc.trolltech.com/3.3/tutorial.html
http://doc.trolltech.com/3.3/tutorial2.html
and the excellent docs: http://doc.trolltech.com/3.3/
as well an excellent tutorial at: http://www.digitalfanatics.org/projects/qt_tutorial/
Also a qt forum at: http://www.qtforum.org
It sounds to me like you have completely missed signals/slots, and that is by far the most important aspect of qt.
The basic of qt is this:
1. You design you qt widgets/gui in QtDesigner. You create whatever slots there should be, and you connect appropriate signals to slots. So lets say you have a button and you want something to happen when its clicked. You create a slot slotClicked() (for example, a more appropriate name in your case is better), and you connect the button's clicked() signal to this slot. Do NOT write any implementation in Qt designer.
2. Once you have created the gui, add it to your KDevelop project, and subclass it. This will create a .h and .cpp files for a class that inherits the Widget's class. In here you do your implementation. So toy would implement the slotClicked() slot.
That's the quicky of it. The KDevelop tutorial (http://women.kde.org/articles/tutorials/kdevelop3/) explains all this really well.
Also read the docs. Qt has the best documentation i've ever had to deal with.
Good luck,
Latem
Hi thanks for your reply.
I know about the slot/signal thing. However, what I am trying to do is not exactly this. I have already created a subclass for the GUI. However, I have created a SEPARATE class (for example i call it class abc) with abc.cpp and abc.h files generated. I want to write my core functions in abc.cpp and NOT in the subclass of the GUI. I need to access members (example label, list boxes etc) in the GUI from abc.cpp as well as call functions in abc.cpp from the subclass of the GUI. This is the communication that I am trying to establish. Any help? Thanks
# 8 Re: Communiting between .cpp file and widgets
That's exactly my point though. If there is suppose to be such tight interconnection and interaction between the 2 classes, then why would you want them to be separate like so? Wont you just be doing something like, when event X happens, method Y is executed, which just ends up calling method Z of another class. I dont know the specifics though.
To call the ABC methods from within your widget class, all you need is an ABC member in the widget's class. So for example in the widget's header file you would declare ABC* myAbc; as a member variable
Dont forget to forward declare class ABC at the top.
Then in the widget's cpp file do #include "abc.h".
In the constructor of the widget class make your abc object, and use it in the apporpriate places in the widget.
So lets say you want to call ABC::foo(), when the button X is clicked. Then in the slot slotXClicked(), you call myAbc->foo();. Something along that nature.
You could use singlas and slots here as well. Make the abc class inherit QObject (and don't forget the Q_OBJECT macro), and have the methods you need to call in the widget's calss as slots. Then you create a member variable exactly as described above, but now you can directly connect the desired signals and slots. So lets say that when button X is pressed, you want ABC::foo() to get executed. then you would do in the widget's constructor, or in some other appropriate place depending on the specifics:
connect(myButtonX, SIGNAL(clicked()), myAbc, SLOT(foo()));
There is no need now to call myAbc->foo(), it will automatically get called when the button is pressed.
As well ABC could have signals, and you can connect it's signals to the widget's slots, and transfer data between the 2 using signals and slots.
These are a couple of ways. Again I dont know the specifics, so I am not sure whats the best solution for you.
GL,
Latem
Latem at 2007-11-9 0:52:39 >
# 9 Re: Communiting between .cpp file and widgets
Because he doesn't want them to be tightly coupled. While the GUI depends on the object it is representing, there is no reason why an object should know about the GUI object representing it.
I don't know what the problem is though - within the GUI you simply have a pointer to the class and call its methods. (Or instead of a pointer, have a scoped_ptr or an instance etc.).
# 10 Re: Communiting between .cpp file and widgets
That's exactly my point though. If there is suppose to be such tight interconnection and interaction between the 2 classes, then why would you want them to be separate like so? Wont you just be doing something like, when event X happens, method Y is executed, which just ends up calling method Z of another class. I dont know the specifics though.
To call the ABC methods from within your widget class, all you need is an ABC member in the widget's class. So for example in the widget's header file you would declare ABC* myAbc; as a member variable
Dont forget to forward declare class ABC at the top.
Then in the widget's cpp file do #include "abc.h".
In the constructor of the widget class make your abc object, and use it in the apporpriate places in the widget.
So lets say you want to call ABC::foo(), when the button X is clicked. Then in the slot slotXClicked(), you call myAbc->foo();. Something along that nature.
You could use singlas and slots here as well. Make the abc class inherit QObject (and don't forget the Q_OBJECT macro), and have the methods you need to call in the widget's calss as slots. Then you create a member variable exactly as described above, but now you can directly connect the desired signals and slots. So lets say that when button X is pressed, you want ABC::foo() to get executed. then you would do in the widget's constructor, or in some other appropriate place depending on the specifics:
connect(myButtonX, SIGNAL(clicked()), myAbc, SLOT(foo()));
There is no need now to call myAbc->foo(), it will automatically get called when the button is pressed.
As well ABC could have signals, and you can connect it's signals to the widget's slots, and transfer data between the 2 using signals and slots.
These are a couple of ways. Again I dont know the specifics, so I am not sure whats the best solution for you.
GL,
Latem
thanks.. that sounds good .. i'll try it out tomorrow at work...
but i have some queries..
for the slot/signal method, let's say i want to do some processing or run some stuff before calling a method in ABC.cpp when i click a button, does the code "connect(myButtonX, SIGNAL(clicked()), myAbc, SLOT(foo()));" equal to "myAbc->foo();"? does that mean that once the code "connect(myButtonX, SIGNAL(clicked()), myAbc, SLOT(foo()));" is executed, the method foo() in ABC.cpp is executed?
as for communicating from ABC.cpp to my widget class, i need to do things like updating of objects in the GUI like labels, line edits etc.. so i need to reference directly to the objects. I may also need to call methods in the subclass. So in this sense, which is a suitable method of doing so? i have tried creating a member variable before but i can only call methods in the subclass but i CANNOT directly access the GUI objects like the labels etc.
# 11 Re: Communiting between .cpp file and widgets
Because he doesn't want them to be tightly coupled. While the GUI depends on the object it is representing, there is no reason why an object should know about the GUI object representing it.
I don't know what the problem is though - within the GUI you simply have a pointer to the class and call its methods. (Or instead of a pointer, have a scoped_ptr or an instance etc.).
thanks.. i have used the pointer to the class to call its methods already..
but i still cant directly access objects in the GUI from ABC.cpp.
For example, in the GUI, I have a QLabel called "label". In the subclass .cpp file, i can easily change the text in the QLabel by "label->setText("my desired text");"... however, how can i do this in the ABC.cpp file? i tried using the member technique but it only allows me to call methods but not the objects... many thanks
# 12 Re: Communiting between .cpp file and widgets
But they are tightly coupled now, and how he wants them. If he uses my first suggestion, then that's pretty much the prime example of tight coupling.
If he uses my second suggestion, with signals and slots, he removes that for the most part. The 2 classes dont have to (and indeed they dont) know almost anything about each other. The widget class just needs to know about the available interface between the two, that is what signals and slots ABC has. It makes the appropriate connectons, and everything is executed how it's suppose to. ABC is completely separate from the Widget class, and doesn't know anything about it. All they have to do is send the apporpriate signals. And the data is available, for use to be handled by whoever wants it.
Use signals and slots. ABC has signals for example: sendMessage(const QString& msg);
In the apporpriate place in ABC, just do emit sendMessage("Some text here");
In the widgets class, connect this signal to a qlabel's setText slot
Latem
Latem at 2007-11-9 0:56:42 >
# 13 Re: Communiting between .cpp file and widgets
but i have some queries..
for the slot/signal method, let's say i want to do some processing or run some stuff before calling a method in ABC.cpp when i click a button, does the code "connect(myButtonX, SIGNAL(clicked()), myAbc, SLOT(foo()));" equal to "myAbc->foo();"? does that mean that once the code "connect(myButtonX, SIGNAL(clicked()), myAbc, SLOT(foo()));" is executed, the method foo() in ABC.cpp is executed?
as for communicating from ABC.cpp to my widget class, i need to do things like updating of objects in the GUI like labels, line edits etc.. so i need to reference directly to the objects. I may also need to call methods in the subclass. So in this sense, which is a suitable method of doing so? i have tried creating a member variable before but i can only call methods in the subclass but i CANNOT directly access the GUI objects like the labels etc.
Sorry i missed this part; ppl are replying too fast or something. and im lost now. so ill address it separately. Hopefully I didnt make a fool of my sellf, cuz i missed something.
From the 1st paragraph, it's clear that you dont understand singals and slots. You have to do
connect(myButtonX, SIGNAL(clicked()), myAbc, SLOT(foo()));
only once. That creates the apporpriate conenctions. From then on, whenever the button X is clicked foo() is executed. The method ABC::foo() is not executed when you do this statement. All you have to do is that one statment, and when X is clicked foo() is run. that's it.
For the 2nd part. Signals and slots are the apporpriate method as well. You dont need to access those widget's members directly. All you need is that ABC has signals, that will supply the Widget with data it needs to affect the state of GUI.
If you want them to be separate, use signals and slots for the communcation. It's the best way, withou adding tight coupling with pointers to each otehr, and accessing each other memebrs and stuff. Signals and slots create the interafce where you can avoid this.
Read the docs, and do the tutorials.
GL,
Latem
Latem at 2007-11-9 0:57:45 >
# 14 Re: Communiting between .cpp file and widgets
I don't know why your class wants to talk to the GUI. Perhaps it is to inform it when it has been changed. (UpdateAllViews concept). That is, assuming it may be changed without the GUI knowing (other objects share pointers to it, there are other views, etc).
I don't know about your particular system, but you could write an adapter. It can use an abstract base class with one method, signalModified(), perhaps.
Your GUI will be able to create a "concrete" version of that class which it can pass to the object. The object may have a collection of these and will use the abstract version.
Adding an in-between 3rd class can often be the best way to reduce coupling. (I think it's called the Bridge pattern, because the 3rd class acts as a bridge).
# 15 Re: Communiting between .cpp file and widgets
Here's a quick example of what I am talking about, and maybe it applies to what you want. Cuz this is what it sounds like to me is what you are trying to do.
You have your widget GUI which has a button (btnX) on it, a label (m_label), and an integer selecting spin box thing (m_numInput). I forgot the exact name of the control.
You inherit this class widget class. the header file of the subclass:
#ifndef MYDIALOG_H
#define MYDIALOG_H
#include <qdialog.h>
class ABC;
class MyDialog : public MyDialogUI
{
Q_OBJECT
public:
MyDialog( QWidget* parent = 0, const char* name = 0, bool modal = FALSE, WFlags fl = 0 );
~MyDialog();
public slots:
virtual void btnXClicked();
private:
ABC* myAbc;
};
#endif
and the cpp file:
#include <qbutton.h>
#include <qlabel.h>
#include <qnuminput.h>
#include "abc.h"
MyDialog::MyDialog(QWidget* parent, const char* name, bool modal, WFlags fl)
: MyDialogUI(parent,name, modal,fl)
{
myAbc = new ABC(this);
connect(myBtnX, SIGNAL(clicked()), this, SLOT(btnXClicked()));
connect(myAbc, SIGNAL(message(const QString& msg)), m_label, SLOT(setText(const QString& msg)));
}
MyDialog::~MyDialog()
{
delete myAbc;
myAbc = 0;
}
MyDialog::btnXClicked()
{
myABC->foo(m_numInput->value());
}
then you have the ABC class that does the "core functionality":
#include <qobject.h>
#include <qstring.h>
class ABC : public QObject
{
Q_OBJECT
public:
ABC();
~ABC();
public slots:
void foo(int n);
signals:
void message(const QString& msg);
};
and the cpp file:
ABC::ABC()
{
// do construction
}
ABC::~ABC()
{
// do destruction
}
void ABC::foo(int n)
{
n = n*n;
QString msg;
msg = msg.setNum(n);
emit message(msg);
}
See there is no need to actually access the widget stuff from the ABC. When the button is clicked the btnXClicked() signal is executed. that just calls foo(int) with the value of the integer selecting spin box thing. the foo method just finds the square of n. and emits the value in the message signal. When this happens the label's text is directly updated thanks to the connection.
However, obviusly there is no need for ABC at all, since it's stuff can already be done in the Widget class. That's why I was first saying maybe there is not need for your ABC at all. But if there is, then you can use signals and slots similar to this.
Note that this code is written purely by hand, so it probably has some mistakes, and wont compile exaclty as is. (well u arre missing the base widget too).
Latem
Latem at 2007-11-9 0:59:44 >
# 16 Re: Communiting between .cpp file and widgets
hi i have finally managed to solve the problem with all the help you helpful guys out there!!! thanks a million!!
