Prev: Urgent Openings: 1.GIS Web Developer(.Net), 2.Business System Analyst, Austin, TX., 3.Maximo positions
Next: Looking things up by string prefix
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...





First  |  Prev  | 
Pages: 1 2 3
Prev: Urgent Openings: 1.GIS Web Developer(.Net), 2.Business System Analyst, Austin, TX., 3.Maximo positions
Next: Looking things up by string prefix