[news.eclipse.platform.swt] Re: Background Color (return to default beha

[jared.warren@xxxxxxxxx (Jared Warren)]

Hey Carolyn - thanks for the response.

My particular use case is fairly complex, so I'm sure it's not 
representative of typical (I'm also not at all sure that we didn't 
duplicate functionality already done much better somewhere else in 
SWT...but alas...we were in a hurry :P )

I've implemented a "ShapeCanvas" library "around" the swt.Canvas.  The 
library adds all the listener support for everything that's drawn on the 
canvas (for example, if you draw a circle on the Canvas, our library 
allows you to detect clicks, focus changes, key events, etc on that 
circle...and yes, you can give shapes the focus, etc.)  When the canvas 
itself gets focus, I change the background color of the swt.Canvas as the 
visual queue to the end user that the canvas has focus (they can then use 
the arrows to change which shape inside the canvas has the focus, etc.)

The problem comes when the developer using the new library changes the 
background color on the swt.Canvas intentionally away from default, and 
enables focus listening.  In that case, when I change the background color 
to indicate that the canvas has focus, I don't know what color to change 
it back to when we lose focus (unless I can ask the canvas what background 
color it had, and expect a reasonably true response from getBackground(), 
or have a way to tell when I shouldn't expect a reasonably true response 
from getBackground().)

The solution I've implemented is adding a setBackground() on my 
ShapeCanvas.  This immediately changes the background color of the 
swt.Canvas (if the ShapeCanvas doesn't have focus,) and remembers it for 
when the ShapeCanvas is defocused.  The problem is that I haven't 
delegated all of the mutators for the swt.Canvas, and some of them are 
legitimately needed by the library user...so the library user can still 
get ahold of the swt.Canvas and manually change the background color 
(instead of using ShapeCanvas.setBackground()).  (This is similar to some 
of the problems in JFace, where the viewer doesn't fully encapsulate the 
underlying SWT widget, and the JFace library user can get the SWT widget 
and the JFace viewers in a whacky state by doing things they really 
shouldn't do to the underlying SWT widget.)

One could easily make the argument that the real fix is for me to fully 
encapsulate the swt.Canvas, but that has some downsides as well 
(especially in terms of long-term maintainability.)

Again...not the end of the world...and I can live without the 
hasDefaultXXX() methods...but would sure make my life easier if I had them 
:)

Carolyn MacLeod wrote:

> Hi, Jared.

> It's probably easier for you to cache the background color when your 
> application starts, and compare to that if you need to.
> Or even better, to keep track of whether or not you have set it (i.e. if you 
> didn't set it, then it's still set at the default).

> We wouldn't be able to change getBackground() to return null, because people 
> rely on it that api always returning a color.
> Note that if you do open a feature request to have new api something like 
> "hasDefaultBackground()", it would have to be for foreground and font also. 
> You would also have to explain why you need it - I'm a little unclear on 
> that.

> Carolyn

> "Jared Warren" <jared.warren@xxxxxxxxx> wrote in message 
> news:e7a5aedfdf886f7db7d9b0988c591a46$1@xxxxxxxxxxxxxxxxxx
> > Further investigation reveals that I can call setBackground(null) to get 
> > the Composite back into the "default" state.
> >
> > This will probably work for my immediate need; however, I don't see a way 
> > to tell if the Composite was in the "default" state before the first 
> > setBackground() (in other words, I can't handle the case where the 
> > background was previously set to a non-default state, because I can't ask 
> > the composite if it has been set or not.)
> >
> > Question:  If this were to be added (the ability to tell if a control's 
> > background is in the default state), would it be more appropriate to have 
> > "getBackground()" return "null", or would it be better to add an 
> > "hasDefaultBackground()" method?