How can you edit a QTableView cell from a QTest unit test? - qt

I'm writing a unit test for a custom Validator in a QTableView using the QTestLib framework. One of the most basic test cases could be described like this:
Double click the table cell in the third column and the fourth row, and append the number '5' to its content.
It is not sufficient to simply change the value in the model or anything, the test case shall perform it like this:
Double Click the table cell to set it into edit mode
Press the [End] key.
Press the [5] key.
Note: This question has an answer on how to set a table cell into edit mode from code, however the unit test shall try to stick to the possibilities of a human user, i.e. Mouse/Keyboard actions.
I've found out the X/Y position of a cell can be retrieved using QTableView::columnViewportPosition( int ) and QTableView::rowViewportPosition( int ).
However, double clicking at the specified location using QTest::mouseDClick(...) neither selects the cell nor sets it into edit mode:
// Retrieve X/Y coordinates of the cell in the third column and the fourth row
int xPos = m_pTableView->columnViewportPosition( 2 );
int yPos = m_pTableView->rowViewportPosition( 3 );
// This does not work
QTest::mouseDClick( m_pTableView, Qt::LeftButton, QPoint( xPos, yPos ) );
How can I implement the test case which I described above, using Mouse/Keyboard actions only?
PS: I am trying this under Windows XP 32 bit and Qt 4.6.1

There are several things to consider when trying to edit in a QTableView through simulated events:
A QTableView does not display its cells directly, it does that using its viewport(). Likewise, the double click event must be sent to the viewport instead of the table view itself.
Now when you do
QTest::mouseDClick( m_pTableView->viewport(), Qt::LeftButton,
NULL, QPoint( xPos, yPos ) );
the cell will be selected, but not in edit mode (unlike a human-initiated double click which instantly puts the cell into edit mode even if the table view did not have focus before). If you add a single click on the same location before the double click, however, it will work!
If you then sent the [End] keypress to the viewport, the cursor would not jump to the end of the table cell content, but instead the last cell in the current row would be selected.
In order to change the table cell content, you must send the event to the current editor widget instead. The easiest way to do that is the usage of QWidget::focusWidget()
QTest::keyClick( m_pTableView->viewport()->focusWidget(), Qt::Key_End );
Note that using it like that can be unsafe though as focusWidget() can return NULL.
With that knowledge, the test case can be programmed as follows:
// Note: The table view must be visible at this point
// Retrieve X/Y coordinates of the cell in the third column and the fourth row
int xPos = m_pTableView->columnViewportPosition( 2 ) + 5;
int yPos = m_pTableView->rowViewportPosition( 3 ) + 10;
// Retrieve the viewport of the table view
QWidget* pViewport = m_pTableView->viewport();
// Double click the table cell to set it into editor mode
// Note: A simple double click did not work, Click->Double Click works, however
QTest::mouseClick ( pViewport, Qt::LeftButton, NULL, QPoint( xPos, yPos ) );
QTest::mouseDClick( pViewport, Qt::LeftButton, NULL, QPoint( xPos, yPos ) );
// Simulate [End] keypress
QTest::keyClick( pViewport->focusWidget(), Qt::Key_End );
// Simulate [5] keypress
QTest::keyClick( pViewport->focusWidget(), Qt::Key_5 );
(Note: if you want to verify this, you can add QTest::qWait( 1000 ) commands after each event)
If you are using the _data() functions as described here, note that you cannot retrieve the focusWidget() at the time of data creation.
I solved this issue by creating a custom interface ITestAction with only a pure virtual "execute()" function. I then added subclasses with a similar constructor as the QTest::mouseClick(...) etc functions. These classes simply call the QTest functions but use either the widget itself or its focus widget as a parameter, dependent on an additional boolean flag.
The _data() slot then stores a QList< ITestAction* > for each data row, and the actual test slot iterates over that list and calls execute() on each item before the validation is performed.

Related

QTableView not scrolling all the way to the bottom

