On 08/22/2011 01:13 PM, jsg wrote:
> We haven't tried it in compiled mode yet, but it definitely doesn't
> work in dev mode for us.
Alright - at least that's better than what was happening on my side. The
problem was that in dev mode, the NPE exception was correctly caught in
the try/catch block.
In compiled mode, the NPE doesn't exist, it's caught as a
JavaScriptException.
My code example was intended to demonstrate that when "MyVariable" is
null, then the catch of the NPE doesn't happen in compiled mode.
I was hoping that you were seeing the same thing: the refresh() succeeds
in dev mode, but not in compiled mode because the NPE can't be caught in
compiled mode. The refresh() never got called because of the NPE.
In your case, it's not working in dev mode. In that case, what do you
see when the presenter does not refresh?
Also, is the celltable setup to allow focus to one cell? If so, does the
refresh occur if you set focus to a cell, the blur out of that cell? One
thing I was going to try before I figured out the NPE, was to subclass
CellTable, and start hooking into some of the protected() routines.
>
> What is your code that returns a value? Neither the
> FieldUpdate.update() nor the ScheduledCommand.execute() expects a
> value back so I'm a little perplexed as to your context? And what is
> MyVariable?
>
> Sorry if I've just lost the plot.
>
> On Aug 22, 8:47 pm, Jeff Chimene <jchim...@gmail.com> wrote:
>> On 08/22/2011 02:34 AM, jsg wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Hi Jeff,
>>
>>> Given both our experience and your confirmation, I'm going to file a
>>> bug report in case this thread isn't being noticed.
>>
>>> Thanks for your effort.
>>
>>> On Aug 22, 12:46 am, jchimene <jchim...@gmail.com> wrote:
>>>> Hi Julian,
>>
>>>> I was too glib in my earlier reply.
>>
>>>> I, too, am seeing this problem. I hadn't completetly tested this app
>>>> in production mode, and it fails miserably when compiled.
>>
>>>> So, I will post updates to this thread when I get a solution that
>>>> works not only in development mode, but also when compiled.
>>
>> The answer (at least in my case), was the following:
>>
>> try {
>> switch (MyVariable) {
>> case 1: return 1;
>> case 2: return 2;
>> .
>> .
>> .
>>
>> } catch (NullPointerException e) {
>> return 1;
>> }
>>
>> In compiled mode, the try/catch doesn't, so the Javascript was failing
>> at the switch expression evaluation. So, the side-effect was that the
>> display was never refresh()-ing
>>
>> Try compiling in PRETTY mode and checking for exceptions.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>> On Aug 19, 8:17 am, jsg <jgerso...@gmail.com> wrote:
>>
>>>>> We have refreshed the view because instead of calling
>>>>> ListDataProvider.refresh() which simply calls updateRowData() for all
>>>>> the registered displays, we've done the following:
>>
>>>>> By calling batchTable.setRowData() we are simply more directly
>>>>> targeting both the display and only the row that has changed. (Rather
>>>>> than all visible rows by calling refresh().)
>>>>> As far as I can tell from the system, the DataProviders have no
>>>>> knowledge of the internal column data and so they can't know if any of
>>>>> the values of the rows have been updated. Only that the row instances
>>>>> themselves have changed. (I have tested it now, just to be safe,
>>>>> replacing setRowData() with refresh() with the same results.)
>>
>>>>> Our use case is not so uncommon that we should be struggling so much
>>>>> with this intended functionality.
>>
>>>>> Thanks for your prompt reply.
>>>>> Julian
>>
>>>>> On Aug 19, 4:16 pm, Jeffrey Chimene <jchim...@gmail.com> wrote:
>>
>>>>>> On 8/19/2011 4:53 AM, jsg wrote:
>>
>>>>>>> Thanks for your insight.
>>
>>>>>>> However, after wrapping the setRowData() in a ScheduleDeferred like
>>>>>>> so:
>>
>>>>>>> Scheduler.get().scheduleDeferred(new ScheduledCommand() {
>>>>>>> @Override
>>>>>>> public void execute() {
>>>>>>>
>>>>>>> batchTable.setRowData(index,
>>>>>>> Collections.singletonList(object));
>>>>>>> }
>>>>>>> });
>>
>>>>>>> There is no perceived change in behaviour.
>>>>>>> I've tried wrapping the whole FieldUpdater.update() contents inside
>>>>>>> the execute() action, but to no avail.
>>
>>>>>> I'm not sitting in front of my GWT development machine,so I don't have
>>>>>> this exactly right,but where are you calling the list.refresh() method?
>>>>>> You've updated the backing list, but not refreshed the view (at least in
>>>>>> the sample).
>>
>>>>>>> On Aug 18, 10:01 pm, Jeff Chimene<jchim...@gmail.com> wrote:
>>>>>>>> On 08/18/2011 12:05 PM, jsg wrote:
>>
>>>>>>>>> Hello.
>>>>>>>>> I've created a test case of my CellTable issue as a self contained
>>>>>>>>> panel that can easily be imported into any project:
>>>>>>>>> http://pastebin.com/zDLPKUNh
>>>>>>>>> Basically I have two Date class fields in my row model, a startDate
>>>>>>>>> and an endDate. Each Date has two columns in the CellTable (called
>>>>>>>>> batchTable), one to display the actual date (a DatePickerCell) and
>>>>>>>>> the other being a text input cell for the time.
>>>>>>>>> When the FieldUpdater of the startTime or endTime is fired we parse
>>>>>>>>> the value, save the new time and call batchTable.setRowData() with
>>>>>>>>> the updated object and row index.
>>>>>>>>> The problem is that when FieldUpdater is fired, the cells do not
>>>>>>>>> update. I specifically edited the FieldUpdater of the endTime cell
>>>>>>>>> to be an hour later than what it was set at.
>>>>>>>>> I've checked as best as I can that all the gets and sets of the
>>>>>>>>> respective startDate and endDate are in order, but I'm thinking that
>>>>>>>>> there's something about CellTable I'm not getting.
>>>>>>>>> Apologies if I've missed anything.
>>>>>>>>> I'm running: GWT 2.3
>>>>>>>>> I've tested it in the latest Chrome and IE9.
>>>>>>>>> Regards, Julian
>>>>>>>> Try putting your update actions inside a ScheduleDeferred command.
>>
>>>>>>>> The issue seems to be the coupling between the FieldUpdater and the
>>>>>>>> cellTable refresh logic. Running the FieldUpdate.update() action after
>>>>>>>> the browser's refresh loop seems to address this issue.
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
