Community
Participate
Working Groups
It turns out that this API as defined is essentially useless. If you know the MHandlerContainer to look in then the search is trivial. Since there are different UIElements that are also HandlerContainers we should be implementing this by extending the scope of the generic 'findElements' APIs by adding an 'IN_HANDLER_CONTAINERS' as a 'searchFlag' option. Interestingly it may be a good idea where possible to check the 'clazz' parameter and adjust the searchFlags where appropriate (i.e. if 'clazz' == MHandler then *set* the searchFlags to 'IN_HANDLER_CONTAINER' even if it wasn't specified by the user. NOTE: I'm not proposing that this be done in Luna necessarily, just the the existing API is useless as defined...
Here's the Gerrit patch for this: https://git.eclipse.org/r/24280
Hi Dani, This is the other API that needs to be fixed. Remove org.eclipse.e4.ui.workbench.modeling.EModelService.findHandler(MHandlerContainer, String) It was introduced in M5 and made obsolete in M6. I'd like to make sure it doesn't go out in Luna, if possible. PW
Paul / Dani, I've amended the commit to include the associated tests. These tests will fail until the actual search code is implemented (Paul has someone to do that I think). I've added the new code as comments as the implementation requires the new API from bug 431738.
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=5bce3c23abc377df17fa805da69e234a64277a61 PW
(In reply to Eric Moffatt from comment #3) > Paul / Dani, I've amended the commit to include the associated tests. These > tests will fail until the actual search code is implemented (Paul has > someone to do that I think). Is that the test that you expect to fail now (from N20140402-2000): EModelServiceFindTest.testFindHandler: N/A junit.framework.AssertionFailedError at org.eclipse.e4.ui.tests.application.EModelServiceFindTest.testFindHandler(EModelServiceFindTest.java:370) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:657) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:310) at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:36) at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:32) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:379) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:233) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) at org.eclipse.equinox.launcher.Main.main(Main.java:1438) at org.eclipse.core.launcher.Main.main(Main.java:34)
(In reply to Dani Megert from comment #5) > (In reply to Eric Moffatt from comment #3) > > Paul / Dani, I've amended the commit to include the associated tests. These > > tests will fail until the actual search code is implemented (Paul has > > someone to do that I think). > > Is that the test that you expect to fail now (from N20140402-2000): > > EModelServiceFindTest.testFindHandler: > Yes. We have a fix for it that will go in today. PW
Verified in 4.4.0.I20140428-2000.
