I am using a QTableWidget to display and edit a data matrix. For validation purpose, I used the QLineEdit as items in this table. As following,
pTable=new QTableWidget(N,N,this);
pItem=new QLineEdit();
pItem->setText(tr("%1").arg(pInfra->adjacencyM(i,j)));
rx=new QRegExp("0|1");
validatorRegexp=new QRegExpValidator(*rx,0);
pItem->setValidator(validatorRegexp);
pTable->setCellWidget(i,j,pItem);
Since I want to know if data in certain cell has been changed, so I tried cellChanged(int, int) signal, and connect it with my own slot cellEdited(int,int), like this
connect(pTable,SIGNAL(cellChanged(int,int)),this, SLOT(cellEdited(int,int)));
But, when I edit QLineEdit in the cell, I can not catch this signal. When will this signal be fired? Or can I do this using another signal or in some other way?
Thanks!
The problem is that the cellChanged() signal is emittet only if the table model is issued the setData() method, which normally comes from the QLineEdit of the delegate. Since You have your own mechanism by setting the cell widget the setData() method of the model will never be called. Which means you'll have to connect to the textChanged() or the textEdited() signal of the QLineEdit object you put in the cells.
Another valid option is the approach mentioned by beduin in the comment.
Also possible: You could subclass the used delegate and make it create QLineEdit objects with your validator. Which would be the cleanest approach since you don't interfere with the model/view architecture and can rely on the signals the table object is sending.
Best regards
D
Not aware about causes of this problem. Considering another ways. You can catch QLineEdit signal textChanged and use QSignalMapper to bind signal, fired by each QLineEdit to particular cell number. Maybe itsn't the best qway to do that, but you can use it in case this problem won't be solved.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I need a bit of an explanation about the connect function and his use. I already connect signal and QButton or signal and timer.
Now I create my own signal, this signal is emit when I receive data from a client. I want to connect this signal to a QTableWidget ... But there's no QButton or something like that, so I don't know how to call connect() , and I realize I don't really understand the function.
Can you explain me how to connect my QTableWidget and my signal ?
Look at the QTableWidget docs, for example via Qt Assistant or this link:
http://qt-project.org/doc/qt-4.8/qtablewidget.html
(note that this is for Qt 4.8, but docs for other versions are also available online). Search for the section entitled 'Signals' - these are the signals that every QTableWidget will emit in certain situations. Each Qt widget has such a set of signals characteristic for this particular widget. The signals for QTableWidget are different than for QPushButton you've mentioned.
For example, QPushButton has the signal clicked() that is emitted when the button gets pushed, but it is only one of the several signals it can emit. It can emit signals also e.g. when the title of the main window gets changed. QTableWidget doesn't feature the clicked() signal, but has many others.
Find the signal that will enable you to do what you want in your program, and then connect it to the slot via the connect() function. There is a bunch of readymade slots available for QTableWidget (search for the section 'Slots' in the above mentioned docs).
If you cannot find the right slot, you can write one yourself and connect signal to it. If you cannot find proper signal, you may have to subclass QTableWidget and add an appropriate function to it that will emit the signal in the situation defined by you.
Also, here's a quick guide to how the connect() function works in general:
http://qt-project.org/doc/qt-4.8/signalsandslots.html
BTW: always state the Qt version you use since some problems are version-specific.
The connect() method adds the tuple (sender, sender signal, receiver, receiver signal) to the connection table for a given sender. Both the sender and the receiver are pointers to instances of QObject. The signal and slot can be provided as signatures wrapped in SIGNAL or SLOT macros, or as method pointers in Qt 5. Internally they are stored as method indices.
You need to know the contents of this tuple in order to call connect(). That's all.
The connection table is used within the signal to invoke the slots. A signal is a method whose implementation is generated by the moc tool. The implementation iterates through the connection table and invokes the slots connected to the signal.
"when I receive data from a client. I want to connect this signal to a QTableWidget"
This is ambiguous. Yes, there are no buttons in a QTableWidget. A QTableWidget is defined in the Qt documentation as follows: -
The QTableWidget class provides an item-based table view with a default model.
If you look at the public slots, you can see what your signals can connect to in the QTableWidget class.
However, I expect that what you're wanting to do is add data to the table, having received it from a data source. As the QTableWidget class is a view on a model, it's the model you need to look at here.
I suggest you begin by reading up on Qt's Model-View programming, to understand how models link to views and how to populate a model with your received data.
Also, if you're not quite sure about how signals and slot work, you can read the Qt tutorial for that here.
In order to to what you want, you need to connect a signal to a slot, and call the slot when the signal is emitted. There's no reason to use only QButton. You can use every class in order to emit right signals (with right arguments).
You need to use connect connecting your signal and the QTableWidget slot.
I've problem with qt signal-slot system.
First I've created a class which is called System in Singleton pattern, so I can access it's instance where I want. System has a signal SelectionChanged.
I've a list widget and I am connecting it's itemSelectionChanged signal to my custom slot which is called onSelectionChanged. In onSelectionChanged slot, I am emitting System's SelectionChanged signal. There is no problem yet.
In my software design, a selection of object(s) can be used by many GUI widgets or custom classes and System's SelectionChanged signal can be emited by widgets other then the list widget.
So I am creating a slot called OnSystemSelectionChanged in the list widget then connect it to the System's SelectionChanged signal. The OnSystemSelectionChangedSlot is like this.
void MyListWidget::OnSystemSelectionChanged(QObject *sender)
{
if (sender == this) return;
// Then I want to get a list of selected objects and set them as selection of this widget like this:
this->SetSelection(System::Instance()->GetSelectedObjects());
}
But the problem is when I start to set the list widget's selected items, it is going to emit itemSelectionChanged signal and my onSelectionChanged slot will be called. Then the slot will emit System's SelectionChanged signal and then OnSystemSelectionChanged will be called too. It will stop through sender parameter but there is no method for setting list widget's selected items at once.
How can I figure this problem out.
I hope I did explain my problem well. Thanks in advance.
Edit: Spelling and grammer errors are corrected.
There are a few ways of dealing with this in Qt.
Idioms
Use multiple views with one underlying model. This handles propagation of changes to multiple view controls automatically and you don't need to do anything extra. You can use QDataWidgetMapper to link "plain old" widgets to the data elements in a model. I'd say that this should be the preferred way of doing things. Having an underlying model for all of your UI is a step in the direction of good software design anyway.
When propagating changes between data models, implement both a DisplayRole and an EditRole. The views will nominally modify the models using one of the roles (say, the EditRole), while you can, programmatically, modify the models using the other role (say, the DisplayRole). You handle the dataChanged signals from the model in your own slot, properly dealing with the roles, and call setData on the other models with the other role. This prevents the loops.
For controls that are not QAbstractItemViews, implement two signals: one emitted on any change, another one emitted only on changes based on keyboard/mouse input. This is the interface exposed by QAbstractButton, for example: the toggled(bool) signal is the former, the clicked() is the latter. You then only connect to the input-based signals.
Your own code must propagate programmatic changes to all the interlinked controls, since changing one control from your code won't modify the others. This should not be a problem, since well designed code should encapsulate the implementation details of UI controls from rest of the code. Your dialog/window class will thus expose its properties in a way that's not coupled to the number of controls showing a particular property.
Hackish Let's-Hope-They-Won't-Become Idioms
Use a flag inhibiting signal emission (Bartosz's answer).
Break the signal/slot connections for the duration of the change (Bartosz's answer).
Use QObject::blockSignals().
There are two possible solutions I can think of:
add a flag which makes possible to ignore particular signals:
void MyListWidget::OnSystemSelectionChanged(QObject *sender)
{
if (sender == this || inhibitSelectionChanged)
return;
this->inhibitSelectionChanged = true;
this->SetSelection(System::Instance()->GetSelectedObjects());
this->inhibitSelectionChanged = false;
}
disconnect the slot from the signal, and reconnect it after changing the selection:
void MyListWidget::OnSystemSelectionChanged(QObject *sender)
{
if (sender == this)
return;
this->disconnect(SIGNAL(SelectionChanged()));
this->SetSelection(System::Instance()->GetSelectedObjects());
this->connect(
this, SIGNAL(SelectionChanged()),
this, SLOT(OnSystemSelectionChanged(QObject*)));
}
I found my solution in QObject::blockSignals() method. It will prevent emitting signals from the list widget while I am setting selected items.
Thanks for all the answers and solutions especialy for BartoszKP's. This solution is looks like the official way of his first solution.
The problem: you've tried to cut corners and created a singleton. Not a classic case for singleton.
Signals and slots are used for notifications, each object notifies interested objects about what it did or to reflect its new state.
I'm suggesting changing the design as follows:
No singleton signal.
Each Object has its own signal and slot for a relevant event (e.g. selection change).
The application or a higher level object (that created the widgets/objects) performs the signal to slot connection. If those widgets are placed in a list, this is very simple.
I have many QLineEdit's in my Main Window. I have a connected the editingFinished() SIGNAL of each object to a single SLOT in my QMainWindow class.
I want to implement my own Undo/Redo functionality. I find the Qt Undo framework pretty difficult to understand & complex to implement.
So I want to maintain a QList <QLineEdit *> undoList; which will store the sequence of QLineEdit's which were modified. I am maintaining an int variable to keep track of current state. When Undo/Redo is done I can simply update the int variable & find the QLineEdit which was edited at that state & then call undo() on that QLineEdit.
Currently my biggest problem is that since I have connected all my QLineEdit's to a single SLOT, I have no information as to which QLineEdit emitted that SIGNAL.
So I would like to know if there is any way by which I can understand which QLineEdit emitted the SIGNAL.
Thank You.
Use sender() inside the slot to get the the QObject that emitted the signal connected to it.
In my form I have a QListWidget which contains checkable QListWidgetItems. I'm looking for a way to capture the event of a QListWidgetItem being checked/unchecked. I don't see any such signal existing for this but maybe I'm wrong. What I'm currently doing is using the QListWidget::itemClicked() signal and checking the checkState of the QListWidgetItem, but this isn't what I want because this event happens any time the item is clicked, not just went the checkmark is toggled. Can anyone give some assistance? Thanks!
Apparently no such signal is provided, your best bet is to use QListWidget::itemChanged(QListWidgetItem* item) , and scan the resulting item->checkState(). This should be a slight improvement over using itemClicked
An extra option is to use your own QAbstractListModel with a QListView. At first this does add some extra code as you need to add your own management code . But you do get a lower level access. Basically because the QListView will ask your model what to do. It will also relay input back to your listmodel where you can hook into it.
Alternatively you could subclass QStandardItemModel and catch certain edits related to changing the checkbox.
I am creating a GUI to manipulate a robot arm. The location of the arm can be described by 6 floats (describing the positions of the various arm joints.
The interface consists of a QGraphicsView with a diagram of the arm (which can be clicked to change the arm position - adjusting the 6 floats). The interface also has 6 lineEdit boxes, to also adjust those values separately.
When the graphics view is clicked, and when the line edit boxes are changed, I'd like the line edit boxes / graphics view to stay in synchronisation.
This brings me to confusion about how to store the 6 floats, and trigger events when they're updated. My current idea is this:
The robot arm's location should be represented by a class, RobotArmLocation. Objects of this class then have methods such as obj.ShoulderRotation() and obj.SetShoulderRotation().
The MainWindow has a single instance of RobotArmLocation.
Next is the bit I'm more confused about, how to join everything up. I am thinking:
The MainWindow has a ArmLocationChanged slot. This is signalled whenever the location object is changed.
The diagram class will have a SetRobotArmLocation(RobotArmLocation &loc). When the diagram is changed, it's free to change the location object, and fire a signal to the ArmLocationChanged slot.
Likewise, changing any of the text boxes will fire a signal to that ArmLocationChanged slot. The slot then has code to synchronise all the elements.
This kind of seems like a mess to me, does anyone have any other suggestions? I've also thought of the following, does it have any merrit?
The RobotArmLocation class has a ValueChanged slot, the diagram and textboxes can use that directly, and bypass the MainWindow directly (seems cleaner?)
thanks for any wisdom!
Except for really simple cases (e.g. a label that shows the value of a slider) my experience has been to stay away from inter-component signal/slot connections inside Qt Designer. Rather, have the component firing the signal of interest connect to a slog defined in the top level QWidget class you're subclassing (i.e. QMainWidow, etc... let's just call it the Form class). You can also go the other way: if you have a custom signal in the Form class, you can connect it with Qt Designer to one of the public widget slots.
To be specific using your example:
I'm going to assume that you have subclassed QMainWindow and QGraphicsView. Let's call the subclasses RobotMainWindow and RobotView.
RobotMainWindow contains the QLineEdit fields and RobotView. The way you specify RobotView in Qt Designer is to insert a QWidget and use the Promote to... feature to tell Qt that the QWidget should be replaced at compile time with your custom RobotView.
Name the QLineEdit fields edit1, edit2...edit6.
In the Qt Designer signal/slot editor define slots in RobotMainWindow to be called when the value in a QLineEdit changes. There are some more elegant ways of doing this, but for simplicity let's say you define 6 slots named setValue1(float), setValue2(float), etc.
In the source code for RobotMainWindow, go declare and define these slots, such that they update your arm, shoulder, whatever.
Also in the source code, define a signal valueChanged() (or multiple for each field, your choice). Have the slots you defined emit valueChanged().
Back in Qt Designer you can now link the appropriate signal from each QLineEdit to the corresponding slot in RobotMainWindow.
Back in the signal/slot editor add the valueChanged() signal to the RobotMainWindow (so Qt Designer knows about it). Connect this signal to a new slot in RobotView, using the procedure above, so it can update the rendering.
Repeat all of this for handling changes from RobotView to the editing fields (via RobotMainWindow.
In short, I think you'll find everything more straight-forward if your route the signals through your Form subclass (which I think of as the Controller in MVC parlance).