first post to StackOverflow, though I've been finding great tips for a few years here. Hope to resolve a vexing problem with handsontable.
I have an application that presents a handsontable instance with several columns whose content/format is dependent upon the value in a cell in another column. I determine the content and format of the dependent cells by way of a database query and server-side processing, the results of which are sent back to handsontable for processing in the afterChange function.
My problem is that whenever the user updates one cell in the table, ALL cells blink while the code laboriously reconsiders the formatting for ALL cells in the table. The preferred behavior would be to ONLY update the cells for which the formatting has changed, i.e., that small set which is dependent on the value that changed in the first cell. It's only these dependent cells whose contents are being changed anyway. Why redraw the WHOLE table??
I have searched and search here and elsewhere, and the closest to an answer I could find is that this is the intended behavior for the table. I don't agree...when the table is anything larger than 10 rows, the updating process is painfully slow and distracting to the user.
Any suggestions? I'm open to directly editing the handsontable js code, but would prefer to flip some flag I'm unaware of if possible.
Thanks all!
afterChange fire only one time for the cell you just updated (documentation example).
Your problem might come from an afterChange "chain reaction". The first afterChange modifies one or more related cells, triggering others afterChange and so on. If that's the problem, you can put a filter on the source parameter.
Another solution could be to work on a copy of the data to do your updates (see data binding), and once everything is fine, inject it back on the table with loadData, and ignore the loadData source in the afterChange callback.
Finally, if you still have some performance issues, you can check the performance tips, and remove any option that might slow your table (example with columnSorting)
(sorry I can't use comments to identify precisely from where your issue come...)
Related
In my slick grid I have a non editable column, can we make the cell editable while adding the new row.
I have looked into onBeforeEditCell event but that's kinda helpful when making a editable cell non editable.
The thing that determines whether a column can be edited is whether it has col.editor defined.
You could alter this using something like grid.getColumns()[3].editor = Slick.Editors.Text (set to null or undefined to remove).
You'd have to detect the moving to a new row to decide how to set the editor. The onActiveCellChanged event seems like the best place to do this, but note that internally, editing mode decisions are already made by the time this event is called - see the internal function setActiveCellInternal. You might be best off declaring a new event and putting it earlier in that function, or moving the existing one up.
This is not a use case I think would be very widespread.
Note my repo is worth trying for the many updates and bug fixes it has over the now unmaintained original MLeibman repo.
I have a model of about 1000 rows, with one of the columns changes every second.
I placed a cusom sort/filter model between the real model and the table view so as for the rows to be filtered immediately after they changed.
Now comes the problem:
If nothing is selected in the table view, everything just works fine; but when I have selected some rows, the table becomes lagging. The more rows selected, the more lagging it is.
Why? hope some one could give me a hint, thanks in advance!
Sorry, but there is a whole lot of potential places where performance can go down in QTableView.
The easiest way to pinpoint the slowdown is to profile the application. If you have the call(s)
that eats the cpu, it's far more simpler to deduce what is the cause and fix it.
Also you don't say much about the design of the custom sort/filter proxy. If you use QSortFilterProxyModel beware it does not scale well.
While painting the (top) header for a table with selection enabled, the function:
bool QItemSelectionModel::isColumnSelected(int column, const QModelIndex &parent) const
is called (twice for each column - but may vary on selection mode).
This function iterates through all selected rows (Line 1333 in "qitemselectionmodel.cpp" Qt 4.8.5).
So if there are many rows selected, the paint for each header column will get really slow.
Same for left header with cols/ rows switched.
The called functions are mostly not virtual - so there seems to be no way to avoid this without completely drawing your own header or hiding the header.
Maybe Qt should optimize this.
I am drawing the GUI using GTK+ with PyGTK.
I've created a ComboBox within a TreeView. But the problem is that when I first click an item, the dropdown arrow is insensitive (grayed-out). I had to click another item and then return to the item again to for the dropdown arrow to be sensitive again.
Is this standard for ComboBox in TreeView? If you have a fix in any other language, I can accept it as well.
An example can be found here.
He is facing some other issues but his code demonstrates the problem as well.
The problem with the code you are referring to above seems to be that the ComboBox actually only has 1 element when you start editing, which makes drop-down feature useless (and hence inactive). To make it behave as I suspect you wish, all you have to do is use another signal to execute self.populate_combo. I added two lines after the treeview was created to make it work:
treeview = gtk.TreeView(liststore_hardware)
sel = treeview.get_selection()
sel.connect("changed", self.populate_combo)
That is, I made the changed selection cause population of the Combos, which implied that they had more than one element in them when control was returned to the main-loop. And hence drop-down worked.
I also commented out the previous editing-started signal since it added nothing with the current structure of the program.
window.connect("destroy", lambda w: gtk.main_quit())
#self.cellrenderer_combo.connect("editing-started", self.populate_combo)
self.cellrenderer_combo.connect("edited", self.combo_changed, liststore_hardware)
Edit:
On second thought, the model is a None after __init__ has been run and not 1-length per row as I wrote above, which makes the lack of dropdown-features even more reasonable.
Comment:
The code you referred to and my change to it are both only rational if changing rows (or editing) causes a drastic need to rewrite the ListStore. I'm not really sure what type of scenario would demand that. If, on the other hand, the contents of the TreeView and the ComoBox' ListStore varies as a result of a search-action or filtering done else-where, then that search, rather than the change of rows should invoke populate_combo.
So an alternative solution in the scope of the code at hand, my suggested event above can also be commented out and a simple
self.populate_combo()
be added as the last line of the init function.
Further, should there be a need to re-populate the combos during the run of the app, I would suggest that the current ListStore is modified rather than creating a new one each time, if the changes are not expected to be major (in which case make a new is probably fastest and simplest).
I'm working on some legacy code. I have a user control with a VtChart (VCI First Impression Library) in it and I'm trying to make changes to it, namely, adding another series to the control. However, every time I make changes to the control, close the form editor, then reopen it, the changes are gone.
I can't find any documentation on this control, so thought I'd ask the community, any ideas?
Ah! Found my answer. Since VtChart is connected to a grid (F1Book), the SsLinkRange needs to correspond to the number of columns needed in the chart. For example, if you want 3 columns, SsLinkRange should be A1:C10, where A and C is the column range. If the SsLink properties don't match it won't save the settings.
This is an very obscure problem, but I'll post this answer anyways for archiving.
It's a longshot that anyone can help with this, but here goes. I inherited a VB6 app with a Janus GridEX control. It iterates through records, and is editable. Problem is, if I edit a cell and hit the button to go to the next record, the change is applied to the next record, not the one I was editing. It's like, I need it to finish up the edit before going to the next record. I've had this sort of problem before in VC++, and sometimes you have to "KillFocus" on the control you're on or something. I just don't know what to do here. I tried sending a carriage return, since if you return out of the edit cell, it works, but sending a carriage return manually doesn't work. What's the secret?
Is your grid bound or unbound?
It's hard to tell from your description, but I imagine that if your are having this problem then it's probably bound.
As the other answer asked, is the button the RecordNavigator that is built into the control or is it a separate button? The reason I bring this up again, is that I have seen issues in the VB6 applications I support where a toolbar will often intercept and interfere with how the JanusGrid should work.
To get around this limitation, I have added the following code in the click handler of any toolbars where there is also a JanusGrid control on the form.
If jsgxYourGridName.EditMode = jgexEditModeOn Then jsgxYourGridName.Update
This way any changes are immediately applied to the current row.
If this does not help, then I have also seen problems where the recordset that is bound to the grid gets out of sync with the internal recordset in the grid. You can check this by comparing the bookmark of the grid to the bookmark of the recordset.
Ie. mrsYourRecordset.Bookmark = jsgxYourGrid.ADORecordset.Bookmark
At one point I may have also used something like this.
jsgxYourGrid.ADORecordset.Bookmark = jsgxYourGrid.RowBookmark(jsgxYourGrid.RowIndex(jsgxYourGrid.Row))
Finally you can try setting a breakpoint in the BeforeUpdate, RowColChange and/or AfterColUpdate events of the grid, to see what record the grid is really on when clicking on the button.
It depends whether the button is internal to Janus GridEX or not. If it internal then just about the only thing you can do is look at the events the control exposes to see if there a sequence that can let you know that this problem occurs. Then you can try to take corrective action by restoring the row you moved to and put the edit in the row you left.
If the button is external to Janus then you can use the debug mode to trace sequence of statement that control the transfer of focus to the next row. It could be something out of order or a side effect of the particular sequence of commands. I have run into both with different controls.
Remember that you can edit while in debug mode so you can try different approaches and test until you find one that works.