|
|
|
|
|
|
|
Re: Modifying table behaviour [message #1013878 is a reply to message #1011795] |
Sun, 24 February 2013 15:28 |
|
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.05241 seconds