| Modifying table behaviour [message #1008611] |
Wed, 13 February 2013 04:40  |
Eclipse User |
|
|
|
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 #1013878 is a reply to message #1011795] |
Sun, 24 February 2013 10:28  |
| Eclipse User |
|
|
|
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
|
|
|
|
Powered by
FUDForum. Page generated in 0.07058 seconds
Home