I posted this last night in an existing thread, but after thinking on it further, it’s really its own issue…so moving it here. As I understand it, this isn’t a bug, per se, but it was a real counter-intuitive expectation for me.
I wanted to note some confusion around how the font-related LookAndFeelMethods affect the ComboBox (when applying a look and feel class to the whole plug-in editor component).
I was working on some code to conditionally change the font used in a ComboBox, and confirmed with
DBG output that I had the
getComboBoxFont method being called when expected – but it still wasn’t affecting the ComboBox’s font in the GUI.
Turns out the issue was that I had also implemented the L&F
getLabelFont method, to set the font for some controls’ labels. However, because the ComboBox uses a
label internally for its text display, the ComboBox’s font was actually being determined by
getLabelFont instead of by
If I removed the
getLabelFont method from my L&F, then the ComboBox’s font was then determined by
getComboBoxFont, as originally expected.
One solution for this case would be to write a more narrowly focused L&F that gets applied directly to the ComboBox component only (which I could then omit
getLabelFont from), rather than applying a single L&F to the whole editor. Or, if trying to stick with the One-L&F-To-Rule-Them-All approach, I could add some conditional checking within
getLabelFont to see which label it’s being applied to.
Not sure which way is going to be more convoluted and confusing to my future self. In any case, not realizing that
getLabelFont would override the ComboBox styling in
getComboBoxFont cost me several hours of troubleshooting, so I wanted to note that here and possibly save someone else the headache.