|
|
Re: Proper way to update UI from EContentAdapter [message #1011978 is a reply to message #1011970] |
Wed, 20 February 2013 16:11 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Jonathan,
Comments below.
On 20/02/2013 5:04 PM, Jonathan Jekeli wrote:
> I have an econtent adapter that is essentially causing the refresh of
> numerous tables. While it is theoretically possible to filter all
> notifications down to the exact notifications that should cause a
> refresh on the tables, it would be extraordinarily difficult and
> time-consuming as we have a massive model, and many different events
> and changes that could possibly trigger a refresh. Also, what often
> happens is a single "user-event" (like clicking state->new in our
> application), triggers 4 objects being created behind the scenes, all
> of which look very similar from the notification standpoint and
> therefore makes it difficult to filter out. I'm wondering if there is
> a good way to do some sort of "delayed job" so that the 4
> notifications only cause a single refresh. For example, something
> similar to:
>
> public void notifyChanged(final Notification notification)
> super.notifyChanged(notification);
> @Override
> public void run() {
> if(matchesFilters(notification)) { //some sort of
> check to see if we recently had another event that would have
> triggered a refresh?
> if(!schedulingJob) {
> scheduleDelayedJob();
> }
> } }
> }
In
org.eclipse.emf.edit.ui.provider.AdapterFactoryContentProvider.notifyChanged(Notification)
you can see it uses a
org.eclipse.emf.edit.ui.provider.AdapterFactoryContentProvider.ViewerRefresh
to do something like that.
> Unfortunately I have little experience in jobs and things like that,
> so it would be very helpful if someone could give assistance in what
> the proper way of doing this is.
Are you using an EditingDomain to support undo? In that case, listening
to the command stack would be much easier. That's how the generated
editor updates the properties view...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03377 seconds