FULL PRODUCT VERSION :
all versions (up-to and including the mustang snapshot build 44)

ADDITIONAL OS VERSION INFORMATION :
irrelevant

EXTRA RELEVANT SYSTEM CONFIGURATION :
irrelevant

A DESCRIPTION OF THE PROBLEM :
The problem is any code in the ui-delegates that tries to get hold of a special type of LookAndFeel and ui-delegate class:

if (mycomp.getUI() instanceof SomeUI) {
    dosomething();
}

myUI = mycomp.getUI();
if (myUI instanceof SomeUI) {
   dosomething();
}

myUI = BasicLF.getUIOfType(mycomp.getUI(), SomeUI.class);
if (myUI != null) {
  dosomething();
}

(similar for checking the type of LookandFeel)

In all these cases the dosomething() is not executed if an auxiliary LF is added: then the getUI() returns MultiLookAndFeel and the instanceof  check is false.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :

nothing to reproduce - some behaviour silently isn't executed. Before fixing #4842445 an error was thrown. The fix solved the underlying reason - the returned ui is MultiLookAndFeel - only incompletely.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------

no code - it's a code quality error!  I rate the severity high because any application is potentially unstable as soon as an aux LF is set. This instability may express itself at unexpected places ("loading audiomap doesn't work") , the real reason difficult to locate and such  requiring long and difficult debugging sessions. There's nothing an application programmer can do to solve - short of not adding aux LF.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :

no workaround, this is solvable in core swing only. All ui-delegates need to be aware of the MultiLF:

ui = mycomp.getUI
if (uiinstanceof MultiXXUI)
   ui= ((MultiXXUI) myui).getUIs()[0]
myui = BasicLF.getUIOfType(ui, someui.class);
if (myui != null)
  dosomething();

similar for LookAndFeel types.

In the long run this should be moved as a public service into LookAndFeel: this requires to add some means to recognize a MultiXXUIs - f.i. an interface with the method getUIs and the same contract as the multiXXUIs getUIs(). It's important to guarantee that the first entry has the "real" UI.

Have fun when cleaning up <g>

Jeanette
Posted Date : 2005-08-05 15:37:04.0

N/A

N/A

The solution should not only be aware of MultiLF, but generally any LF that is used instead of MultiLF. 

I have written a LF that encapsulates and delegates ComponentUI methods calls to the contained LF. The contianed LF can be any existing LF. The reason for doing this is to get complete control over the contained LF. My LF adds a few features, e.g., encapsulated paint/update method to overwrite on client area and/or return slightly different values from non-void methods.  This works accept for some controls where the contained LF uses BasicLookAndFeel->getUIOfType() API. These controls donot respond to keyboard if my LF is active.

Pramod.