Can we reposition grid visible area?

[hgaglani]

Is it possible to have the grid set to any postion after invalidating the cache and refetch.. for eg instead of 0..75 can I set it to 100..150..??

I can see there is getDrawnRows[int,int] which gives the current grid drawn postion, wud a setter work??

Thanks,
Hetal

[renzland]

Dear all,
I am also very interested in a solution. Please see my post:
http://forums.smartclient.com/showthread.php?t=6349

Thanks

Uwe

[Isomorphic]

Use ListGrid.scrollBodyTo().

[renzland]

Dear Isomorphic,

thank you for reply. I tested it, it works if the resultset was already fetched before.

Is it possible to combine a scroll action with fetching of a new resultset?
Let's say the user can search for a result. If he/her clicks a search button,
following code will be performed:

listGrid.invalidateCache();
listGrid.fetchData(filterBuilder.getCriteria());

SmartGWT is calling transformRequest(request) implicitly with startRow = 0, endRow = 60.
When the result set is loaded in the cache it is possible to scroll e.g. to row 200 by:

listGrid.scrollToRow(new Integer(200));

In this case SmartGWT is calling transformRequest(request) implicitly with startRow = 177, end endRow = 237.

I would like to enforce following behavior:
If the user clicks a search button, the result list should be fetched newly from the server and the scroll action should be performed with the same step:

I tried following code:

listGrid.invalidateCache();
listGrid.fetchData(filterBuilder.getCriteria(), new DSCallback() {
	public void execute(DSResponse response, Object rawData, DSRequest request) {
		listGrid.scrollToRow(new Integer(200));
	}
});

The code does not work. The scrollToRow has no effect. The only transformRequest(request) call by SmartGWT is with startRow = 0, end endRow = 60.
Even if it would work it would be inefficient, because it would enforce two transformRequest(request) calls (first with startRow = 0, second with startRow = 177).

Is it possible to realize the desired behavior?

Thank you very much in advance.

Best Regards

Uwe

[hgaglani]

Hi,


scrollBodyTo didnt work in my case which I assumed was because my widget is in a layout or something. It even maybe because all rows are not fetched at a time. I tried with 100 rows i.e no lazy loading and then do a scrollBodyTo currentPosition+some int but it didnt work.

scrollToRow() also does not work in my case. The series of steps that I execute are the same and everytime for a new fetch after an invalidateCache the start and end rows are 0 to PageSize.

My use case is different as I have 2 different views of the grid. All I want is if user goes to row 1000 in the first grid and switches to another view he shud be able to the see the data in 1000th row in the other view too. I can easily manipulate the fetch but aint able to display it.

Any other suggestions would really help.

Thanks,
Hetal

[Isomorphic]

@renzland You have special reasons for wanting this which differ from hgaglani's. You've been answered in the thread you started.

@hgaglani Are you displaying basically the same grid and same dataset on both screens? If so, the most efficient thing is just to add the same grid in the new screen. It will redraw, but retain the same data without a new fetch. Just remember to add it back to the original screen when you leave the new screen.

[renzland]

Dear Isomorphic,

@renzland You have special reasons for wanting this which differ from hgaglani's. You've been answered in the thread you started.

you are right, my other thread suggests to handle the same problem.
But I have also another usecase which is matching exaclty the problem in "this" thread:

In one tab, the user can specify some filter criteria. By clicking a search button, the result list will be shown in a NEW tab. In that tab the user is free to specify "local filters" , to sort the data, or to scroll down, etc. ..

Because I do not know, how many tabs the user will open, I am a little bid afraid about the performance (cpu and memory) of the IE7 (the user can only use this browser).

Therefore I make some thoughts about how to accelerate the performance. One approach is to detach the DOM objects from a tab in the moment the user "unselect" the tab by selecting another one. The only stored information in that tab would be the filter criteria, selected sorting row/direction as well as the CURRENT POSITION of the visible top list element.

If the user comes back by selecting the tab, the list will be restored from the database and the user should jump to the row with the previously stored number.

But if I understand you correctly in my other thread, this is not possible, because a live list grid is not able to invalidate the cache and to jump to a specified position within the same action.

Can you confirm this?

Thank you very much.

Best Regards

Uwe

[Isomorphic]

All doable, but requires ResultSet APIs that don't appear in SmartGWT yet (they are a top priority addition).

However, you're thinking about optimization way too early and without a clear concept of what the important factors are. The most effective thing to do in this use case is to clear() the ListGrid in order to draw() it later - this requires no persistence of various pieces of view states and is sufficient for a very large number of "dormant" tabs.

[hgaglani]

@hgaglani Are you displaying basically the same grid and same dataset on both screens? If so, the most efficient thing is just to add the same grid in the new screen. It will redraw, but retain the same data without a new fetch. Just remember to add it back to the original screen when you leave the new screen.

No.. I have two different grids... and two different datasources. So lets say the first grid's fetch gets me results 1-75 and on scroll gets me 125...200, wen the user clicks on switch view, I can make the second DS fetch to get me start and end rows from 125...200, but wen it returns with the result, it does not let me display it.. my guess wud be probably coz any grid wud want rows starting from 0. So I made it return resultset of 0...200... but the problem still persists as I cant make it scroll down to row 125.

That in all is my usecase.
scrollToRow was my best bet but it doesnt work.

Let me know if anything else u think could be the solutions.

Thanks,
Hetal

[renzland]

@Isomorphic, thank you it works if I store the start position for later use.
Following methods will be triggerd by deselectTab, selectTab events:

	public void clearList() {
		storedStartRow = grdSearchResults.getVisibleRows()[0];
		grdSearchResults.clear();
	}

	public void drawList() {
		grdSearchResults.draw();
		if (storedStartRow != null) {
			grdSearchResults.scrollToRow(storedStartRow);
		}
	}

The only thing I am wondering: If the list cache stays in the browser (I noticed no fetch action), how could this improve the performance? Do you store the data in a DOM part, the browser is ignoring?


@hgaglani, could it be, that you are also waiting for a to be realized feature?
Please note following thread in the wishlist: Live Grid Extension: Scroll to a specified position directly after fetching data