From: John B. Matthews on 3 Jul 2010 12:54 In article <4b158b30-ff42-4ef0-9348-36c102184d1a(a)d37g2000yqm.googlegroups.com>, FutureScalper <futurescalper(a)gmail.com> wrote: > On Jul 2, 2:48 pm, "John B. Matthews" <nos...(a)nospam.invalid> wrote: > > In article > > <737f986b-4e2a-4e5e-8a17-710b11b79...(a)e35g2000vbl.googlegroups.com>, > > > > FutureScalper <futurescal...(a)gmail.com> wrote: > > > I will dig into the code and see whether I can over-ride the > > > behavior, as one poster suggested. > > > > It looks like MetalTabbedPaneUI.TabbedPaneLayout achieves the > > effect you want by overriding the methods rotateTabRuns(), > > padSelectedTab() and normalizeTabRuns(). These methods are > > inherited from the superclass BasicTabbedPaneUI.TabbedPaneLayout. > > Thanks John for the tips on possible code workarounds. This app is a > high performance online Futures trading application and I can't > afford "operator error" due to the GUI arbitrarily reorganizing > itself. So I may try and work around it, or just stay with what I > have, or find another LAF which does not do this. I think the behavior is part of BasicTabbedPaneUI.TabbedPaneLayout unless overridden. Another LAF may or may not rely on it. Ignoring form, here's how I'd change the function: /** @author John B. Matthews */ class MyTabbedPane extends JTabbedPane { public MyTabbedPane() { this.setUI(new MyTabbedPaneUI()); } @Override public String getUIClassID() { return "MyTabbedPaneUI"; } @Override public void updateUI() { // preclude others } private class MyTabbedPaneUI extends BasicTabbedPaneUI { @Override protected LayoutManager createLayoutManager() { return new BasicTabbedPaneUI.TabbedPaneLayout() { @Override protected void rotateTabRuns( int tabPlacement, int selectedRun) { } @Override protected void padSelectedTab( int tabPlacement, int selectedIndex) { } }; } } } > All I wanted to do was to "skin" it a bit, and I found myself in all > of these "gotchas" :(
From: FutureScalper on 4 Jul 2010 08:43
On Jul 3, 12:54 pm, "John B. Matthews" <nos...(a)nospam.invalid> wrote: > In article > <4b158b30-ff42-4ef0-9348-36c102184...(a)d37g2000yqm.googlegroups.com>, > > > > > > FutureScalper <futurescal...(a)gmail.com> wrote: > > On Jul 2, 2:48 pm, "John B. Matthews" <nos...(a)nospam.invalid> wrote: > > > In article > > > <737f986b-4e2a-4e5e-8a17-710b11b79...(a)e35g2000vbl.googlegroups.com>, > > > > FutureScalper <futurescal...(a)gmail.com> wrote: > > > > I will dig into the code and see whether I can over-ride the > > > > behavior, as one poster suggested. > > > > It looks like MetalTabbedPaneUI.TabbedPaneLayout achieves the > > > effect you want by overriding the methods rotateTabRuns(), > > > padSelectedTab() and normalizeTabRuns(). These methods are > > > inherited from the superclass BasicTabbedPaneUI.TabbedPaneLayout. > > > Thanks John for the tips on possible code workarounds. This app is a > > high performance online Futures trading application and I can't > > afford "operator error" due to the GUI arbitrarily reorganizing > > itself. So I may try and work around it, or just stay with what I > > have, or find another LAF which does not do this. > > I think the behavior is part of BasicTabbedPaneUI.TabbedPaneLayout > unless overridden. Another LAF may or may not rely on it. Ignoring form, > here's how I'd change the function: > > /** @author John B. Matthews */ > class MyTabbedPane extends JTabbedPane { > > public MyTabbedPane() { > this.setUI(new MyTabbedPaneUI()); > } > > @Override > public String getUIClassID() { > return "MyTabbedPaneUI"; > } > > @Override > public void updateUI() { > // preclude others > } > > private class MyTabbedPaneUI extends BasicTabbedPaneUI { > > @Override > protected LayoutManager createLayoutManager() { > return new BasicTabbedPaneUI.TabbedPaneLayout() { > > @Override > protected void rotateTabRuns( > int tabPlacement, int selectedRun) { > } > > @Override > protected void padSelectedTab( > int tabPlacement, int selectedIndex) { > } > }; > } > } > > > > } > > All I wanted to do was to "skin" it a bit, and I found myself in all > > of these "gotchas" :( Thanks very much for that contribution which I may try to implement. One thing is clear: I can't have tabs moving all over the place. Too much operator error confusion in my application, which puts real money on the line for the trader. Off-topic is the further issue of the Security Warning (posted elsewhere) which is another Java "innovation" that kills my app's reliability, far more serious than this GUI issue. As in the GUI case, I may abandon using Nimbus; I may also have to abandon upgrading beyond Java 6 Update 17 as well unless I can find a workaround... |