Community
Participate
Working Groups
Created attachment 251094 [details] Plug-in project to reproduce described problem The method org.eclipse.core.commands.AbstractHandler#fireHandlerChanged(), when called with a HandlerEvent parameter indicating that the enabled status has changed, no longer causes the UI to be updated. Indeed, the handler's isEnabled() method is not even being called by the framework. In Eclipse 3.x, the handlerChanged event was (indirectly) being received by the command associated with the handler, which in turn issued a commandChanged event that was picked up by a CommandContributionItem. The latter reacted to the event by obtaining the current enabled status from the handler and updating the UI. In Eclipse 4.4, a fireHandlerChanged() still results in the command getting a handlerChanged event and it still raises a commandChanged event in response, but unfortunately there do not appear to be any attached listeners that feel responsible for updating the UI! I suspect that the behavior changed with the introduction of the E4 model in Eclipse 4.x, but we didn't notice the missing update in our application because at the same time a toolbar updater was introcuded into the Eclipse framework that was automatically updating the UI every 400 ms. This periodic update was, however, intentionally removed in Eclipse 4.4 (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=385394), whereupon the missing UI update became obvious. Because the affected commands in our application use a core expression based on the selection source provider, a toolbar update can be implicitly forced by changing the selection (or even re-selecting what's already selected), but this seems like a clumsy workaround to suggest to our users simply in order for them to make sure the status of the toolbar is synchronized with the internal state of the application. Note that I have provided a zip file as an attachment, containing a sample plug-in project illustrating the problem. After unzipping and importing the project, further instructions for reproducing the problem can be found in the project's README file.
I believe the framework code needs to send out the event to evaluate the handler. Gerrit patches are welcome.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I re-tested with the latest released version of "Eclipse IDE for Enterprise Java and Web Developers": Version: 2021-03 (4.19) Build id: I20210303-1800 Result: The problem still occurs. Because I am still interested in a fix, I am re-opening this bug report. For testing, I used the attached example from 2015-02-25, which now causes a couple of warnings related to the newer java version, but still runs fine. The example uses the Navigator view, which is now deprecated, but the reported bug is not specific to any particular workspace part. As already mentioned, the instructions for using the example project are contained within its README file. If any of the described steps are unclear, please do not hesitate to contact me.
