Community
Participate
Working Groups
Using observeDelayed has unexpected behavior in RAP (when compared to RCP). The delayed binding is executed on the display thread after a user specified delay -- usually not in the current req./resp. cycle. This results in an update of the UI state on the server. However the browser will be out of sync until the next regular request/response. ISWTObservableValue model = SWTObservables.observeDelayedValue(200, SWTObservables.observeText(text, SWT.Modify)); ISWTObservableValue source = SWTObservables.observeText(label); dbc.bindValue(source, model); See attached snippet for full example. As a workaround one can use UICallBack.
Created attachment 186261 [details] Application to reproduce issue
Fixed in CVS HEAD by activating the UICallBack in SWTDelayedObservableValueDecorator ctor and deactivating it in SWTDelayedObservableValueDecorator#dispose().
The current solution seems to keeps a UICallBack open until the widget is being disposed. In many cases this will result in a UICallBack running for the entire lifetime of the application. I think this solution is less than optimal. We once had the idea to add the UICallback in Display#timerExec(), which would also help in other cases. By wrapping the timerExec runnable, we could disable the UICallBack immediately after executing the wrapped runnable.
Keeping the UICallback around (that's what we do as a workaround) seems also to negatively impact the clean shutdown of the RAP app when the sesion expires. We have a getDisplay().disposeExec() resgistered, that get's called if we don't use the UICallback and it does not get called when we use the UICallback workaround.
I'm sorry, but it's too late for 1.4, we have to carry this issue along to 1.5.
The UICallBack activation/deactivation is no longer needed in SWTDelayedObservableValueDecorator as it is done by Display#timeExec (see bug 364863).
