Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » (Manually) handling the wait cursor
(Manually) handling the wait cursor [message #1064448] Wed, 19 June 2013 06:41 Go to next message
Urs Beeli is currently offline Urs Beeli
Messages: 318
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 10:58 Go to previous messageGo to next message
Andreas Hoegger is currently offline Andreas Hoegger
Messages: 173
Registered: February 2010
Senior Member
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 #1072132 is a reply to message #1070734] Mon, 22 July 2013 02:19 Go to previous messageGo to next message
Urs Beeli is currently offline Urs Beeli
Messages: 318
Registered: October 2012
Location: Bern, Switzerland
Senior Member
Thanks, I'll have a look at these.
Re: (Manually) handling the wait cursor [message #1072164 is a reply to message #1072132] Mon, 22 July 2013 04:01 Go to previous message
Urs Beeli is currently offline Urs Beeli
Messages: 318
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?

Previous Topic:Setting certain cells in an editable table column to non-editable doesn't work
Next Topic:Swing Gui rendering issue in multiple operatig system
Goto Forum:
  


Current Time: Fri Jul 25 12:17:46 EDT 2014

Powered by FUDForum. Page generated in 0.03578 seconds