I tried this solution, but in my case, the header checkbox seems automatically selected and it selects all the records. I have a situation where there could be pre-selected values for each row coming from DB. How do I do that?
On Monday, August 27, 2012 at 2:58:15 PM UTC-5, Kara Marie Rawson wrote: > > That works like a charm. Thanx for the tip! > > On Friday, June 8, 2012 8:45:04 PM UTC-4, Nicholas Lesiecki wrote: >> >> Hi, >> >> Thanks for your well written post. It appears that your solution works >> well if you construct the CheckboxCell with the right flags: >> >> new CheckboxCell(true, true) >> >> the two booleans are handlesSelection and dependsOnSelection, and they >> cure the weird event ordering issues you were seeing. >> >> Cheers, >> >> Nick >> >> On Tuesday, November 22, 2011 10:19:31 AM UTC-8, Raziel wrote: >>> >>> This question has been asked and partially responded in a number of >>> posts: >>> >>> >>> http://groups.google.com/group/google-web-toolkit/browse_thread/thread/dc3a97cd25deb6e3/392dfcdb35f04c95?lnk=gst&q=DefaultSelectionModel#392dfcdb35f04c95 >>> http://snipt.net/araujo921/checkbox-in-gwt-celltable-header/ >>> >>> http://groups.google.com/group/google-web-toolkit/browse_thread/thread/56f5513b709cd041 >>> >>> http://groups.google.com/group/google-web-toolkit/browse_thread/thread/b20080056a76276f >>> >>> http://0-groups.google.com.topcat.switchinc.org/group/google-web-toolkit/browse_thread/thread/6d4e65510855e6f6 >>> >>> However, I still haven't found I clean answer to what seems to me a >>> very common feature requested in data presentation (and editing) >>> grids. >>> >>> In summary we want to be able to add a checkbox header to a selection >>> column of checkboxes that: >>> >>> * Checking it will select all visible items in the grid. >>> * Unchecking it will deselect all visible items in the grid. >>> * Any change in the visible data, caused for example by paging or >>> sorting, will result in the checkbox header value to be updated >>> according to the rules above: if all visible items are selected then >>> check it, otherwise uncheck it. >>> >>> The straightforward logic would suggest that the following >>> implementation should work: >>> >>> CheckboxCell headerCheckbox = new CheckboxCell(); >>> Header<Boolean> selectPageHeader = new >>> Header<Boolean>(headerCheckbox) { >>> @Override >>> public Boolean getValue() { >>> for (T item : grid.getVisibleItems()) { >>> if (!getSelectionModel().isSelected(item)) { >>> return false; >>> } >>> } >>> return grid.getVisibleItems().size() > 0; >>> } >>> }; >>> selectPageHeader.setUpdater(new ValueUpdater<Boolean>() { >>> @Override >>> public void update(Boolean value) { >>> for (T item : grid.getVisibleItems()) { >>> getSelectionModel().setSelected(item, value); >>> } >>> } >>> }); >>> grid.insertColumn(0, checkColumn, selectPageHeader); >>> >>> However, the result is not the expected: >>> >>> * When updating the visible data, lets say by moving to the next page, >>> the getValue() method gets called. The first couple of calls, >>> getVisibleItems() returns empty, and then it returns the new not-yet- >>> selected data. In each case, getValue() returns false. However, this >>> produces no change in the checked state of the header. This in itself >>> seems like a bug to me. >>> >>> * When just toggling the checkbox header, this ends up in the opposite >>> state than desired. Even though update() gets called with the proper >>> value that reflects the checkbox header state, and the last calls made >>> to getValue() result in the proper value being returned. The only >>> "irregular" logic I see that could cause this, is that when clicking >>> on the header, the getValue() method gets called before the update() - >>> to obtain the key and create a cell context. That results in >>> getValue() returning the wrong value (i.e. the opposite). However, >>> after update() gets called and it sets the selection state of the >>> visible items, getValue() gets called again, thus returning the proper >>> value this time. >>> >>> I guess there are ways where the header can be created in a way where >>> we can control better how its value is set and retrieved. However, >>> this being such a common use case, and whose logical implementation >>> shown above produces inconsistent results, tells me that either I'm >>> completely missing something, or that this is a flaw in the celltable >>> widgets. >>> >>> I would appreciate any input on this regard, >>> >>> Thanks >>> >>> -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
