Home » Eclipse Projects » Eclipse Platform » FireHandlerChanged doesn't work from non-GUI thread
| FireHandlerChanged doesn't work from non-GUI thread [message #326712] |
Sun, 30 March 2008 23:13  |
Eclipse User |
|
|
|
In 3.3.2, when a handler calls #fireHandlerChanged in a thread that
isn't the GUI thread, then associated menu items do not get updated. The
call appears to just get ignored. So currently the only way to
enable/disable menu items in response to background events (e.g. message
received over the network), is to asyncExec the fireHandlerChanged call,
which strikes me as awkward.
Is this behavior by design or is this a bug?
Thanks,
Jasper.
|
|
| | |
| Re: FireHandlerChanged doesn't work from non-GUI thread [message #326740 is a reply to message #326724] |
Mon, 31 March 2008 09:04  |
| Eclipse User |
|
|
|
Ed,
It seems like a pretty severe drawback to me. Imo, this is an(other)
example of how the Command/Handler/MenuItem approach of not
re-evaluating enablement state unless the framework is explicitly
notified of a change to such state, is in practice not as flexible a
setup as the old Actions approach in which enablement was always checked
immediately prior to re-rendering.
In the latter approach, it was irrelevant which thread set the
enablement. In the current approach, the caller needs to be aware of
what thread it's in, which is odd, and needs to async the call, making
it impossible to avoid a dependency on SWT.
My $0.02 worth :-)
Thanks,
Jasper.
Ed Merks wrote:
> Jasper,
>
> Given that SWT checks that all display/widget access is done on the
> display's thread, this seems like a necessary thing...
>
>
> Jasper wrote:
>> In 3.3.2, when a handler calls #fireHandlerChanged in a thread that
>> isn't the GUI thread, then associated menu items do not get updated.
>> The call appears to just get ignored. So currently the only way to
>> enable/disable menu items in response to background events (e.g.
>> message received over the network), is to asyncExec the
>> fireHandlerChanged call, which strikes me as awkward.
>>
>> Is this behavior by design or is this a bug?
>>
>> Thanks,
>> Jasper.
|
|
| |
| Re: FireHandlerChanged doesn't work from non-GUI thread [message #326743 is a reply to message #326740] |
Mon, 31 March 2008 09:40 |
| Eclipse User |
|
|
|
Jasper wrote:
> Ed,
>
> It seems like a pretty severe drawback to me. Imo, this is an(other)
> example of how the Command/Handler/MenuItem approach of not
> re-evaluating enablement state unless the framework is explicitly
> notified of a change to such state, is in practice not as flexible a
> setup as the old Actions approach in which enablement was always checked
> immediately prior to re-rendering.
Actions don't do this either, they only re-check their state under a
limited set of circumstances. They're the worst combination of MVC in
one class.
>
> In the latter approach, it was irrelevant which thread set the
> enablement. In the current approach, the caller needs to be aware of
> what thread it's in, which is odd, and needs to async the call, making
> it impossible to avoid a dependency on SWT.
Actually, it did matter ... simply that ActionContributionItem added the
non-UI thread protection ages ago, and it was missed in
CommandContributionItem.
Later,
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/workbench.htm
|
|
|
Goto Forum:
Current Time: Thu Oct 30 23:46:44 EDT 2025
Powered by FUDForum. Page generated in 0.04545 seconds |
Home