ListGrid filtering causes dataArridved?

[csillag]

Hi, I have a ListGrid configured to "BASIC" date fetch mode.
When the user enters something into the filter text box above the grid, and presses the filter button, the dataArrived event is fired, and I don't know why.

All the data is supposed to be available on the client - and indeed it is, Developer Console does not report any RPC operation during the filtering.

Why is data arrived handler called?
How can I tell it not to fire in these cases?
Or how can I determine that a given data arrived event is not a real data arrived event, just a filtering?

[Isomorphic]

When a client-side optimization (local filtering) means that the server does not need to be contacted, we still fire the event so that the optimization does not affect code relying on the event.

There are a few ways you might try detecting this circumstance - but what makes you care about it?

[csillag]

I have external data structures (and application states) which depend on the contents of said ListGrid, so I keep track of all possible reasons why and when data might arrive.

When I want to do something that will cause new data to arrive, I register the current reason beforehand, so that when the data arrives, I know how to manipulate the data structures, taking the current reason into account.

In this system, unexpected data arrive events mean an error, because I do now know how to react to them. (Different reasons demand different answers.)

* * *

So, how do I detect this?

[Isomorphic]

OK, well, the API doesn't currently expose this information and your requirements are far too vague for us to suggest a workaround. Perhaps look at listGrid.willFetchData().

[csillag]

How about adding a boolean configuration option which would determine whether dataArrived calls are wanted if only client-side operations happen?

[csillag]

Perhaps look at listGrid.willFetchData().

1. I can tell that the filtering can always be done from the cache, because I have set the data fetch policy to BASIC.
... or can I? What happens if one sets a narrow filter, and then removes it? Is that previously loaded data (from the wider filter) lost in these cases, so does it have to be reloaded? Or is it preserved and restored?

2. The filtering happens as a result of the user fiddling with the controls. (Entering some text in the filter, and pressing enter, or clicking on the filter button.)

Where can I intercept this process?

(If I notice that a filter operation is going to happen, I can tell my ListGrid not to worry about the incoming DataArrived event.)

[csillag]

It's time to revisit this.

In the meantime, my use-case has changed somewhat: I no longer load all the data, so now filtering actually involves contacting the server.

What I need is a way to be know that a given dataArrived event is caused by a criteria change.

(When I initiate it from code, I am aware of it, but the user can also cause a filter change, using the filter row above the ListGrid.)

How can I detect this? (Earlier you have said there are a few ways I can try to detect this.)

What I would like to have is a simple callback function which is called every time the user initiates a filtering, or a function
I can call which decides whether this data arrival was caused by a filtering action.

[csillag]

I am still interested in this.

[Isomorphic]

So again, the API does not currently expose this information (the particular reason that dataArrived was called, that is).

If you really need this information, use other APIs, for example, compare the criteria relative to some criteria you have previously saved.

[csillag]

I was already trying to do that (compare the saved criteria with the current one) before you have suggested it, but my efforts was thwarted by the extra fetch requests generated after filtering (see here: http://forums.smartclient.com/showthread.php?t=10170 ), which was impossible to recognize, except the first one.

Now that this is resolved, I can (hopefully) detect all events:
- if filter is changed, user is filtering
- if filter is not changed, user is scrolling

Are there any more reasons I am not aware, which would cause DataArrived to be called? (External data modification can be ruled out here, and the grid itself is read only.)

Thank you!

UPDATE: unfortunately, the original issue making the autodetection impossible is still not resolved, so I'm back at square one with this.

[csillag]

for example, compare the criteria relative to some criteria you have previously saved.

How can I check the TextMatchStyle used to create the current result set?

It is passed with the DSRequest, but is it stored and available somewhere in the ListGrid, like Criteria is stored and available as getCriteria?

[csillag]

move this to a new thread

I have moved this to a new thread, here: [URL]http://forums.smartclient.com/showthread.php?t=10271[URL]

[csillag]

So again, the API does not currently expose this information (the particular reason that dataArrived was called, that is).

If you really need this information, use other APIs, for example, compare the criteria relative to some criteria you have previously saved.

How about making at least the operation type and operation id available to the DataArrivedEvent passed to the handlers?