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 view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/_rvjvPkrhzkJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to