| RWT/RAP VerifyEvent support and ClientScripting [message #990487] |
Wed, 12 December 2012 11:42  |
 |
 John Gymer
Messages: 77
Registered: November 2012
Location: UK |
Member |
|
|
RAP 1.5 noted a difference between SWT and RWT as follows:
Quote:
Limitations in Verify and Modify Events: ModifyEvent, VerifyEvent
Modify and Verify events are not fired instantaneously, but with a small delay, possibly combining a number of changes into one event. Also, the values of the VerifyEvent fields text, start and end currently always report the entire text to have changed. The ClientScripting was created specifically to provide an alternative.
Firstly, VerifyEvent also does not populate event.character either, which is not such a big deal, but doesn't appear to be documented as a difference.
Incidentally, I'm using RAP 2.0 M3 rather than 1.5, but cannot see this as a documented difference.
So, the question, which has most likely been asked somewhere already, but I couldn't see a complete answer, is how to handle VerifyEvent logic in RWT/RAP and ultimately also Tabris, which I assume works the same way as RAP.
Performance of VerifyEvent is not great with RAP because of the round-trip nature of the event-browser-appserver-browser. I have read a little about ClientScripting, but does this technology have a future? It does mean that I can no longer single-source my application for SWT and RAP, but I can probably live with that if the solution is slick enough.
Is ClientScripting the way to go? What is its future? Is it supported in Tabris too? Or is there a sensible, more generic alternative?
I'd love to see an example of ClientScripting, perhaps implementing something simple like an upper-case translator for an entry field... anyone got a snippet they can share?
Here's the SWT equivalent that works well as a local SWT application:
VerifyListener validateUppercaseListener = new VerifyListener() {
public void verifyText(VerifyEvent event) {
event.doit = false; // assume don't allow char input
char myChar = event.character;
String myTxt = String.valueOf(myChar);
if (Character.isUpperCase(myChar)) event.doit = true; // allow 0-9
else if (Character.isLowerCase(myChar)) {
event.text = event.text.toUpperCase();
event.doit = true; // allow 0-9
}
if (myChar == '\b') event.doit = true; // allow backspace
if (myTxt.codePointAt(0) == 127) event.doit = true; // allow delete
if (myTxt.codePointAt(0) == 0) event.doit = true; // allow changes via code
}
};
applied to a Text widget with:
myTxtWidget.addVerifyListener(validateUppercaseListener);
I'm very excited about all these technologies at the moment, but don't want to end up down the wrong path that will cause me grief later on.
Useful comments and help very much appreciated,
John
---
Just because you can doesn't mean you should
|
|
|
] 
Search
Help
Register
Login
Home
