Hi Patrick,
The base answer to the original question is that rotation doesn't apply
very well to components and it would be very dificult to produce that result
directly. Here's why:
First, let me mention some terminology. All Swing components are
Containers and Components; Here, I mean Containers more in their AWT
sense, something that is primarily meant to contain something else. The
classic is Panel/JPanel.
We'd like to rotate a panel and then draw the components, with the
result that all components are rotated. We'd also like to avoid subclassing
any component to be rotated. Turns out there are problems in both cases.
Component subclasses: Components have their own graphics sent, and
possibly clipped, in their paint routines ( I include here paintComponent(),
etc. ) However, to rotate, we need space at least equal to width x width.
If we want to rotate around a central point, size needs to be at least
width x 2 ) by ( width x 2 .) But standard component size is width x
height. We can make the component larger, but, if it worked we'd still face
the same problem. Actually, what usually happens is that the size inside
the component border is increased. We may, with a lot of work, get the
contents ( usually text ) to rotate, but it doesn't look much like the
standard version of the component. And each one must be subclassed. Oh,
and we'd like the transformation to be done in or prior to the paint() call,
so that it is applied to the border, the component and its children instead
of producing a mess.
Container rotation: If we rotate the graphics of a container like
(J)Panel instead, it does nothing for its component children unless the
transformed graphics is sent to the component to use for painting. This
actually works, ONCE per time the container's paint() is called.
Unfortunately, when the component's paint() is called outside of the
container routine, an unrotated graphics is sent. A prime example is a
normal text component. Apparently the standard Caret routine sets up a
timer and calls the component's paint() periodically, alternating Caret
draws to simulate a blinking cursor. Result? Rotated component in one area
usually with a 'stuck' caret, active version unrotated.
I have no doubt that all of these problems can be overcome ( cleanly? I
don't know, ) but who wants to put in that kind of effort? Not me,
especially for free.
As Patrick knows, I contacted him with a request for further info. As I
interpret things, what he really needs is to be able to rotate the CONTENTS,
primarily text, of a component. Now, text and images, not being components,
are the kind of things that transforms can work with quite well. What
occurred to me was, why not just get the TEXT from the component and rotate
that ( using drawString()? ) If that's not good enough, then how about just
drawing the component in a container when requested, with rotation? We
know from above that works too.
So, that's what the attached code does. While the set up flow of the
program is a little unusual and should obviously be changed for a real
program ( JPanel does the work, but I wanted everything for the sample in
one class, ) the logic should be fairly easy to follow. AND, while there's
a limit to what I'll do for free, this looks to be amenable to expansion in
a fairly generic way. For any of those out there who want to actively key
into a 237 degree rotated component, have at it or send me lots of
cash ;-) ) Any comments or different approaches welcome.
Joe Sam
Joe Sam Shirah
Autumn Software
What you don't know DOES hurt you...and your business
___________________________________________
RJC.java
