Let me get this straight, you run the code in dev mode, you set the
endTime TextInputCell to a value, let's say 14:18 and on pushing Enter
or leaving focus, the code parses the value and updates it to 15:19
(as the + 1 is set in the FieldUpdater) and then this displays
immediately on your machine??
On Aug 22, 10:46 pm, Jeff Chimene <jchim...@gmail.com> wrote:
> 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.
