Thread: Some swing components use wrong look and feel

Our application uses a custom Synth based look and feel. On a couple of demo laptops, when new components get created due to some incoming event, the new components use a different look and feel.

Instead of using our Synth look and feel, the new components get created with the default ( Windows 7 ) look and feel. It is very strange. Other machines using the same java version, 1.7.0_25-b17, work correctly.

Any ideas?

Please dont ask us to do your work for you.
Post the program that isn't working.

Originally Posted by llowe29

Please dont ask us to do your work for you.
Post the program that isn't working.

I don't believe the OP is asking anyone to do his/her work, and this doesn't sound like a homework problem. The OP presented the bare outline of a problem and is asking for suggestions on how to solve it. If you have some ideas what might be causing the OP's problem but believe more info would be helpful to understand the problem, e.g., the code that sets the look and feel or the code that is called when an "incoming event" occurs, then you could ask for more details.

In fact, I am not asking anyone do to my work for me. We have a very strange problem that only occurs on a couple of machines, and thought I might be able to get some help/suggestions here.

If it makes you feel better, llowe29, here is the code that sets the look and feel:

public class ClientLookAndFeel extends SynthLookAndFeel
{
public ClientLookAndFeel() throws UnsupportedLookAndFeelException
{
super();
try
{
load( ClientLookAndFeel.class.getResourceAsStream( "Client.xml" ), ClientLookAndFeel.class );
UIManager.setLookAndFeel( this );
}
catch ( final ParseException e )
{
// todo - Log it
}
}
}

This is the ONLY place where the look and feel is set in the application. The rest of the application is proprietary and way to large to post. When the program starts, the components all look correct. At some point new components are created, and they use the Windows look and feel. Right in the middle of a panel that is using our look and feel.

Please post your code in code tags.

I don't have much experience with changing the look and feel from whatever the host OS prefers to use, but if I were you, I'd wonder why the look and feel changes made by my application aren't persistent. Or, said a different way, if the look and feel is going to change (for whatever reason), how can one ensure that it always returns to what it needs to be when the desired application has focus? Since the look and feel is often set at the OS level, I can see how the look and feel behavior might vary from computer to computer depending on the applications sharing the OS, so think about the problem in a bigger space, not just within the boundaries of your application.

I suggest that your application reset the look and feel to the desired look and feel each time it takes the focus and each time it processes an incoming event before new components are created, whether it has the focus or not (if that's possible).

Hope this helps and good luck!

Forgot the code tags, sorry.

Getting focus is NOT causing the problem. I can be actively using the application when the problem occurs. Example. Select a new value in a combo box. That triggers a JNI call to a DLL which broadcasts an event. The swing part of the application listens for this event and then updates itself by deleting a series of buttons and creating a different series based on the data in the event. These new buttons use the Windows look and feel, even though the look and feel of the application has NOT been changed since the application was started. And, again, this only happens on a couple of machines.

I have been working with swing for 13 years and have never seen anything like this.

Thanks for trying to help.

--- Update ---

The look and feel is set in a call from the main() routine of the class used to launch the program.

I've always been told that removing components and adding new ones to an existing interface can be risky, so I've always avoided the practice. I don't know what 'risky' means, but perhaps the behavior you're experiencing is one of the risks.

Good luck. Sorry I can't be more helpful, but someone much smarter than me will probably happen along and have some ideas.

Thanks anyway.

--- Update ---

It wasn't wrapped in SwingUtillities.invokeLater(), but based on your suggestion, I just wrapped in in SwingUtillities.invokeAndWait() and am preparing a build now. Setting the look and feel is ususally the first thing I do in an application. I used invokeAndWait() because I need this to happen first or else out login dialog will not look right. If there is a problem with invokeAndWait(), I'll try invokeLater(). I'll just have to refactor the code so that the stuff to launch the login dialog is called from within the invokeLater() instead of the way it is now.

I honestly don't think this is the problem because the application look fine when it starts. I am giving it a shot though.

Thanks

After further digging, it appears that we are running into an know bug in java 7 update 25.

Bug ID: JDK-8017776 Swing Event Thread does not use JNLP class loader

More info can be seen in these threads:

https://forums.oracle.com/thread/2552214
https://forums.oracle.com/thread/2552941
https://forums.oracle.com/message/11090709#11090709
https://forums.oracle.com/thread/2556898

Only a few of the machines have been updated to java 7 update 25, that is why not everyone would see it.
Most of us are still on java 7 update 21. Also, the problem ONLY occurs when the application is launched via JNLP.
When the app is launched view command line or IDE, everything works fine.
In a nutshell, update 25 broke how the AppContext is maintained. Instead of there being only 1, there are now several.
We have tried the workarounds listed in the bug and threads ( launch console with app, set the class loader in the
EventQueue, etc ... ) but none of them worked for us. We are going to uninstall update 25 and reload update 21 on
the problem machines.

Good luck to anyone else that sees this. Hopefully Oracle will fix this soon.

Thanks for the update.