| (Manually) handling the wait cursor [message #1064448] |
Wed, 19 June 2013 10:41  |
 Urs Beeli
Messages: 573
Registered: October 2012
Location: Bern, Switzerland |
Senior Member |
|
|
One requirement for our application is that we need to show the wait cursor if an action takes longer than two seconds.
I potentially see two situations where this may happen:
(a) requesting data from the server that takes a long time to assemble
(b) running some lengthy job on the client side, which cannot be done in the background (as an AsyncJob) for some reason
To simulate (a), I ran some tests (by inserting Thread.sleep(15000) in an OutlineService call). I observed the following behaviour:
- when I launch the action, the mouse cursor changes into the windows wait cursor (the spinning circle in Win7)
- after 4 seconds the mouse cursor goes back to the normal cursor (the arrow) and the icons of all view stacks changes into a spinning circle of circles
- when my call returns, the icons of the view stacks are replaced with the correct icon again
To simulate (b), I inserted a Thread.sleep(15000) in an execAction of a button on a form. Here, it is almost the same:
- when I press the button, the mouse cursor changes into the windows wait cursor (the spinning circle in Win7)
- after 4 seconds the mouse cursor goes back to the normal cursor (the arrow) and the icon of the subtitle changes into a spinning circle of circles (if the form has no subtitle, a temporary panel is added to show the spinning icon)
- when my call returns, the icons of the view stacks are replaced with the correct icon again
While I like the spinning circles on the view stack icons, I fear these may be too subtle for our client. Is it possible to keep the mouse cursor showing the wait cursor until the call returns (preferably in addition to the spinning icons, if needs be instead of)?
Having the mouse cursor go back to the "normal cursor" is especially galling as most elements do not react (at least not visibly) until the icon has stopped spinning, but the cursor gives the user the illusion that he can actually continue working...
|
|
|
| Re: (Manually) handling the wait cursor [message #1070734 is a reply to message #1064448] |
Thu, 18 July 2013 14:58  |
Eclipse User |
|
|
|
Basically you are able to exchange the whole Job/Busy handling in Scout applications.
See:
- org.eclipse.scout.rt.ui.swt.AbstractSwtEnvironment.createBusyHandler()
- org.eclipse.scout.rt.ui.swt.busy.SwtBusyHandler
- and referenced classes
-andreas
|
|
|
|
| Re: (Manually) handling the wait cursor [message #1072164 is a reply to message #1072132] |
Mon, 22 July 2013 08:01 |
Urs Beeli
Messages: 573
Registered: October 2012
Location: Bern, Switzerland |
Senior Member |
|
|
Ok, I've had a look at things. At first, just using createSimpleJob() looked promising (it kept showing the application wide wait cursor) but that doesn't block input to the application and I ended up with multiple dialog windows opened simultaneously due to "test clicks" I made while waiting.
After some deeper investigation, I've come up with the following:
SwtEnvironment:
@Override
protected SwtBusyHandler createBusyHandler() {
return new SwtBusyHandlerEx(getClientSession(), this);
}
SwtBusyHandlerEx extends SwtBusyHandler:
@Override
protected void runBusy(Job job) {
BusyJobStrategyEx.createWorkbenchExJob(this, false).schedule();
}
BusyJobStrategyEx
public static Job createWorkbenchExJob(SwtBusyHandler handler, boolean allowWorkbenchBlocking) {
return new WaitForBlockingJobEx(TEXTS.get("BusyJob"), handler, allowWorkbenchBlocking);
}
WaitForBlockingJobEx extends WaitForBlockingJob
@Override
protected void runBlocking(IProgressMonitor monitor) {
if (true) { // m_blockWorkbench) {
new BlockWorkbenchJob(TEXTS.get("BusyJob"), getBusyHandler()).schedule();
} else {
// schedule a blocking job
new BlockPartsJob(getName(), getBusyHandler(), m_parts).schedule();
}
}
This seems to work, but I have a few questions:
- it seems that BlockPartsJob() stops displaying the application wide wait cursor (though I don't see how it does that in the code) and displays the "per part wait cursor"
- it seems that BlockWorkbenchJob() blocks input but keeps the application wide wait cursor -> so far this looks to be the solution. Is there any reason why I shouldn't just generally use this method? I'm asking because there is the switching logic in the original WaitForBlockingJob class, after all... so my question is, if there are any other differences (apart from the different visual indication) between those two jobs?
|
|
|
Powered by
FUDForum. Page generated in 0.03377 seconds
] 
Search
Help
Register
Login
Home
