RAP generally follows the rule “If it compiles, it works”. That means that all SWT API implemented in RWT is working within the requirements set by SWT. If an SWT feature is not implemented, the corresponding API is also missing. In some cases, SWT classes and methods are implemented as empty stubs in RWT to enable single-sourcing, but only where this is a valid implementation of the API. Examples are the Accessibility API or some SWT constants that are marked as HINT.
RWT also provides some additional features that are not part of SWT.
Partly, these are features related to web clients such as the browser history,
partly enhancements of SWT widgets such as the HTML markup support in widgets.
However, RWT does not add any new API to the classes adopted from SWT.
All RWT features are accessible by API in the package
Many of the additional features are activated using the widget's
method with a constant from the
RWT class as the key, for example
table.setData( RWT.MARKUP_ENABLED, Boolean.TRUE ).
FileUploadwidget can be used. The widget looks like a button and will open the filepicker dialog of the user's browser. After a file has been selected, it can programmatically be send to any HTTP server.
RWT.MARKUP_ENABLED. This may require a custom item height, which can be set using
RWT.CUSTOM_ITEM_HEIGHT. To achieve similar effects in SWT, the application would have to draw on the widget using a
PaintListener, which is not supported in RWT except on Canvas.
RWT.FIXED_COLUMNS, it is possible to exclude any number of leftmost columns from scrolling, so that they always stick on the left border of the tree or table.
RWT.getBrowserHistory()to access it. Note that there are known issues when using the browser history and the
Browserwidget in the same application.
Canvaswidget. In some cases the
drawImagemethods may disregard the drawing order and overlap elements that are drawn later. Some methods are unimplemented, including
setXORMode. Performance and results of a drawing operations can differ depending on the browser.
Browserwidget is based on the HTML iframe element, all security restrictions regarding cross-frame-scripting apply. This means for
BrowserFunctionto work, the document loaded in the
Browserwidget has to come from the same domain and port that the RAP application is loaded from. This is automatically given if the
setTextmethod is used.
evaluatemethods will not block program execution. Like with dialogs, a workaround is possible using the class
endcurrently always report the entire text to have changed. The ClientScripting was created specifically to provide an alternative.
DragSourceEvent, the fields
offsetYhave no effect.
DropTargetEvents may be omitted while the mouse cursor is still in motion.
Display#asyncExec()from a background-thread, the UI may not be updated immediately. This is due to the client-server architecture of RAP, in which only the client can send requests to the server. There is a solution for this provided by the class
UICallBack. Read more about it here. Note that as of RAP 1.5,
timerExecdoes not require a UICallBack anymore (it uses UICallBack internally).