Home » Eclipse Projects » Eclipse Platform » FireHandlerChanged doesn't work from non-GUI thread
|
| Re: FireHandlerChanged doesn't work from non-GUI thread [message #326724 is a reply to message #326712] |
Mon, 31 March 2008 11:34   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
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 #326740 is a reply to message #326724] |
Mon, 31 March 2008 13:04 |
 Jasper
Messages: 84
Registered: July 2009 |
Member |
|
|
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 13:40 |
|
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
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
Goto Forum:
Current Time: Wed Jul 17 12:23:38 GMT 2024
Powered by FUDForum. Page generated in 0.04295 seconds |
] 
Search
Help
Register
Login
Home
