I'm currently trying to apply a filter to the wxCheckListBox (for a search of specific elements). So far i have no idea how to do it. The Problem with it is, that I don't want to have a copy of the Control and always delete the unnecessary items from the copy, and as soon as the search changes it has to be copied again from the original and delete the items again. I was wondering if there is a way to simply hide some items and not the entire control
You can't hide the items in a wxListBox or wxCheckListBox. To have this sort of dynamic control over the items appearing in the control you need to use wxListCtrl in virtual mode.
However it's not usually really a problem to delete some items from a wxListBox and then insert them back (or, even simpler, store all the items, delete some of them from the control and then, to revert, clear the control and restore all the initially stored items).
Related
I have the following small issue. A pretty old MFC application being ported to C++11. There is a MFC CListCtrl in report view the data in which is being refreshed by a separate thread. Either manually or via a timer. The current implementation sets m_ListCtrl->SetRedraw(FALSE); deletes all items then populates them back again. This causes a flicker. Also internally the items are sorted via GetItemData DWORD, setting each list items new position after sorting. The state of sorting is internal to CListCtrl.
What is the best design pattern to add new, update or remove deleted list items after the table has been modified? I am thinking of hashing the contents of the list item row, keeping a separate vector<RowObject> table current and after refresh and comparing hashes. Is this a right approach?
Or may be use m_ListCtrl->SetItemText on existing items? But how to deal with sorting in this case?
following scenario:
I have a Firebase database containing a list that is used to create a set of "paper-cards" with dom-repeat:
<template is="dom-repeat" items="{{items}}">
<my-element card="{{item}}">
<paper-card id="{{card.id}}">
...
</paper-card>
</my-element>
</template>
In the UI, the user can add or delete paper-cards, so items also get deleted in Firebase.
Now I realized if I change the CSS of an element (e.g. fadeIn, fadeOut animation) and afterwards delete a card and later add one card, the card still has the CSS state as it was before (e.g. for fadeIn/fadeOut animations).
My questions:
How does DOM repeat deal with elements added or removed? Is not all information of this element "deleted"?
If I delete item #5 (out of 10), what happens to elements 6-10, are they deleted and re-created as "5-9" or "moved/altered"?
Besides CSS, are there any other implications that should be considered inside the template tag? Do I need to manually reset anything?
You can read about the dom-repeat on https://www.polymer-project.org/1.0/docs/api/dom-repeat but what it basically tells you that it tries to be too smart without asking the developer if it wants that behavior. The dom-repeat is heavily flawed because of this.
Polymer is saving performance to doing a dirty check, basically looping through everything and only changing the DOM if the checked values (id, in this case) changes. This means that it will inherit other values.
Basically, it wont update sub-properties. This means that dom-repeat isn't really made for any kind of update.
You can possibly go around this issue by using Polymer's this.splice(). It works like the splice in javascript but sends out an event to dom-repeat to update and where to update. Remember however, that arrays in Javascript are references, so if you take this.items and try to modify it, it will automatically update values the dom-repeat (without updating DOM) and then it will dirty check the update with the new values and not change anything at all. If you want to modify the array in the dom-repeat, then use JSON.parse(JSON.stringify(array) first to get rid of the reference.
Another thing you can do is to use the unique id. If the id changes for that specific card, then hard reset all values and initialize that specific card once again with all it's normal properties (including CSS). That's the workaround I use all the time.
The desperate thing to do, when nothing else works, is to nullify the array that keeps track of the cardset, with this.set('items', []) and then set the property with the new array.
The repeater evaluates the number of items in your array on initialization and stamps that many template instances into the DOM. If you delete an item from your array the repeater is presented with a new array that is one element less, removes the last one and propagates data change to elements' instances.
So if you start with 10 elements and order to delete #5 then element's #6 data is inserted via data-binding into the same DOM node that previously contained #5 data, and so on down the list. The last DOM node for which the updated array contains no data will be removed from the DOM tree.
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 basically want to have the same virtual performance I can get with a List-View control. With a List-View control you can set an ItemCount and in the LVN_GETDISPINFO notification you then fill in the information for the items once they are scrolled visible.
Now, the virtual functionality the Tree-View provides is good for very deep trees, so you would only add items once a node expands (via TVN_ITEMEXPANDING), and TVN_GETDISPINFO can be used for filling in item information once the item is scrolled visible. But what to do if you have an "always expanded" two-level tree (just for design matters) where TVN_ITEMEXPANDING wouldn't be of any use and only want to add the items once they would be visible. The problem is, there's no such thing as SetItemCount() or similar to already resize the tree.
In my case, the filling of item information (text, image, selected image) isn't the expensive part, but the inserting of items (all at one level) is.
One option would be to only insert the items which would be visible plus one invisible one, once the invisible one gets visible (detected in TVN_GETDISPINFO), I'd insert a few more and so on. But then the scrollbar would always get smaller the more I scroll down, I think that's weird.
Are there any other ideas to achieve what I want except from drawing my own control?
The whole tree would just look like this, pretty much a list, it's just that I like the tree-look.
RootNode
|
|--Item 1
|--Item 2
|--Item 3
|--Item 4
|--Item 5
|--Item 6
|--Item 7
...
|__Item 1000
As stated in many other posts, the really expensive part about the Tree-View control is using InsertItem and DeleteItem. A quick way to improve performance for those operations is making use of SetRedraw. Not only does it hide the flickering but does really speed things up, since the drawing seems to be expensive - even though TVN_GETDISPINFO is used.
Also, it's faster to rename existing items and change their data instead of deleting and adding new ones. So when I have a big list and know that the next update will contain about the same amount +/- a couple ones, I go iterate through the items, rename them, change their lparams and sync (i.e. remove/add) the remaining ones in accordance to the new data. Depending on the size of the list, making those extra calculations can have a huge performance improvement.
The Win32 TreeView control does not support the kind of virtual mode you are looking for. So you will need a custom control.
I am using a List Control to display a representation of elements within a vector. When the list is clicked on another control shows information about that element. The index of the element is currently determined by its index in the control, however if I wish to sort or filter the results this will no longer work.
I have been told that I could use a virtual list control, but the MSDN is not very friendly, can someone run me through how I could use a virtual list control for this?
Frankly - tying data (the position in your data vector) to the presentation of the data in the list control (the position in the list ctrl) is something I would stay away from.
In MFC each control has a "Data" DWORD member variable - when coding in MFC I Always called "SetItemData" for each item added and passed in a pointer that the relevant row referred to e.g.
YourListCtrl.SetItemData((DWORDPTR)&YourData);
Then when the ListCtrl item is selected, you just call
DataTypeYouWant* pData = (DataTypeYouWant*)(YourListCtrl.GetItemData(indexofselecteditem));
Or somesuch thing.
Alternatively - if you don't want to use pointers - hold the index of the item in your original vector in the itemdata for your row (just pass it into the above fns).
To use a virtual list control, set the LVS_OWNERDATA style. You then need to handle the LVN_GETDISPINFO notification message (which is sent via WM_NOTIFY).
If you do this, you are entirely responsible for the data, including the order in which it is shown. Therefore it is up to you to handle sorting and so forth.
By far the easiest way is just to use the item data to set/get an ID that can be used to retrieve the original data, whether that's a vector index or a pointer to the data, or even a key into an associative container.
It really depends on the performance you require.
I have personally seen MAJOR increases in performance for lists holding massive amount of data. However it is much more work to implement, thus for simple uses with not so many data I recommend staying away from it.
Basically, what happens with virtual list controls is that you have your data somewhere in some data structure of your own. Since the list view shows only a small subset of the whole data, it queries you for the content to display when ever something happens (redraw necessary, scroll up or down, change the sorting, etc.).
I don't have handy examples for you. But you can look on codeguru, I am quite sure there are very good examples to start from.
The purpose of virtual list controls is totally different: You should use it for performance reason when you have A LOT of items in your list (I'd say 2500+).
In your case, all you need is to store the vector index in the list item data as NotJarvis explains.