I have a QTableWidget.
I have a problem with sorting files and folders.I have tried out the following meethods:
ui.table->horizontalHeader()->sortIndicatorOrder();
ui.table->sortItems(columnNumber, Qt::AscendingOrder);
Suppose my first column consists of files and folders.How do I ensure that, folders always remain on top and files remain after the folders?
Do I need to implement some kind of boolean operator " < " for QTableWidget class.
Thanks in Advance!
You should not be using QTableWidget for files and folders, because the number of files and folders is not known. QTableWidget's performance with a huge number of items is bad.
You should learn how to do Model/View programming, and in the link there's an example on how to deal with files.
With model view, you have a view that takes information from a model. The model can be (almost) arbitrarily huge, and the view doesn't care because it only loads what it's viewing. This is unlike QTableWidget which loads everything all the time, and causes performance hick-ups.
Now regarding your question about sorting, you should use QSortFilterProxyModel, which you set as a model for your view, and you set inside QSortFilterProxyModel a source model. The proxy works as a middle-man between your view and the model, and can sort and filter the information before passing it. That's the right way of sorting tables in Qt.
Yes, you can overload <() operator and implement a sorting logic.
class CustomTableWidgetItem : public QTableWidgetItem
{
public:
CustomTableWidgetItem(const QString txt = QString("0"))
:QTableWidgetItem(txt)
{
setTextAlignment( Qt::AlignCenter ); /* center the text */
}
bool operator <(const QTableWidgetItem& other) const
{
/* Implement logic here */
/* e.g if(column == file) return true; */
/* else return false; */
}
};
Then use new CustomTableWidgetItem instead of new QTableWidgetItem. Read my other post to see how it's done on a widget.
Performance note: If you have many rows use the model view approach, if you just deal with a couple of rows QTableWidget should be fine. If you notice the sorting will take a couple of seconds it's time to switch.
Related
The context
In a wxWidgets (version 3.0.2) C++ application, I am trying to hide the first column of a wxListCtrl.
I did not find a member function to do this so I tried to set the width of the column to 0:
myListCtrl->SetColumnWidth(0, 0);
first argument being the column ID and second one the width in pixels (wxListCtrl documentation).
After running the program, the header of the first column is hidden as I wanted but the data of each row of the first column overlaps the data of each row of the second column (which is not hidden). It is obviously not what I want. The header and the data of the first column should be hidden.
The question
In wxWidgets 3.0.2, is there a way to hide the first column (header and data of each rows) of a wxListCtrl?
I don't believe you can. You have a few options.
Delete the column using DeleteColumn(int columnIndex). You aren't losing any data, just the display of it, so you can always re-insert the column and repopulate it if you need to re-add it. Obviously this could be time consuming if your data is excessively large.
Depending on your application, just don't create the column in the first place. You don't say why you want to hide it, so if you just don't want it, don't add it.
Implement your control as a virtual control which gives your application control over what to display where. The burden of data display management falls to you to do manually but you have a great deal more flexibility. Inherit the class with wxLC_VIRTUAL style and implement OnGetItemText http://docs.wxwidgets.org/3.0/classwx_list_ctrl.html#a92370967f97215e6068326645ee76624
Edit:
To expand on the comment question, how to get the selected item index:
The wxListCtrl is a little weird when it comes to selected items. I'm sure it has to do with needing to support report, icon, etc. different views. When dealing with a multi-column report mode, you might find that you can only select items in the first column. If you are on Windows, it should automatically be set to "Full Row Select" but I don't know about other OSs.
Anyway, here is a utility method that returns the first selected item (note that you can support multi-selection if you want to).
//Get the item currently selected
int ListView::GetItemSelected() const
{
for(int i=0; i<GetItemCount(); ++i)
if (GetItemState(i, wxLIST_STATE_SELECTED) == wxLIST_STATE_SELECTED)
return i;
return -1;
}
If you want (and it makes sense), you can connect the list item selected event.
this->Connect(wxEVT_COMMAND_LIST_ITEM_SELECTED, wxCommandEventHandler(ListView::selected_Changed), NULL, this);
and within that event handler, get the selected item and do what needs doing (depending entirely on your application).
You will note that I'm using a derived class here which just makes things a lot easier but you don't have to. You can connect to something like MyMainForm::sqlResults_selectedChanged or whatever.
There is more than one way to accomplish all this and you can also find some good suggestions and help here: https://wiki.wxwidgets.org/WxListCtrl
Quick question
Is there an easy/quick way to map a QListWidget or QStandardItemModel (for QListView) item to my application logic?
Complete Question
Note: I will use undistinctly both QListWidget or QListView and itsQStandardItemModel. From my current point of view for this question, switching from one to another is trivial.
I face usually the need to have a QListView or equivalent in an HMI, which shows some text value and need to react on selection/click.
In the SLOT, in order to perform the required action, the row need to be identified. Qt::DisplayRole is NOT appropriate because some texts could be duplicated and QStrings are not the best way to identify data in Computer Science.
// Click on a row
connect( &myView, &QListView::clicked,
[&myView, this]( const QModelIndex &idx)
{
// E.G. need to update the database for this row. Which row?
});
Possible solutions:
Maintain a map to retrieve the ID from the QModelIndex row.
Save in the model row any ID, making easy to apply any operation.
First option is tedious: it requires to connect the model for keeping the map and the model synchronized.. Same logic again and again.
Second option seem by far the best: I save the (e.g. database id) and use it afterward; But, QListView model (up to what I know) does NOT include this very friendly and useful ID. So until now I had extended again and again the models for QListView.
How to map the QModelIndex back to my application logic? Do I really have to extend the model for that simple operation?
RELATED QUESTION: QTreeView: maintaining mapping between QModelIndex and underlying data
What about creating the QAbstractModel manually, this way you have complete control how the QModelIndexes are created, and you can use that to do stuff.
I'v implemented thousands of Qt Models, and I have never liked the QStandardItemModel approach as I would usually need to write more boilerplate than if I had come with the model myself.
Inherit from your QAbstractList/Table/TreeModel
implement index()
create a method for direct item access
.
// Click on a row
connect( &myView, &QListView::clicked,
[&myView, this]( const QModelIndex &idx)
{
auto& myItem = idx.model()->directAccess(idx.row());
});
profit.
I would like to know how to achieve mouseover on a cell, if a column is too short for full text.
So, if I have column with fix width, and text is too long, how to present whole text with mouseover in a cell.
You can dynamically add a mouse over tooltip on any cell by overriding the
execDecorateCell(Cell view, ITableRow row, IColumn<?> col) method in AbstractTable and setting your tooltip text like
#Override
protected void execDecorateCell(Cell view, ITableRow row, IColumn<?> col) {
super.execDecorateCell(view, row, col);
view.setTooltipText("Hi there: " + view.getText());
}
Unfortunately, this does not consider if your text length exceeds the length of your column/cell. It will set the tooltip text in any case! So far, I am not sure, whether (or how) it is possible to calculate (in pixels?), if the actual string length inside a cell exceeds ones column length. Maybe you could try something, that takes the actual string length into account (java.lang.String.length()) and only provide a tooltip if a certain length is given.
Let me know, if this is works for you!
Best regards,
Matthias
The tooltip for truncated text in a table cell is currently only shown if it is not possible to resize the column. This is done by purpose because the tooltip may be very annoying. The code responsible for this is in the file Table.js:
scout.Table.prototype._isTruncatedCellTooltipEnabled = function(column) {
return !this.headerVisible || column.fixedWidth;
};
If you don't like this behaviour, you could adjust the JavaScript code. There are mainly two ways for doing this:
Replace the original function
Extend the table and override the function
With the first approach you replace the actual function, so everytime a scout.Table gets created this function is used. With the second approach you need to make sure your new table is used. In order to do this you need to specify a mapping between the object type and the constructor which will be used whenever an object should be created using scout.create(objectType). This is normally done by convention, so if you write scout.create('Table') a new scout.Table will be created. Because you now want to create a custom table you need to add the mapping to scout.objectFactories.
For me, the first approach feels more like patching, whereas the second one is a cleaner solution. The advantage of the second solution is that the original object stays untouched and you could, at least theoretically, still create regular tables. That's why I suggest to use the second approach. But in the end it is probably a matter of taste.
In both ways, you need to create one or more JavaScript files, register them in yourproject-module.js and include this module in your index.html. The files could look like this:
Approach 1:
patches.js
scout.Table.prototype._isTruncatedCellTooltipEnabled = function(column) {
return true;
};
Approach 2
CustomTable.js
scout.CustomTable = function() {
scout.CustomTable.parent.call(this);
};
scout.inherits(scout.CustomTable, scout.Table);
/**
* #override
*/
scout.CustomTable.prototype._isTruncatedCellTooltipEnabled = function(column) {
return true;
};
objectFactories.js
scout.objectFactories = $.extend(scout.objectFactories, {
'Table': function() {
return new scout.CustomTable();
}
});
Remember: The scout JavaScript code is not api and may change anytime. You won't get compile errors if the function will be renamed as you are used to with java. So before adding a lot of custom JavaScript code to adjust the default behaviour you should consider opening a bug first so that it can be fixed in Scout. It could help others as well.
I have a list with about 2500 custom items. I set them with:
const std::vector<const Items::AbstractItem *> results = _engine.request(text);
if (!results.empty())
{
for (auto i : results){
QListWidgetItem *lwi = new QListWidgetItem;
_results->addItem(lwi);
ListItemWidget *w = new ListItemWidget;
w->setName(i->name());
w->setTooltip(i->path());
_results->setItemWidget(lwi, w);
}
_results->setFixedHeight(std::min(5,_results->count()) * 48); // TODO
_results->show();
}
This takes about 5 seconds on an i5-4590. Hiding the widget is twice as fast. Is this normal or do I have look for errors?
A few ideas:
Try assigning proper parents to your QWidgets, thats way the layout doesn't have to do this
mapping for you. This should help performance.
Call setUpdatesEnable(false) before starting the insert, and to true after it's done
As for hiding the widget while adding large amounts of items, this will help to alleviate extraneous update calls. The second suggestion above should mitigate that.
I think this is fully expected behavior for controls like Lists or Trees that are not based on any data model. And I believe that the data model was invented mainly to fix this issue.
In your situation you have a ListWidget control that stores its data on its own. You need to pass all 2500 items before your app can go on, and you need to do this even if your list shows only 10 items at a time. Even if you just run and close your app, the user won't see all the items but you still need to pass them to your ListWidget. Some GUI frameworks use internal allocation of items and in such case they can optimize things a bit, you could do the same if you allocated your Items in chunks but it's still not a good solution.
Now let's say you introduce some object that could be asked about item properties. The Control will ask about some item and your object will respond with the contents. Your object don't even need to know about all your items, it will just learn when needed.
You Control can ask about few first items and stop when it realize it can fill up its entire height. This way you can avoid work that is not needed for now. The Control can also ask about the item count, so it can set-up its vertical slider.
It needs to be said that the model will not solve your problem automatically, it's just a programming paradigm that allows you to do it better.
So the solution for you would be to replace your QListWidget with a QListView and implement you own data model inheriting QAbstractListModel. You could pass the results to the model and it will pass the items data when needed.
If your QListWidgetItem's always has fixed size, call setUniformItemSizes on your QListWidget, pass true.
I am not sure how to go about this big data problem. Instead of using a Table Widget, it is suggested to use a Table View for big data for speed. The data will be at most 200000 rows by 300 columns of strings. Also, it might have gaps in the structure. For the View, it is needed to define a Model. I was not able to do this yet and I wonder the following:
Will it really be faster to use a View if the user only wants replace some values in a column, and inspect the data? Is a QList a smart choice given speed needs, or are there better options? And how to implement this as a Model?
A QTableWidget uses its own Model as backend (container for its data). One can't (or it is not intented that one should) customize a QTableWidget's model. Each cell in a QTableWidget is represented by a QTableWidgetItem. They are written to solve general problems and are not that fast.
When one decides to use a QTableView with it's own model deriving from QAbstractTableModel as backend, one can speed things up allot. I've found that one of the things that took the most processing time was the size calculation of rows. I overloaded sizeHintForRow in my table like this:
int MyTable::sizeHintForRow ( int row ) const
{
//All rows have the same height in MyTable, hence we use the height of the
// first row for performance reasons.
if( cachedRowSizeHint_ == -1 )
{
cachedRowSizeHint_ =
model()->headerData( 0, Qt::Vertical, Qt::SizeHintRole ).toSize().height();
}
return cachedRowSizeHint_;
}
Implementing a simple table model is quite easy (Qt Help files are adequate...). One can start by providing the data for the minimum roles (Edit and Display). TableModel data can always be modified by using QIdentityProxyModels where necessary. If your models don't work, post your code. Remember to not return invalid data for roles e.g:
QVariant IO_PluginMngr::data(const QModelIndex & index, int role) const
{
if( index.isValid() )
{
if( role == Qt::DisplayRole)
{
return sequence_[index.row()][index.column()];
}
}
return QVariant();
}
Returning for example erroneous data for especially SizeHintRole will cause havoc in the views.
I've noticed that one should, when implementing models, be diligent in calling begin/endInsertRows when appropriate, otherwise persistent model indexes don't work.
We've written more complicated tables where the data is modified in threads in the background, and swapped out prior to updating the table. One of the areas in which one could have speed improvement, is to never order the data in your model, but rather use an ordered reference sequence that references the real (unordered) data. We have tables that have about a thousand rows and 50 columns that get updated once a second (with many views), and the processor our processor is sitting a about 20%, but the greatest speed improvement was the caching of the sizeHint.