Alt key calls paintImmediately() on all my JLabels

Thread view:

Belinda - 25 Oct 2005 23:26 GMT

I'm trying to figure out how to tell the system that I don't want a
particular JLabel to paint when someone presses the alt key in my app.

I think it has to do with mnemonics, but I've set my jlabel to have no
mnemonic (setDisplayedMnemonicIndex(-1) which was already the default).

I've also tried setting:
setLabelFor(null);
setEnabled(false);
setIgnoreRepaint(true);
setFocusable(false);
setToolTipText(null);
setTransferHandler(null);

But I still get a call to paintImmediately() whenver the user presses the
alt key anywhere in the app.

setVisible(false) is the only thing which stopped the JLabel from getting
any paint commands on the alt key (not very practical unfortunately).

How can I stop this?

-BP

Reply to this Message

Roedy Green - 26 Oct 2005 02:53 GMT

>But I still get a call to paintImmediately() whenver the user presses the
>alt key anywhere in the app.

Can you get a stack track to find out who is calling it? That may
give you a clue how to suppress it.

hint:
insert newThrowable().printStackTrace();
in an overridden paintComponent.

See http://mindprod.com/jgloss/trace.html
http://mindprod.com/jgloss/debugger.html

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

Andrey Kuznetsov - 26 Oct 2005 06:52 GMT

>>But I still get a call to paintImmediately() whenver the user presses the
>>alt key anywhere in the app.
[quoted text clipped - 5 lines]
> insert newThrowable().printStackTrace();
> in an overridden paintComponent.

in an overridden paintImmediately().
Ensure also that you override _both_ variants of paintImmediately()

Signature

Andrey Kuznetsov
http://uio.imagero.com Unified I/O for Java
http://reader.imagero.com Java image reader
http://jgui.imagero.com Java GUI components and utilities

Reply to this Message

Roedy Green - 26 Oct 2005 07:09 GMT

On Wed, 26 Oct 2005 07:52:41 +0200, "Andrey Kuznetsov"
<spam0@imagero.com.invalid> wrote, quoted or indirectly quoted someone
who said :

>> hint:
>> insert newThrowable().printStackTrace();
>> in an overridden paintComponent.
>
>in an overridden paintImmediately().
>Ensure also that you override _both_ variants of paintImmediately()

Good idea. that would avoid generating stacktraces for ordinary
repaints.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

Belinda - 26 Oct 2005 19:15 GMT

> On Wed, 26 Oct 2005 07:52:41 +0200, "Andrey Kuznetsov"
> <spam0@imagero.com.invalid> wrote, quoted or indirectly quoted someone
[quoted text clipped - 9 lines]
> Good idea. that would avoid generating stacktraces for ordinary
> repaints.

The message is indeed a paintImmediately (actually _paintImmediately())
called directly on this label by the system.

My purpose in all of this was to avoid repainting labels at certain times
because I was overlapping some of them with a semi-transparent JPanel.

I could take control of the painting of the labels, but I haven't found a
way to ask, "am I obscured by another component?" (beyond checking for
componentAt for every pixel of the label).

Currently when someone hit's the ALT key, all the JLabels paint right
through my semi-transparent layer.

-BP

Reply to this Message

Christian Kaufhold - 28 Oct 2005 17:16 GMT

> > On Wed, 26 Oct 2005 07:52:41 +0200, "Andrey Kuznetsov"
> > <spam0@imagero.com.invalid> wrote, quoted or indirectly quoted someone
[quoted text clipped - 9 lines]
> > Good idea. that would avoid generating stacktraces for ordinary
> > repaints.

> The message is indeed a paintImmediately (actually _paintImmediately())
> called directly on this label by the system.

To clarify, this is the normal way repainting is actually done, so this
is just the normal reaction to an earlier repaint().

In all Java 1.5 versions I have here, the label is not repainted if it
has no mnemonics, while in 1.4 this check is missing. There is nothing
to avoid this, except replacing WindowsRootPaneUI (probably completely).

> My purpose in all of this was to avoid repainting labels at certain times
> because I was overlapping some of them with a semi-transparent JPanel.

> I could take control of the painting of the labels, but I haven't found a
> way to ask, "am I obscured by another component?" (beyond checking for
> componentAt for every pixel of the label).

> Currently when someone hit's the ALT key, all the JLabels paint right
> through my semi-transparent layer.

