public class PeriodicRefreshHandler
extends java.lang.Object
| Modifier and Type | Field and Description |
|---|---|
int |
refreshDelaySeconds |
| Constructor and Description |
|---|
PeriodicRefreshHandler() |
| Modifier and Type | Method and Description |
|---|---|
boolean |
canExecute(MHandledItem handledItem)
Always returns true, since only CHECK menu items are expected to trigger the call,
and they get selected or unselected but always are enabled.
|
void |
dispose() |
void |
execute(MHandledItem handledItem)
Starts a
NotifyServiceUpdateJob with 10 seconds refresh period,
which will notify the interested parts via the IEventBroker. |
void |
init() |
public final int refreshDelaySeconds
@PostConstruct public void init()
public boolean canExecute(MHandledItem handledItem)
Hack: We abuse this method to 'harvest' all relevant menu items in menuItemsToSync,
so that we can later synchronize their selection state (all checked or unchecked).
See http://www.eclipse.org/forums/index.php/t/442970/ and http://www.eclipse.org/forums/index.php/t/444326/
and http://comments.gmane.org/gmane.comp.ide.eclipse.e4.devel/7870
about alternative workarounds, that I found not working or uglier than this harvesting.
There it also explains why EModelService#findElements is not working for menu items,
and other current limitations of E4 like not having a HandlerUtil class to sync stateful menu items.
I believe that having moved the menu items away from the java code into the e4xmi file, there
should also be a declarative way to form synchronization groups of stateful menu items.
public void execute(MHandledItem handledItem)
NotifyServiceUpdateJob with 10 seconds refresh period,
which will notify the interested parts via the IEventBroker.
An alternative implementation could get parameter @Active MPart part injected
and notify the part directly, without IEventBroker.
@PreDestroy public void dispose()