Without getting into unneeded detail, I'll try to explain the basic issue I'm having. I'm evaluating Kendo-UI Web and working with the Grid.
I do some page column re-sizing based upon the grid having detail rows expanded or not.
The behavior that I'm noticing is that the VERY first time "detailExpand" event is triggered per row, you can see the DOM being updated with the new elements BEFORE my code in detailExpand runs. I'm guessing that this is actually just detailInit running since it's the first time the row is expanded. After that however, if I expand the row again, detailExpand event runs first, before the row shows up. (The code appears as though it's simply doing a .show().. This means that I can't properly calculate the change in height.
Same with detailCollapse. The event code fires before the detail row is hidden. So I end up with extra space equal to the size of the detail row. If they were always the same size, this wouldn't be a problem, I could just anticipate the size and reduce or grow based on that. That is not the case.
So to boil it down, if I could simply have an AfterRowExpanded Event, it would solve everything.
I feel I can customize the kendo ui JS easy enough, but then I have to re-minimize the JS and all that.. Any thoughts?
With the latest version to me it seems that the detailExpand is triggered when the detail row has finished expanding, however the detailCollapse is executed before the detail row is hidden.
As a work-around I would suggest you to slow down the execution of your logic with the help of setTimeout without specifying miliseconds (it will be executed just after the row is actually hidden / shown)
e.g.
$('#grid').data().kendoGrid.bind('detailCollapse',function(e){
setTimeout(function(){
//code goes here
})
})
Related
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...)
I have implemented a slickgrid and activated keyboard navigation.
When the users is scrolling down using the down-arrow key and reaches the last of the currently visible rows, the grid loads a whole new section of rows and places the selection at the top.
My user tests have all included a complaint about this behaviour as they all find the jump jarring.
I would like to implement behaviour, so the grid scrolls just one line at a time, when I press the down arrow while the last visible row is selected.
I was wondering if there might be some setting, I have overlooked, or if anyone has some suggestions for how to approach the task of adding this behaviour.
(the "problem" is the same, when you scroll upwards - only reversed of course)
This is controlled by the doPaging argument in scrollRowIntoView(row, doPaging) (https://github.com/mleibman/SlickGrid/blob/master/slick.grid.js#L2662). There's no setting to control that behavior, but you could easily add one.
It was initially written this way to make keyboard navigation faster since continuously navigating down doesn't have to do as much work as it would have if we were updating the grid on every 'row down'.
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).
there
I found that when quickly swiping or flicking the pivot, the pivot will become very obtuse.When the finger off the screen the pivot still traslate between pivotItems a few times.
Is there any way to make the Pivot performance like the Panorama in the situation of quickly swiping or flicking.
I encountered the same problem which was due to using more than 5 tabs each with databinding on them. Each time I swerved to a new page the databinding was triggered thus causing a noticeable delay. (If you keep swirving these requests create a backfill this eventually resulting in multiple background threads for each pivot tab)
I fixed this by collapsing the data on the tabs and only revealing it when the tab was shown for more than 3 seconds. This greatly reduced the databinding and thus data loading. Inmy case though I did have to resort to this because I used the tabs as ways to navigate through dates thus I was facing a potentially limitless collection and had to cycle data across my 5 available tabs. (Microsoft recommends against using more than 5 tabs).
If you have a finite set of less than 6 tabs an easier approach would be to set data binding to ‘one time’ to populate the data. If you have items on the tabs that rely on allowing a control to not just display but also update a value you can always trigger the databinding through that controls events. (be sure to not just use the updated method but also the page.navigateaway event to trigger databinding as navigating away from a page right after updating the value of a control won’t trigger the control.updated event)
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.