Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » Modifying table behaviour(Scrolling to the end after inserting new elements)
Modifying table behaviour [message #1008611] Wed, 13 February 2013 04:40 Go to next message
Urs Beeli is currently offline Urs Beeli
Messages: 318
Registered: October 2012
Location: Bern, Switzerland
Senior Member
I have added a form containing a table to my application that shows messages generated on the server or by other clients (kind of an event log). I have managed to set up a client notification service that keeps this table updated with the latest content. However there is one issue I have not managed to solve.

I disabled sorting of the table (SortEnabled=false) so the entries always appear in the correct order. By default, I want the table to always show the latest entries (which are at the bottom of the table). However, filling the table with updated data scrolls back to the top of the table.

What I've done currently is the following:
In my form class I have:
  public void refreshForm() throws ProcessingException {
    IMessageListProcessService service = SERVICES.getService(IMessageListProcessService.class);
    MessageListFormData formData = new MessageListFormData();
    exportFormData(formData);
    formData = service.load(formData);
    importFormData(formData);
    setEnabledPermission(new ReadTabbedPermission());
    getTableField().getTable().selectLastRow();
    getTableField().getTable().deselectAllRows();
  }

  public class DisplayHandler extends AbstractFormHandler {
    @Override
    public void execLoad() throws ProcessingException {
      refreshForm();
    }
  }


The client notification handler then just calls form->refreshForm().

This scrolls the table to the bottom when refreshForm() is called from the notification handler, but not on its initial call, when the form is filled from form.DisplayHandler.execLoad().

So I have two questions:

  • is there a better way to enforce that the table always scrolls to show its bottom entry?
  • any ideas why my hack above does not work on the initial population of the table?

Re: Modifying table behaviour [message #1008621 is a reply to message #1008611] Wed, 13 February 2013 05:51 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie Bresson
Messages: 625
Registered: October 2011
Senior Member
Have you ScrollToSelection == true on the table?

You can set it to true with:
  protected boolean getConfiguredScrollToSelection() {
    return true;
  }


Are you using Swing, SWT or RAP UI?


Can you also try to put your refreshForm() call in execPostLoad()?
http://wiki.eclipse.org/Scout/Concepts/Form_Handler

Quote:
This event is suitable if you want select some rows in a TableField

Re: Modifying table behaviour [message #1008714 is a reply to message #1008621] Wed, 13 February 2013 11:58 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 Jeremie

Yes, ScrollToSelection is true on the table (and it works on subsequent calls triggered by the client notification).

Thanks for the hint about execPostLoad(), but sadly that has not helped. My code now looks as follows
  public void startDisplay() throws ProcessingException {
    startInternal(new DisplayHandler());
  }

  public void refreshForm() throws ProcessingException {
    IMessageListProcessService service = SERVICES.getService(IMessageListProcessService.class);
    MessageListFormData formData = new MessageListFormData();
    exportFormData(formData);
    formData = service.load(formData);
    importFormData(formData);
    setEnabledPermission(new ReadTabbedPermission());
    scrollTableDown();
  }

  public void scrollTableDown() {
    getTableField().getTable().selectLastRow();
    getTableField().getTable().deselectAllRows();
  }

  public class DisplayHandler extends AbstractFormHandler {
    @Override
    public void execLoad() throws ProcessingException {
      refreshForm();
    }

    @Override
    public void execPostLoad() throws ProcessingException {
      scrollTableDown();
    }
  }


As I understand it

  • form->startDisplay() is called after the form has been created
  • this in turn calls DisplayHandler.execLoad() which calls form.refreshForm() -> this loads the data from the server and places it in the table (this works)
  • refreshForm() also calls form.scrollTableDown() which I would have expected to show the last entry in my table (this doesn't work)
  • DisplayHandler.execPostLoad() is called which again calls form.scrollTableDown() however, this, too doesn't work
  • later, a client notification is received (code not shown here) which in turn calls form.refreshForm() -> this reloads the data from the server and places it in the table (this works)
  • refreshForm() also calls form.scrollTableDown() and interstingly enough, here it works

I'm wondering why the same mechanism works later on, but not initially.
Re: Modifying table behaviour [message #1008956 is a reply to message #1008714] Thu, 14 February 2013 03:01 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie Bresson
Messages: 625
Registered: October 2011
Senior Member
I can not see what is wrong with your approach... As you I would expect that it works...

Can you tell your Eclipse version, Scout version and Scout Renderer (SWT, Swing, RAP)?
Re: Modifying table behaviour [message #1010753 is a reply to message #1008956] Mon, 18 February 2013 02:21 Go to previous messageGo to next message
Urs Beeli is currently offline Urs Beeli
Messages: 318
Registered: October 2012
Location: Bern, Switzerland
Senior Member
My IDE is based on Eclipse 4.2.1 and Scout SDK 3.8.1, however I have set up a target definition file to use Scout Kepler M5 as runtime platform (see below). I am using SWT as renderer.
<unit id="org.eclipse.scout.rt.source.feature.group" version="3.9.0.20130206-1155"/>
<unit id="org.eclipse.scout.rt.testing.source.feature.group" version="3.9.0.20130206-1155"/>

<unit id="org.eclipse.platform.ide" version="3.8.1.M20120914-1540"/>
<unit id="org.eclipse.rcp.feature.group" version="3.8.1.v20120814-105048-92BmGJlFw3Ez0WZ9TxCqgcSVAE"/>
<unit id="org.eclipse.equinox.sdk.feature.group" version="3.8.0.v20120522-1841-7M7fA78g5_y-eQjtHxcd47Zm7mDQ"/>

<unit id="org.eclipse.rap.runtime.requirements.feature.group" version="1.5.1.20120917-1130"/>
<unit id="org.eclipse.rap.runtime.feature.group" version="1.5.1.20120917-1130"/>
<unit id="org.eclipse.scout.rt.rap.feature.feature.group" version="3.8.1.201209171521"/>
<unit id="org.eclipse.rap.incubator.supplemental.fileupload.feature.feature.group" version="1.5.0.20120220-1720"/>
<unit id="org.eclipse.scout.rt.ui.rap.incubator.filechooser.feature.feature.group" version="3.8.1.201209171521"/>

Re: Modifying table behaviour [message #1011558 is a reply to message #1010753] Tue, 19 February 2013 14:45 Go to previous messageGo to next message
Lukas Huser is currently offline Lukas Huser
Messages: 40
Registered: March 2010
Member
Hi Urs

Your code to scroll down might work if you call it from execFormActivated() (defined on the form iteslf, not on a handler) instead of execLoad() or execPostLoad().

Both execLoad() and execPostLoad() are called during initialization of the model. The UI is not yet ready to receive events from the model. So a call to selectLastRow() will simply update the selection state of the table model, but the fired event for the UI is lost. When the UI is finally attached, it will display the most recent state of the table model (no rows selected).

In contrast, execFormActivated() is called after the UI has been attached to the model.

But then, if you want to show the most recent entries to the user, why not simply sort your table entries descending, you then have the most recent log entries at the top and won't need to scroll down...
Re: Modifying table behaviour [message #1011795 is a reply to message #1011558] Wed, 20 February 2013 04:18 Go to previous messageGo to next message
Urs Beeli is currently offline Urs Beeli
Messages: 318
Registered: October 2012
Location: Bern, Switzerland
Senior Member
Lukas, thanks for your answer. Unfortunately, calling scrollTableDown() in execFormActivated() doesn't work either...

However, if I comment out the line with deselectAllRows(), then it even works if only called at the end of refreshForm(). I think I can live with that.

I have thought about sorting the table in reverse order and while that would work it can be a bit counter-intuitive at times.
Re: Modifying table behaviour [message #1013878 is a reply to message #1011795] Sun, 24 February 2013 10:28 Go to previous messageGo to next message
Beat Schwarzentrub is currently offline Beat Schwarzentrub
Messages: 43
Registered: November 2010
Member
Lukas is right. In most cases, model events that affect the UI are simply discarded when the UI is not ready yet. (Technically, they are not discarded - there is simply no one there to listen to the events!)

Quote:

However, if I comment out the line with deselectAllRows(), then it even works if only called at the end of refreshForm(). I think I can live with that.


Not sure about this... Sometimes, multiple events are "collected" and the fired all together. Multiple events for the same thing are compacted to a single event (two selection events in the model for the same row only have to be selected once in the UI to get the desired state) and events that neutralize themselves are neglected. So it might be, that in your case Scout thinks: "Why should I selected a single row, when they all should be deselected moments later anyway?"

You could try to postpone the "deselectAll" event using a ClientSyncJob:
  public void scrollTableDown() {
    getTableField().getTable().selectLastRow();
    new ClientSyncJob("deselect all later", ClientSyncJob.getCurrentSession()) {
      @Override
      protected void runVoid(IProgressMonitor monitor) throws Throwable {
        getTableField().getTable().deselectAllRows();
      }
    }.schedule();
  }


But I'm not sure if this works. If not, you could debug the application and "chase" the event (to see where it is ignored).

Beat
Re: Modifying table behaviour [message #1014135 is a reply to message #1013878] Mon, 25 February 2013 03:39 Go to previous message
Urs Beeli is currently offline Urs Beeli
Messages: 318
Registered: October 2012
Location: Bern, Switzerland
Senior Member
Beat

Thanks for your answer. I've tried the scheduled approach, but that didn't work either, not even when I delay it by 100ms, to give scout time to consume the first event...

I tried debugging the two lines (selectLastRow() and deselectAllRows()) but in both case I got as far as the TabelEvent() constructor where the chain ends, I haven't yet found out who consumes these events and where to set a breakpoint.

However, I can live with the solution of just leaving out the deselection of rows and have the last row always be selected, so I'm happy to let this rest here Smile
Previous Topic:How to extend the LoginDialog
Next Topic:deployment problem
Goto Forum:
  


Current Time: Thu Jul 24 09:01:12 EDT 2014

Powered by FUDForum. Page generated in 0.02371 seconds