nally happy with a strong gwt core, and that just keep getting
> better with each release.
>
> On Sun, Sep 25, 2011 at 8:32 PM, camerojo wrote:
>
>
>
>
>
>
>
>
>
> > I also agree - I hope the Google folk look at this.
>
> > GWT is a wonderful conc
I also agree - I hope the Google folk look at this.
GWT is a wonderful concept, and we should all be very grateful for it,
but some of the implementation is certainly over engineered.
In particular I wish that more focus was given to fixing basic bugs
(of which there are quite a few) rather than
I have had no feedback on this but I think it is a serious but fairly
easily resolved problem so I have reported it as an issue -
http://code.google.com/p/google-web-toolkit/issues/detail?id=6777
On Aug 16, 4:40 pm, camerojo wrote:
> Cell widgets were a great step forward for GWT - enabl
Whoops - ignore the last two lines below - they snuck into my posting
by mistake...
> I suggest either redefining, creating a new enum, or allowing
> pluggable policies
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group
Cell widgets were a great step forward for GWT - enabling efficient
client display of very large amounts of server data by means of
RangeChangeEvents processed by AsyncDataProviders.
However there is a serious problem with keyboard navigation as defined
by KeyboardPagingPolicy.INCREASE_RANGE.
Sup
There is a workaround - which is to defer the setFocus call:
ie
Scheduler.get().scheduleDeferred(new Scheduler.ScheduledCommand()
{
public void execute() {
name.setFocus(true);
}
});
Clearly this is some kind of timing problem.
--
You received this message because y
This problem occurs with all browsers I have tested: Windows IE,
Firefox, Safari
I have logged this as issue 6687
http://code.google.com/p/google-web-toolkit/issues/detail?id=6687
On Aug 15, 12:08 pm, camerojo wrote:
> TabLayoutPanel does not seem to manage focus correctly, whereas
> Ta
TabLayoutPanel does not seem to manage focus correctly, whereas
TabPanel does.
This works fine - the "name" TextBox ends up with focus:
public void onModuleLoad() {
TabPanel tabPanel = new TabPanel();
FlowPanel panel = new FlowPanel();
TextBox name = new TextBox();
panel.add(name)
Back in May I posted a bug report for this but it does not seem to be
getting the attention it deserves so I have uploaded a simple app that
demonstrates the bug - see http://keybdscrollbug.appspot.com/
The bug was reported as issue 6383 - see
http://code.google.com/p/google-web-toolkit/issues/det
Seeing that this new release involves new work in the area of cell
based widgets, it might be a great opportunity to fix a nasty keyboard
scrolling bug that I reported a few months back - see
http://code.google.com/p/google-web-toolkit/issues/detail?id=6383
I have looked at the new source code and
Seeing that this new release involves new work in the area of cell
based widgets, it might be a great opportunity to fix a nasty keyboard
scrolling bug that I reported a few months back - see
http://code.google.com/p/google-web-toolkit/issues/detail?id=6383
I have looked at the new source code and
API with code that
looks like:
ReCaptchaImpl reCaptcha = new ReCaptchaImpl();
reCaptcha.setPrivateKey("");
ReCaptchaResponse reCaptchaResponse =
reCaptcha.checkAnswer(remoteAddr, challenge, response);
boolean valid = reCaptchaResponse.isValid();
On Jul 17, 10:01 am, camerojo
I am interested in this as well - in fact any captcha - not just
JCaptcha.
Here are two postings that I found recently. I haven't tried either
yet myself, so interested in any feedback.
http://www.javacodegeeks.com/2010/06/add-captcha-gwt-application.html
and
http://groups.google.com/group/Goog
Am I right in assuming that eventually the intention is that CellList
will become an alternative to the existing ListBox?
On May 21, 8:08 am, Paul Stockley wrote:
> There is the data bound cell based list and tree widgets they talked
> about. These are really independent of any mvp framework. Ho
14 matches
Mail list logo
