Eclipse Community Forums: Eclipse Scout » Modifying table behaviour

Home » Eclipse Projects » Eclipse Scout » Modifying table behaviour(Scrolling to the end after inserting new elements)

Show: Today's Messages :: Show Polls :: Message Navigator

Modifying table behaviour [message #1008611]

Wed, 13 February 2013 09:40

Urs Beeli

Messages: 573
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?

Report message to a moderator

Re: Modifying table behaviour [message #1008621 is a reply to message #1008611]

Wed, 13 February 2013 10:51

Jeremie Bresson

Messages: 1252
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

Report message to a moderator

Re: Modifying table behaviour [message #1008714 is a reply to message #1008621]

Wed, 13 February 2013 16:58

Urs Beeli

Messages: 573
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.

Report message to a moderator

Re: Modifying table behaviour [message #1008956 is a reply to message #1008714]

Thu, 14 February 2013 08:01

Jeremie Bresson

Messages: 1252
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)?

Report message to a moderator

Re: Modifying table behaviour [message #1010753 is a reply to message #1008956]

Mon, 18 February 2013 07:21

Urs Beeli

Messages: 573
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"/>

Report message to a moderator

Re: Modifying table behaviour [message #1011558 is a reply to message #1010753]

Tue, 19 February 2013 19:45

Lukas Huser

Messages: 42
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...

Report message to a moderator

Re: Modifying table behaviour [message #1011795 is a reply to message #1011558]

Wed, 20 February 2013 09:18

Urs Beeli

Messages: 573
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.

Report message to a moderator

Re: Modifying table behaviour [message #1013878 is a reply to message #1011795]

Sun, 24 February 2013 15:28

Beat Schwarzentrub

Messages: 205
Registered: November 2010

Senior 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

Report message to a moderator

Re: Modifying table behaviour [message #1014135 is a reply to message #1013878]

Mon, 25 February 2013 08:39

Urs Beeli

Messages: 573
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

Report message to a moderator

Previous Topic:	How to extend the LoginDialog
Next Topic:	deployment problem

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Apr 20 00:19:40 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter