Restoring grid => filter-input

Hi,

we just bought v6 and I’m trying to update my old v5 scripts.

Use case is: When someone leaves the grid for another page and comes back he should return with the same filter, sort and scroll-position.
I was able to do that, the one thing I’m failing is putting the filter-value back into the input in the header row. I was able to localize that input through javascript and also putting the value back in. But somehow the grid always empties this input afterwards, even if I wrap it inside a dhs.awaitRedraw()-Promise.

If I use a button to set the value it works. Any idea how I could put in a value there when the page loads?

Thank you.

Jonas

Edit: Scrolling does also reset my manually set input.

And a follow-up question:

When I store one filter and use

grid.data.filter({by: value.by, match: value.match});

It works. When I store more than one filter and call grid.data.filter several times it just does nothing.

How do I apply more than one filter to the grid programmatically?

Good luck with the restoring the filter input value; you’ve already gotten farther than I ever did.

But for using multiple filters, have a deeper look into the config object in the Grid -> API -> Data Collection -> filter() function. It allows for multiple filter rules, but does a replace by default.

Oh hell, I overread that somehow. Thanks, I’ll try that.

Yeah, I’ve come quite far, but if the grid itself empties this inputs himself all the time it’s not worth much.
It’s a quite common use-case that you leave the site for some detailed view of a row and want to come back exactly how you left the page. This is really something that needs to be implemented or changed or whatever.

I apologize for the delay with the reply.
Unfortunately currently it is not available to manipulate with the in-header filters by API.

What about the multiple filters please, refer to the “compare” property of the filter, or the add/multiple parameters of the filter ocnfig allowing to apply the next filter to the already filtered dataset.

Unfortunately currently it is not available to manipulate with the in-header filters by API.

Is this a possibility for future updates? This is quite important for us and, as I said, a quite common use-case that you want to restore the grid like it was before you left the page.
Otherwise I’d have to write my own filter-section.

Yes, we’re planning to extend that feature in the future updates. But unfortunately we have no such plans in the near future, so I cannot give you any timeline.

@jonas3344 I’m not sure what kind of constraints you’re working with, so these options may not work for you, but usually if I expect someone to return to a grid, I either open the details in a new browser tab/window (using window.open()), or load the details in a dhx.Window, so that the grid is left untouched.

In one instance where I expected a user might open details for several rows, where I didn’t want them having to figure out which browser tab was which, I built a Tabbar with the grid in an uncloseable tab at index 0, then added a new closeable tab for each row they opened (or made active the relevant tab if one already existed for that row). That was in DHX5, so I can’t speak to how DHX6 might handle the grid headers now that the VDOM doesn’t keep the content of inactive tabs rendered, and would thus re-render the grid each time you switch back to the grid’s tab.

Maybe one of those solutions would work for you without having to fight the grid headers?

Thanks for the inputs. Opening a new browser-tab will probably be the “solution” or workaround. It was the solution before I took over the development. And I wrote this grid-restore function for v5 which worked really good and allowed my to store the whole grid-status in the localStorage. So I’m a little bit disappointed that they stripped that away. Tabs aren’t an option right now as the following page still works with Forms to edit data, which would reset the page anyway.