| UICallbackManager#releaseBlockedRequest in 1.5 requires manual trigger [message #802035] |
Sun, 19 February 2012 09:39  |
|
Hi all,
Our RAP unit tests depend so much on UICallbackManager#sendImmediately()
to send notification to client.
Since 1.5 it seems to be replaced by releaseBlockedRequest() but somehow
we have to trigger it manually to make it work (by clicking somewhere in
the browser, etc), otherwise our tests will be frozen. This of course
breaks our automate tests.
Any help would be greatly appreciated.
Thanks & Regards,
Setya
|
|
|
| Re: UICallbackManager#releaseBlockedRequest in 1.5 requires manual trigger [message #802044 is a reply to message #802035] |
Sun, 19 February 2012 09:53  |
|
Hi,
The problem is not in releaseBlockedRequest method but a call to
Display#sleep() afterwards which waits for events which I have to
trigger manually. I'm not sure why this works fine in < 1.5.
Please advice.
Regards,
Setya
> Hi all,
>
> Our RAP unit tests depend so much on UICallbackManager#sendImmediately()
> to send notification to client.
>
> Since 1.5 it seems to be replaced by releaseBlockedRequest() but somehow
> we have to trigger it manually to make it work (by clicking somewhere in
> the browser, etc), otherwise our tests will be frozen. This of course
> breaks our automate tests.
>
>
> Any help would be greatly appreciated.
>
>
> Thanks & Regards,
>
> Setya
|
|
|
|
| Re: UICallbackManager#releaseBlockedRequest in 1.5 requires manual trigger [message #803213 is a reply to message #802744] |
Tue, 21 February 2012 03:33 |
|
Hi Ralf,
Thank you for your response & link.
In our unit tests after we trigger some actions that update the UI we always call UICallManager#sendImmediately and Display#sleep to make sure the update visually reflected.
For example:
...
IWorkbenchPage page = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
page.showView("someViewId");
UICallBackManager.getInstance().sendImmediately();
Display.getCurrent().sleep();
...
The above code works fine in 1.4 in that the view is visually displayed and we can move to the next execution.
Since 1.5 we have to replace the call UICallBackManager#sendImmediately by UICallBackManager#releaseBlockedRequest(). I've checked the source code and they do exactly the same.
...
IWorkbenchPage page = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
page.showView("someViewId");
UICallBackManager.getInstance().releaseBlockedRequest();
Display.getCurrent().sleep();
...
In 1.5 the above snippet opens the view but the execution always stops at Display#sleep until I manually trigger it by clicking somewhere in the page.
Hope I make it clear this time.
Thanks & Regards,
Setya
|
|
|
| Re: UICallbackManager#releaseBlockedRequest in 1.5 requires manual trigger [message #803216 is a reply to message #802744] |
Tue, 21 February 2012 03:33 |
|
Hi Ralf,
Thank you for your response & link.
In our unit tests after we trigger some actions that update the UI we always call UICallManager#sendImmediately and Display#sleep to make sure the update visually reflected.
For example:
...
IWorkbenchPage page = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
page.showView("someViewId");
UICallBackManager.getInstance().sendImmediately();
Display.getCurrent().sleep();
...
The above code works fine in 1.4 in that the view is visually displayed and we can move to the next execution.
Since 1.5 we have to replace the call UICallBackManager#sendImmediately by UICallBackManager#releaseBlockedRequest(). I've checked the source code and they do exactly the same.
...
IWorkbenchPage page = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
page.showView("someViewId");
UICallBackManager.getInstance().releaseBlockedRequest();
Display.getCurrent().sleep();
...
In 1.5 the above snippet opens the view but the execution always stops at Display#sleep until I manually trigger it by clicking somewhere in the page.
Hope I make it clear this time.
Thanks & Regards,
Setya
|
|
|
|
| Re: UICallbackManager#releaseBlockedRequest in 1.5 requires manual trigger [message #804434 is a reply to message #804165] |
Wed, 22 February 2012 16:11 |
|
Hi Ralf,
> I still don't understand your test setup and why you need to access
> internal methods.
Since those methods are all I know that I can use to tell the client to
update UI.
> From which thread do you trigger the UI changes?
From main test thread.
> Whatever you're doing, it would be preferable to try doing it using API
> calls. Have you tried Display#wake() instead?
I tried Display#wake and while it made the test pass, the UI updates are
not visible.
Would you please give example to achieve the same as you suggested ?
Thanks & Regards,
Setya
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04415 seconds
] 
Search
Help
Register
Login
Home
