Multi-column sorting not working with FixedHeader

hd.deman

Multi-column sorting not working with FixedHeader
http://datatables.net/release-datatables/extras/FixedHeader/

allan

Hi hd.deman,

Thanks for pointing this out! This is a known limitation of FixedHeader at the moment, and I hope to address it in a future release. It's basically due to how the click is passed on to DataTables - I'll attempt to find a better way.

Regards,
Allan

joesaland

Allan,

Was this every fixed? I've noticed if I try and use FixedHeader with per column filtering it constantly redraws the footer, so that the user input gets lost. This is really bad if you are using a keyup event because you essentially can't ever type more then one or two keys before it redraws on your. Even without that it becomes unusable because after the redraw whatever was in the input field does not get re-displayed yet the filter is still applied which is very counter-intuitive. The user has to go into into an apparently empty input field and hit enter to clear the old filter.

For now I guess I could just code the input fields to sit in a div outside of the table itself, perhaps above it. Functionally it would work, it's just non-ideal for very long tables like I am working with (800+ rows).

Joe

allan

It certainly was: http://datatables.net/release-datatables/extras/FixedHeader/index.html . v2 of FixedHeader introduced multi-column sorting abilities.

The thing about FixedHeader is that every time it redraws the table, it has to redraw the fixed elements as well (since it might have changed). This is done by cloning the original header / footer etc, therefore the user input - as you point out as lost.

I agree that this is actually a very nasty interaction - and most undesirable. There are three options off the top of my head:

1. Provide a method to stop FixedHeader from recloning on a filter (although for other draw types the problem should still exist)
2. Stop this behaviour (but then the header / footer might get out of sync with the table - perhaps the v1 behaviour of needing to call fnUpdate should have been retained).
3. Save the information on the keypress before the filter, let DataTables / FixedHeader do it's thing, then put the information back in the field and focus on the element again. More work for the developer though...

Any other suggestions?

Regards,
Allan

joesaland

Allan,

I think you are the right track with option #3 to be honest, since it seems more flexible in the long run. The only concern I could see with it would be on slower machines the redraw might be noticeable for end users. Some combination of #2 and #3 might work as well. Personally I don't mind as a developer just being given the appropriate hooks, though I understand if you want something more robust then that.

Joe