If this causes real painting problems (pixel garbage), then it is not set up
correctly (isOpaque).

Christian

Reply to this Message

Chris Smith - 26 Oct 2005 04:31 GMT

> I'm trying to figure out how to tell the system that I don't want a
> particular JLabel to paint when someone presses the alt key in my app.

> But I still get a call to paintImmediately() whenver the user presses the
> alt key anywhere in the app.

This shouldn't be a problem. Painting ought to be fairly simple, and
calling it any number of times is functionally identical to calling it
once. If your paint operation is expensive enough to make a big
difference, you may want to consider painting into an off-screen image
when anything changes, and just copying that off-screen image onto the
screen from paintComponent.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

Andrey Kuznetsov - 26 Oct 2005 06:50 GMT

>> I'm trying to figure out how to tell the system that I don't want a
>> particular JLabel to paint when someone presses the alt key in my app.
[quoted text clipped - 5 lines]
> calling it any number of times is functionally identical to calling it
> once.

not in case of paintImmediately()

Signature

Andrey Kuznetsov
http://uio.imagero.com Unified I/O for Java
http://reader.imagero.com Java image reader
http://jgui.imagero.com Java GUI components and utilities

Reply to this Message

Chris Smith - 26 Oct 2005 17:17 GMT

> > This shouldn't be a problem. Painting ought to be fairly simple, and
> > calling it any number of times is functionally identical to calling it
> > once.
>
> not in case of paintImmediately()

Can you explain what you're trying to say?

The paintImmediately method does nothing but arrange for paint to be
called and completed before paintImmediately returns. I don't see how
it differs in any considerably respect from my description above.

Calling paintImmediately very frequently (say, on the order of tens of
times per second) might indeed be a performance concern. However, it's
just not physically possible for a human being to press and release the
alt key often enough that it should cause any significant performance
problem in your application. There is a chemical delay in the nerve
synapse that provides this guarantee. And if you really need that extra
5% or so performance gain that might be possible, then tell the stupid
user to stop pressing alt as fast as humanly possible. :)

Seriously, I suspect that you've put expensive code into paintComponent
that would be best run elsewhere.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

Andrey Kuznetsov - 26 Oct 2005 19:36 GMT

>> > This shouldn't be a problem. Painting ought to be fairly simple, and
>> > calling it any number of times is functionally identical to calling it
[quoted text clipped - 3 lines]
>
> Can you explain what you're trying to say?

if you call many times repaint() then paint events may be coalesced,
if you call many times paintImmediately() then nothing is coalesced.

> Calling paintImmediately very frequently (say, on the order of tens of
> times per second) might indeed be a performance concern. However, it's
> just not physically possible for a human being to press and release the
> alt key often enough that it should cause any significant performance
> problem in your application.

what is about press and hold? auto repeat may be pretty frequently...

Signature

Andrey Kuznetsov
http://uio.imagero.com Unified I/O for Java
http://reader.imagero.com Java image reader
http://jgui.imagero.com Java GUI components and utilities

Reply to this Message

Roedy Green - 26 Oct 2005 23:17 GMT

On Wed, 26 Oct 2005 20:36:26 +0200, "Andrey Kuznetsov"
<spam0@imagero.com.invalid> wrote, quoted or indirectly quoted someone
who said :

>what is about press and hold? auto repeat may be pretty frequently...

See http://mindprod.com/products1.html#KEYPLAY

It will show you what events get called when you do various things at
he keyboard.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

VisionSet - 26 Oct 2005 10:14 GMT

> ...you may want to consider painting into an off-screen image
> when anything changes, and just copying that off-screen image onto the
> screen from paintComponent.

Doesn't Swing's default double buffering do just this for you?

--
Mike W

Reply to this Message

Chris Smith - 26 Oct 2005 17:19 GMT

> > ...you may want to consider painting into an off-screen image
> > when anything changes, and just copying that off-screen image onto the
> > screen from paintComponent.
>
> Doesn't Swing's default double buffering do just this for you?

No. Double buffering writes to a temporary off-screen image as a step
in a single paint operation. My recommendation was to maintain an off-
screen image with a longer lifespan, which would keep intermediate
results from one paint operation to the next. This requires the
cooperation and knowledge of code that modifies the state of the
component, and cannot be done by Swing behind the scenes.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

Alt key calls paintImmediately() on all my JLabels

Free Magazines