I have a grid in ExtJS 6.0.2 that can be set to auto-refresh (it reloads once every ~10 seconds), but when it does, I want it to stay where it is instead of scrolling to the top each time. We have successfully used preserveScrollOnRefresh to do this with other grids, but for one particular grid, it's not working. In order to try to get it working, I decided to try calling getScrollY() before reloading the store and setScrollY() after, but that didn't work either. When I stepped through with the debugger, for some reason, getScrollY() returned 0 even when I had the grid scrolled all the way to the bottom.
Is there anything else that I can try?
it sounds like this is working for other grids in your app, so without seeing any code I'd suggest that something with that store/grid ecosystem is not configured the same as other grids in your app.
perhaps post a fiddle (fiddle.sencha.com) with an example, that may also help you find your answer if the fiddle works.
Related
I'v run into an preformance releted problem with a DataGrid in an Sliverlight 4 application that I'm currently working on.
In our application we have a DataGrid which is quite huge, up to 4000 rows.
Its obviously extreamly slow to scroll a grid this big. Lets say you grab the tracker in scrollbar at the top and drag the mouse courser to the bottom. The tracker eventually reaches the bottom but it takes a few minutes.
It seams like Silverlight wants render ALL rows that it passes.
Using the ScrollToPercent method works like a charm though, so what I would like to do is to use ScrollToPercent when you release the tracker.
You follow? Lets say I grab the tracker and then I can move it up and down the scrollbar WITHOUT the view changing, but as soon as I release the tracker it should trigger a ScrollToPercent.
Did that make sense? Is this possible, or do you have a suggestion that in another way can help me solve this problem?
We build complex enterprise application using KnockoutJS and faced poor performance especially in IE8. Application might take more than 1GB of RAM and never frees memory. During investigation we discovered that KnockoutJS keeps references to the DOM nodes and never deletes it. This can be reproduced using IESieve against any public KnockoutJS example, just watch DOM utilization while playing with example which adds and deletes DOM nodes.
Have anyone faced this problem and has any ideas of how to work this out?
We had faced similar issues with knockout JS on IE 8. One of the problem areas was having an observable array (with 500+ elements) and building a UI (imagine a table like or list like structure) with all of those.
The only work around that worked for us was to change the view model so that it contains only very few items that could fit on the screen. Also, we had to add handlers for scroll events so that the observable array would keep getting refreshed. And (not too proud of this), we had to add an empty div at the top of the displayed records to give an illusion of the view having scrolled.
Probably to do with event bindings not being released when their DOM elements get deleted. If it's something thats happening under the hood with knockout, you will have to patch and submit a pull request.
I've had this kind of thing happen a lot with backbonejs too. JavascriptMVC is a bit better for cleaning up after itself.
I'm experimenting with creating a metro style app with Visual Studio 2012, I am not the most experienced designer but one thing with my applications is confusing me.
I have been working with 'basic pages' instead of blank ones for the different pages in my application for design consistency, however it seems that these 'basic pages' have a strange behaviour. Every item I place on the page (buttons, text boxes, etc) will all slide in one by one when the page opens. For example if I run the application and navigate to a page with 10 buttons, it will do a brief animation where each button will slide in from the right side to the left side. When dealing with a large number of items on one page this can take a lot of time as each item slides in seperatley.
Looking at the properties for each item I have been able to change the direction it slides in while loading the page by changing the flow direction. Also with a bit of research I am thinking it could potentially be due to either the metro style 'enterPage' or 'enterContent' animations, though I can not be certain.
I have tried to experiment and figure this out, and search to find out what causes this so I can modify it (Ideally I would like to just group items together to slide in with each other) however it's kind of a difficult thing to search with vague words, so I'm asking here.
What is causing this and how might I go about modifying it?
EnterPage shouldn't be sequencing the animations. They do offset some of the animations of a number of elements, but it shouldn't be each one sequentially.
Are you using WinJS navigation?
Well after a bit of experimentation I figured out that putting all my page content inside a grid made them all come in at once like I wanted. I probably should have tried that earlier but everything was already inside an outer grid for the page, so I thought that woulda handled it.
I don't quite understand it fully, but that works for now.
I'm just starting to use SlickGrid but I've had a lot of success creating a remote model that can interact with the paging plugin. The only problem I have seems to be a browser issue, but I'm curious if anyone knows a trick that may resolve the issue.
I'm retrieving the data page by page in my model via AJAX and updating the grid with the grid.setData() and grid.render() methods.
The problem I would like to solve is that when the length of data changes the vertical scroll bar gets really confused, unless I change the current visibility of the filter panel (grid.hideTopPanel() or grid.showTopPanel()). By confused I mean that the scroll handle in the scroll bar doesn't change size to indicate the different number of rows that are now current, and if the list grows, the scroll handle size jumps all over the place as I scroll up and down.
I'm assuming the "fix" works because it forces the browser to recalculate the view port height, but is there any way to force that to happen? Or is there a better way to do what I'm trying to do?
Ok mleibman straightened me out, what I actually was looking for was grid.updateRowCount(). I believe he will be adding a call to this in grid.setData(), but for now just make sure the 2 method calls are used together.
Have you tried grid.invalidate() ? Im my experience that forces the grid to recalculate pretty much everything. It may be more heavy-handed than you need but at least you can see if a complete invalidate solves the problem.
I figured it out. You need to call grid.resizeCanvas() after calling grid.setData(). It seems like this should be part of the grid.setData() method because a call to it will change the number of rows. But anyway, that's what you need to do.
Ok so this bug is very weird
here is my code, you can actually see this bug happening using fiddler
http://jsfiddle.net/LLMUX/13/
the code works fine as long as you don't go to a different tab. the code is a rotator. if you hover the links it will show the block the hover is assigned, then once you hover off it will resume the main rotation
produce the bug
- have the fiddler page open, you could copy the code into a file and try it, same thing happens
- with the fiddler page you can hover or whatever you want or do nothing
- open another tab, do whatever for a few seconds 5-10 should do
- go back to the fiddler page
- chances are you will see 2 blocks showing then eventually 1 goes away
this only happens if you are coming back from a different tab, if you stay on the page this will NEVER happen. I tried is safari, it did not happen I tried it on IE9 it did not happen! I tried this on FF 7 and 8, both with this problem.
If anyone have any idea on why this happens it would be greatly appreciated
Edit - might not happen 100% of the time
I bet your problem is the same as this: Jquery setInterval too fast when coming from another tab
Browsers try to minimize the performance hit of web pages being active when the user doesn't interact with them. One such optimization is setTimeout/setInterval "clamping": Firefox 5+ doesn't fire timeouts faster than once in 1s.
I see that your code only uses a 1300ms interval, but I guess jQuery's animation deals with being in background in a different way than your setInterval-based code does, but I'm not up to debugging this to know the exact reason it works like that.
See also Background Tab Animation and jQuery
(edit) and if I'm right, the way I'd try fixing it is to stop using setInterval to drive animation and instead to always use the jQuery's 'finished' callbacks to schedule the next slide via setTimeout: fadeIn --> wait 1s --> fade out --> fade in.