| Discouraged access of RWTLifeCycle.setSessionDisplay(Display) [message #547331] |
Fri, 16 July 2010 06:16  |
Eclipse User |
|
|
|
Hi,
I would like to extend org.eclipse.swt.widgets.Display with some custom
features, so I subclassed it and call
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.setSessionDi splay(Display)
before the initial call to org.eclipse.ui.PlatformUI.createDisplay().
This way org.eclipse.swt.widgets.Display.getCurrent() always returns my
Display-Subclass.
1) I know this way is kind of a hack, but I could not find a straighter
way to achieve my target. Any comments?
2) In eclipse the call to
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.setSessionDi splay(Display)
shows a warning "Discouraged access". Can you please comment on this
warning? Why is it marked as discouraged? Can I ignore the warning?
Regards,
Philipp
|
|
|
|
|
| Re: Discouraged access of RWTLifeCycle.setSessionDisplay(Display) [message #547355 is a reply to message #547338] |
Fri, 16 July 2010 07:50  |
| Eclipse User |
|
|
|
Hi Philipp,
subclassing Display is a misuse of the SWT API. You should definitely
not do that. If you need to attach application data to the Display, you
can use Display#setData. But I'd also feel that the session is the right
place to store it.
Regards, Ralf
Philipp Leusmann wrote:
> Am 16.07.2010 13:01, schrieb Stefan Roeck:
>> Hi Philipp,
>>
>>> 1) I know this way is kind of a hack, but I could not find a
>>> straighter way to achieve my target. Any comments?
>>
>> If you want to store data per session you could use a SessionSingleton.
>> What's your use case?
>
> Views in our application may receive events to notify them of available
> udates.
> The common base class we derive all our views from, shows a dialog to
> notify the user, but as you can imagine, this dialog should only be
> shown once per update.
> So i decided to use a semaphore and I thought the display would be a
> convenient place to store it. Of course I could put it directly into the
> session, but still I think it fits nicely into the Display ;)
>
> You have any other recommendations?
>
> Regards,
> Philipp
|
|
|
| Re: Discouraged access of RWTLifeCycle.setSessionDisplay(Display) [message #547356 is a reply to message #547355] |
Fri, 16 July 2010 08:23 |
| Eclipse User |
|
|
|
Ok guys, you convinced me. A SessionSingleton is even cooler ;)
Am 16.07.2010 13:50, schrieb Ralf Sternberg:
> Hi Philipp,
>
> subclassing Display is a misuse of the SWT API. You should definitely
> not do that. If you need to attach application data to the Display, you
> can use Display#setData. But I'd also feel that the session is the right
> place to store it.
>
> Regards, Ralf
>
> Philipp Leusmann wrote:
>> Am 16.07.2010 13:01, schrieb Stefan Roeck:
>>> Hi Philipp,
>>>
>>>> 1) I know this way is kind of a hack, but I could not find a
>>>> straighter way to achieve my target. Any comments?
>>>
>>> If you want to store data per session you could use a SessionSingleton.
>>> What's your use case?
>>
>> Views in our application may receive events to notify them of available
>> udates.
>> The common base class we derive all our views from, shows a dialog to
>> notify the user, but as you can imagine, this dialog should only be
>> shown once per update.
>> So i decided to use a semaphore and I thought the display would be a
>> convenient place to store it. Of course I could put it directly into the
>> session, but still I think it fits nicely into the Display ;)
>>
>> You have any other recommendations?
>>
>> Regards,
>> Philipp
|
|
|
Powered by
FUDForum. Page generated in 0.05332 seconds
Home