I'm mocking up a table in Qt using QTableView and QStandardItemModel. The table represents events in a log. It should scroll to the bottom so that it can show the most recent event. To be clear, I am mocking up this display, I am not adding elements to the table dynamically.
When I try using either the scrollToBottom method or the scrollTo method, the view is scrolling about 3/4 of the way down, rather than to the actual bottom of the window.
Here's a simplified version of my code:
logModel = new QStandardItemModel(THREADWATCHER_LOG_TABLE_LENGTH, 2, this);
logTable = new QTableView;
for (int i = 0; i < THREADWATCHER_LOG_TABLE_LENGTH; i += 6) {
QString spawnTimeString = QString("[16:09:10:");
int spawnTimeMs = 186 + i * 8; // a pseudo-random choice for the interval between spawns
spawnTimeString.append(QString::number(spawnTimeMs) + "]");
logMessage[i] = new QStandardItem(spawnTimeString + " Thread \"Image Fetcher 0\" was spawned in the image processor ");
logModel->setItem(i, 0, logMessage[i]);
// do the same thing with [i+1], [i+2]...[i+5]
// so that I get six different messages in each iteration of the loop
}
logTable->setModel(logModel);
QModelIndex lastIndex = logMessage[THREADWATCHER_LOG_TABLE_LENGTH - 1]->index();
logTable->scrollTo(lastIndex);
I get exactly the same thing if I call logTable->scrollToBottom() instead of scrolling to the last index.
Things I've tried already:
using a single-shot timer (to ensure events have completed before scrolling)
creating a public method that calls logTable->scrollToBottom(), and having something else call that method after this class's constructor finishes (the logic above is in the constructor)

Can a QComboBox display a different value than whats in it's list?

Using Qt 5.9 on Linux, I have a QComboBox with several labels.
qc = new QComboBox;
qc->addItem(tr("Red"));
qc->addItem(tr("Green"));
qc->addItem(tr("Blue"));
Lets say a user activates the QComboBox and the 3 color labels are shown in the drop down list. The user then selects the 1st item (red).
What I want to do is have the QComboBox display a different value than what was selected. I.e., if red is selected, then a number is shown, possibly 1 for the first item (or it could be an R for Red), and if green is selected, then display 2 (or G) for the second item.
My goal in doing this is to use less display space (less wide) than is actually necessary to show the complete text of the selection because some of my item strings are quite long and a much shorter label is desired when the QComboBox is not activated in it's drop down state. Besides, the item strings are descriptive and abbreviations would work better for displaying.
Edit:
Using Marek's example, thought this might help. Here's what I have. I'm expecting if the user selects from the list, then an R, G, or a B should be displayed after.
QStandardItem *red = new QStandardItem();
red->setData(tr("Red"), Qt::DisplayRole);
red->setData("R", Qt::UserRole);
QStandardItem *green = new QStandardItem();
green->setData(tr("Green"), Qt::DisplayRole);
green->setData("G", Qt::UserRole);
QStandardItem *blue = new QStandardItem();
blue->setData(tr("Blue"), Qt::DisplayRole);
blue->setData("B", Qt::UserRole);
QStandardItemModel *rgb_model = new QStandardItemModel(this);
rgb_model->setItem(0, red);
rgb_model->setItem(1, green);
rgb_model->setItem(2, blue);
QComboBox *rgb_cb = new QComboBox();
rgb_cb->setModel(rgb_model);
I get the feeling it's because I don't quite understand how to use Qt::UserRole.
Yes it is possible. QComboBox uses data model to manage items.
You have to provide own data model, with items with respective data values.
QStandardItem *itme1 = new QStandardItem();
item1->setData(tr("Red"), Qt::DisplayRole);
item1->setData("1", Qt::UserRole); // note doesn't have to be a string.
QStandardItem *itme2 = new QStandardItem();
item2->setData(tr("Green"), Qt::DisplayRole);
item2->setData("2", Qt::UserRole);
QStandardItemModel *model = new QStandardItemModel(this);
mode->setItem(1, item1);
mode->setItem(2, item2);
qc->setModel(model);
It should work, but I didn't test it. At least this should be some clue.
Please review QComboBox documentation, especially about roles.
Another solution is use translations with multiple lengths. You can provide couple translation for a single string. Each translation should be graphically shorter than earlier one.
In such situation QString contains all possibilities separated by spatial character. When such string is rendered first substring (between separators) which will fit available space will be used.
Now I do not remember what is the separator value. I've used this very long time ago (with Qt 4.8) and now can't find reference for it.
In your example for make it short just make:
qc->setWidth( 20 );
But if you really want user choose something, then:
connect( qc, SIGNAL( onCurrentIndexChanged( int ) ), SLOT( changeComboText() ) );
[...]
void changeComboText()
{
QString shortText;
//Determine short value for shortText
qc->setCurrentText( shortText );
}

