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?