On 8/23/2011 8:19 AM, Jeffrey Chimene wrote:
On 8/23/2011 2:38 AM, jsg wrote:
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??
Yes.

In fact, there are other actions that can occur after pressing enter. For example, the user could choose to delete a row in the table.

You can review the code at http://code.google.com/p/gwt-sked, or try out the project at http://jchimene.com/sked.html The specific example you cite can be demonstrated by the following actions:
0) Select "Load sample schedule" under the "Help"menu"
1) Click a cell in the "Likely" column for a specific activity
2) Set the value to zero. Press enter to blur the cell. Notice the adjacent cell values are set to zero. 3) Enter a non-zero value in the "Likely" cell. Press Enter to blur the cell, the other cells are immediately updated.

I'm happy to supply annotations or answer questions.

You might have already done this, but try compiling the code in PRETTY mode and run it using a browser that will display the Javascript console (I usually use Firefox + Firebug). See if you have any "interesting" runtime errors.

Thinking further on your question, it occurs to me that you're asking: "how do I update THE SAME CELL". I have to admit this caused some consternation. For a while, I considered sub-classing EditTextCell, an approach I abandoned as unworkable.

The Predecessor column implements this same cell update behavior to correct data entry errors that might introduce a network cycle. The apropos code is in "ActivityPresenter.onPredecessorChange()"

Demonstrate as follows:

0) Select "Load sample schedule" under the "Help"menu"
1) Click a cell in the "Predecessor" column for a specific activity
2) Enter a comma-separated list that includes that row's ID. For example, if you choose activity "C",enter the string "1,3" as that activity's predecessor list. Press enter to blur the cell. Notice that the string ",3" is removed from the value.




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.

Reply via email to