QTableView::scrollTo() (finding the right QModelIndex)

I'm trying to get PgDown clicks on a QTableView to scroll down a variable number of rows. I talk to my subclassed QSortFilterProxyModel which talks to the subclassed QAbstractTableModel to figure out what the next row is. That's all fine and dandy but I believe I'm faced with two caveats:
1: The row number inside the view doesn't do much. I need a QPoint on the screen to scroll to, and I'm not sure how to derive that from a cell.
2: I can create an index in the QSortFilterProxyModel but this generally causes crashes, as the parent is different... or I'm missing something.
int nextRow = getModel()->nextRow( indexAt( rect().topLeft() ) );
QModelIndex nextIndex = getModel()->index( nextRow, 0 );
scrollTo( nextIndex, QAbstractItemView::PositionAtTop );
Okay, I figured this out:
QModelIndex nextIndex = getModel()->index( nextRow, 0 );
scrollTo( nextIndex, QAbstractItemView::PositionAtTop );
I was having the QSortFilterProxyModel create and index which was a big no-no. I have issues when I have hidden rows, but should hopefully be able to figure that out.

QTextEdit and cursor interaction

I'm modifying the Qt 5 Terminal example and use a QTextEdit window as a terminal console. I've encountered several problems.
Qt does a strange interpretation of carriage return ('\r') in incoming strings. Ocassionally, efter 3-7 sends, it interprets ('\r') as new line ('\n'), most annoying. When I finally found out I choose to filter out all '\r' from the incoming data.
Is this behaviour due to some setting?
Getting the cursor interaction to work properly is a bit problematic. I want the console to have autoscroll selectable via a checkbox. I also want it to be possible to select text whenever the console is running, without losing the selection when new data is coming.
Here is my current prinout function, that is a slot connected to a signal emitted as soon as any data has arrived:
void MainWindow::printSerialString(QString& toPrint)
{
static int cursPos=0;
//Set the cursorpos to the position from last printout
QTextCursor c = ui->textEdit_console->textCursor();
c.setPosition(cursPos);
ui->textEdit_console->setTextCursor( c );
ui->textEdit_console->insertPlainText(toPrint);
qDebug()<<"Cursor: " << ui->textEdit_console->textCursor().position();
//Save the old cursorposition, so the user doesn't change it
cursPos= ui->textEdit_console->textCursor().position();
toPrint.clear();
}
I had the problem that if the user clicked around in the console, the cursor would change position and the following incoming data would end up in the wrong place. Issues:
If a section is marked by the user, the marking would get lost when new data is coming.
When "forcing" the pointer like this, it gets a rather ugly autoscroll behaviour that isn't possible to disable.
If the cursor is changed by another part of the program between to printouts, I also have to record that somehow.
The append function which sound like a more logical solution, works fine for appending a whole complete string but displays an erratic behaviour when printing just parts of an incoming string, putting characters and new lines everywhere.
I haven't found a single setting regarding this but there should be one? Setting QTextEdit to "readOnly" doesn't disable the cursor interaction.
3.An idea is to have two cursors in the console. One invisible that is used for printouts and that is not possible at all to manipulate for the user, and one visible which enables the user to select text. But how to do that beats me :) Any related example, FAQ or guide are very appreciated.
I've done a QTextEdit based terminal for SWI-Prolog, pqConsole, with some features, like ANSI coloring sequences (subset) decoding, command history management, multiple insertion points, completion, hinting...
It runs a nonblocking user interface while serving a modal REPL (Read/Eval/Print/Loop), the most common interface for interpreted languages, like Prolog is.
The code it's complicated by the threading issues (on user request, it's possible to have multiple consoles, or multiple threads interacting on the main), but the core it's rather simple. I just keep track of the insertion point(s), and allow the cursor moving around, disabling editing when in output area.
pqConsole it's a shared object (I like such kind of code reuse), but for deployment, a stand-alone program swipl-win is more handy.
Here some selected snippets, the status variables used to control output are promptPosition and fixedPosition.
/** display different cursor where editing available
*/
void ConsoleEdit::onCursorPositionChanged() {
QTextCursor c = textCursor();
set_cursor_tip(c);
if (fixedPosition > c.position()) {
viewport()->setCursor(Qt::OpenHandCursor);
set_editable(false);
clickable_message_line(c, true);
} else {
set_editable(true);
viewport()->setCursor(Qt::IBeamCursor);
}
if (pmatched.size()) {
pmatched.format_both(c);
pmatched = ParenMatching::range();
}
ParenMatching pm(c);
if (pm)
(pmatched = pm.positions).format_both(c, pmatched.bold());
}
/** strict control on keyboard events required
*/
void ConsoleEdit::keyPressEvent(QKeyEvent *event) {
using namespace Qt;
...
bool accept = true, ret = false, down = true, editable = (cp >= fixedPosition);
QString cmd;
switch (k) {
case Key_Space:
if (!on_completion && ctrl && editable) {
compinit2(c);
return;
}
accept = editable;
break;
case Key_Tab:
if (ctrl) {
event->ignore(); // otherwise tab control get lost !
return;
}
if (!on_completion && !ctrl && editable) {
compinit(c);
return;
}
break;
case Key_Backtab:
// otherwise tab control get lost !
event->ignore();
return;
case Key_Home:
if (!ctrl && cp > fixedPosition) {
c.setPosition(fixedPosition, (event->modifiers() & SHIFT) ? c.KeepAnchor : c.MoveAnchor);
setTextCursor(c);
return;
}
case Key_End:
case Key_Left:
case Key_Right:
case Key_PageUp:
case Key_PageDown:
break;
}
you can see that most complexity goes in keyboard management...
/** \brief send text to output
*
* Decode ANSI terminal sequences, to output coloured text.
* Colours encoding are (approx) derived from swipl console.
*/
void ConsoleEdit::user_output(QString text) {
#if defined(Q_OS_WIN)
text.replace("\r\n", "\n");
#endif
QTextCursor c = textCursor();
if (status == wait_input)
c.setPosition(promptPosition);
else {
promptPosition = c.position(); // save for later
c.movePosition(QTextCursor::End);
}
auto instext = [&](QString text) {
c.insertText(text, output_text_fmt);
// Jan requested extension: put messages *above* the prompt location
if (status == wait_input) {
int ltext = text.length();
promptPosition += ltext;
fixedPosition += ltext;
ensureCursorVisible();
}
};
// filter and apply (some) ANSI sequence
int pos = text.indexOf('\x1B');
if (pos >= 0) {
int left = 0;
...
instext(text.mid(pos));
}
else
instext(text);
linkto_message_source();
}
I think you should not use a static variable (like that appearing in your code), but rely instead on QTextCursor interface and some status variable, like I do.
Generally, using a QTextEdit for a feature-rich terminal widget seems to be a bad idea. You'll need to properly handle escape sequences such as cursor movements and color mode settings, somehow stick the edit to the top-left corner of current terminal "page", etc. A better solution could be to inherit QScrollArea and implement all the needed painting–selection-scrolling features yourself.
As a temporary workaround for some of your problems I can suggest using ui->textEdit_console->append(toPrint) instead of insertPlainText(toPrint).
To automatically scroll the edit you can move the cursor to the end with QTextEdit::moveCursor() and call QTextEdit::ensureCursorVisible().

How to get the text of a combobox in a tablewidget?

I’m new to Qt, I need help with getting the value of a combobox in a table widget.
I use “setCellWidget” to add a combobox(in my case, its name is “settingA”) to a table widget (the name is “tableWidget_4”):
QComboBox* settingA = new QComboBox();
settingA->addItem("100");
settingA->addItem("200");
ui->tableWidget_4->setColumnCount(1);
ui->tableWidget_4->setRowCount(3);
ui->tableWidget_4->setCellWidget ( 0, 0, settingA );
What I want to do here is:
When a button (its name is “ApplyComboButton” in my case) is clicked, I want the value of the combobox(settingA) can be saved into a QStringList(InputComboData) , and this is how I try to do this:
void MainWindow::on_ApplyComboButton_clicked()
{
QStringList InputComboData;
InputComboData << ui->tableWidget_4->item(0,0)->text();
}
And it fails.
How can I get the value of my combobox?
You can use the QTableWidget::cellWidget ( int row, int column ) function to get your QComboBox widget. Use qobject_cast to cast it to QComboBox, and use the currentText() function to get the text.
QComboBox *myCB = qobject_cast<QComboBox*>(ui->tableWidget_4->cellWidget(0,0));
InputComboData << myCB->currentText();
Use QTableWidget's cellWidget to get a QWidget* to the widget you set as cellWidget (don't forget to use qobject_cast or dynamic_cast to cast that pointer to a QCombobox*)

Resources