Skip to main content

JXButton setText not updating button text with background painter

3 replies [Last post]
vkeiser
Offline
Joined: 2011-11-30
Points: 0

I am using several JXButtons for which I am setting background painters (a matte painter with a linear gradient paint). When I have the painter set and I try to change the text with setText, the text simply does not change. I have tried to getText() on the JXButton and it shows the updated value, but the button does not display it. When I do not set a painter, the button text updates fine.

Is there something that I am missing to get this to work correctly? I did try calling repaint() on it.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kschaefe
Offline
Joined: 2006-06-08
Points: 0

I used JXButtonVisualCheck.interactiveBackgroundCheck to verify this issue.  I am not seeing a problem.

Are you sure that you are updating the button text on the Event Dispatch Thread.  If so, can you please provide a small, runnable demo?

Karl

vkeiser
Offline
Joined: 2011-11-30
Points: 0

I added an java.awt.EventQueue.invokeLater so that it was getting called on the Event Dispatch thread and I am still seeing the issue. However, I am not seeing it in a small self-contained test program that I put together, which leads me to believe I am missing some element of what causes the problem.

I tried with the same painter settings, button parameters, grid bag constraints, and format of calling from an independent thread, with the same enabling and disabling and painter resettings, but it still occurs in my main program and not my test program. I did a search through my code of all the times this button is used, so I don't believe I am doing anything else to it that I haven't captured in my test, but something seems to be missing.

If you have any ideas, I would be glad to check anything, and if not, I will post when I can reproduce it in a test program.

kschaefe
Offline
Joined: 2006-06-08
Points: 0

If you know the modifications are occuring on the EDT, then the best bet is adding functionality to the working test case from the broken code until you trip the issue and isolate what is causing the problem.  No magic bullet here that I can think of.

Karl