-
Bug
-
Resolution: Incomplete
-
P4
-
None
-
5.0
-
x86
-
windows_2000
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
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