|
Replies:
13
-
Last Post:
Apr 11, 2008 9:14 AM
by: Kleopatra
|
|
|
|
|
|
|
JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 10, 2008 8:42 AM
|
|
|
This is hopefully a simple question.
I'm not clear from the javadoc on JXCollapsiblePane.CollapsiblePaneContainer as to what, exactly, is supposed to be returned from the getValidatingContainer() method.
Is this supposed to be the container that holds a JXCollapsiblePane? It would seem that a JXCollapsiblePane's parent is already validated. (And, BTW, wouldn't that make the container the validated container?)
I would greatly appreciate it if someone could explain what this interface is for and how to use it.
Thanks in advance--and thanks for this neat library!
Best,
Laird
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 10, 2008 8:54 AM
in response to: ljnelson
|
 |
Helpful |
|
|
I've never had to fool with it, but It is used by the JXCollapsiblePane to find the oldest ancestor that needs to be validated when the pane changes. The parent of the collapsible pane should implement that interface if normal validation fails (the display does not look correct after validation). JXTaskPane uses it to ensure that its parent (likely a JXTaskPaneContainer) properly validates.
Karl
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 10, 2008 10:02 AM
in response to: kschaefe
|
|
|
Thanks. One last related question, if I may.
I'm not sure of the invalidate()/validate()/repaint() handwaving that I have to do to make a JDialog "follow" the collapsing.
That is, I have a JDialog with a collapsible pane in it (as a child of the content pane...there are other children too). When I toggle it to the collapsed state, I'd like the dialog's size to be adjusted as well. Similarly, when I expand it, I'd like--dynamically if possible!--the dialog's size to be expanded as well.
I tried to make a subclass of JDialog that implemented the CollapsiblePaneContainer interface by returning "this", but nothing happened--toggling effectively just stopped altogether.
What's the best recipe for this kind of behavior?
Thanks again,
Laird
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 10, 2008 11:10 AM
in response to: ljnelson
|
|
|
That is interesting. I'd guess you need to make the content pane the CollapsiblePaneContainer. You may need to listen to the property change and react to it. Hmm. Let me know if you get something from my comments. If not, I'll toy with it tomorrow.
Karl
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 10, 2008 11:24 AM
in response to: kschaefe
|
|
|
OK, I'll try that. I had been wiring up dialog.pack() in a property change listener reacting to the "collapsed" property, but that was giving very odd results (yes, I was on the EDT :-)).
Perhaps I'll try the content (and then the root) pane and see what happens.
Thanks,
Laird
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 10, 2008 11:33 AM
in response to: ljnelson
|
|
|
No luck.
I get a strange blend of expected behavior and not expected behavior.
Here's another way to describe what I'd like to see happen--and maybe this component isn't the right one to do it.
Currently, when I first pack() the dialog, it reserves space for the expansion (because the preferredSize() of the collapsible pane allocates space? I guess? for the fully expanded pane, even when it's collapsed to start with). I understand why it does that, of course.
It would be nice if I could somehow--by way of the collapsible pane itself--tell the enclosing window to pack() all the way "over" the space that would otherwise be reserved for the expansion. Some sort of getPreferredCollapsedSize() method or something?
Thanks,
Laird
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 11, 2008 3:04 AM
in response to: ljnelson
|
|
|
Laird,
> OK, I'll try that. I had been wiring up dialog.pack() in a property change listener reacting to the "collapsed" property, but that was giving very odd results (yes, I was on the EDT :-)).
>
>
that's basically the RightThing (TM Kirill  , in fact explicitly
calling pack (or resizing to some previously stored size - users might
have changed the dialog) is the only way to "visually validate" a
top-level container. What happens here is that the animation interferes:
the collapsed property change is fired before the animated size change
is completed, so the pack is done on the old size. I remember that a
couple of years ago I tried to use a collapsible for the details part of
an ErrorPane and gave up (being impatient) Thingies could have changed
since then - do we get a property at the end of the animation phase? Hmm
... or maybe it's even a bit glitchy to fire the collapsed before the
internal changes are completed?
Anyway, added a visual test to JXTaskPaneIssues to show.
Cheers
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 11, 2008 7:45 AM
in response to: Kleopatra
|
 |
Correct |
|
|
> > OK, I'll try that. I had been wiring up
> dialog.pack() in a property change listener reacting
> to the "collapsed" property, but that was giving very
> odd results (yes, I was on the EDT :-)).
>
> that's basically the RightThing (TM Kirill , in
> fact explicitly
> calling pack (or resizing to some previously stored
> size - users might
> have changed the dialog) is the only way to "visually
> validate" a
> top-level container. What happens here is that the
> animation interferes:
> the collapsed property change is fired before the
> animated size change
> is completed, so the pack is done on the old size. I
> remember that a
> couple of years ago I tried to use a collapsible for
> the details part of
> an ErrorPane and gave up (being impatient) Thingies
> could have changed
> since then - do we get a property at the end of the
> animation phase? Hmm
> ... or maybe it's even a bit glitchy to fire the
> collapsed before the
> internal changes are completed?
You need to listen to ANIMATION_STATE_KEY property, which is fired upon completion of the animation. You could pack() then and get the correct size.
There is currently no property change, etc. for intervals. I guess we need one if we want to collapse/expand gracefully.
Karl
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 11, 2008 7:54 AM
in response to: kschaefe
|
|
|
Yes! Thank you.
Now to investigate why the collapsible pane doesn't honor a setCollapsed(true) call before it is installed into its parent.
L
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 11, 2008 9:14 AM
in response to: kschaefe
|
|
|
jdnc-interest@javadesktop.org schrieb:
> You need to listen to ANIMATION_STATE_KEY property, which is fired upon completion of the animation. You could pack() then and get the correct size.
>
ahhh ... I knew I overlooked something 
> There is currently no property change, etc. for intervals. I guess we need one if we want to collapse/expand gracefully.
>
>
yeah, probably - if "gracefully" means to animate the pack of the
top-level as well.
Have a nice weekend everybody
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 10, 2008 12:06 PM
in response to: kschaefe
|
|
|
Here is a (JUnit 4) test case that pops up a dialog box with a button in it, and does not react to ctrl F presses.
I would have expected the button to not be visible, initially, and I would have expected the ctrl F invocation to cause the pane to toggle.
@Test public void simpleTest() {
assertTrue(EventQueue.isDispatchThread());
final JXCollapsiblePane pane = new JXCollapsiblePane();
pane.add(new JButton("Hello there"));
pane.setCollapsed(true);
pane.getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW).put(KeyStroke.getKeyStroke("ctrl F"), JXCollapsiblePane.TOGGLE_ACTION);
final JDialog dialog = new JDialog((JDialog)null, true);
dialog.setLayout(new BorderLayout());
dialog.add(pane);
dialog.pack();
dialog.setVisible(true);
}
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 11, 2008 4:04 AM
in response to: ljnelson
|
|
|
jdnc-interest@javadesktop.org schrieb:
> Here is a (JUnit 4) test case that pops up a dialog box with a button in it, and does not react to ctrl F presses.
>
> I would have expected the button to not be visible, initially, and I would have expected the ctrl F invocation to cause the pane to toggle.
>
>
Hmm .. my expectation is a bit different: hidden components usually
don't get keybindings (or do they, not entirely sure). Not being sure
means to experiment ... so added another visual test method to the
taskPaneIssues: a plain hidden label doesn't get the binding, a hidden
taskpane child does. Do we want that? Would say no, but could be
convinced
As to the not opening in your test - could it be that the ctrl-F is
eaten somewhere else? For SwingX, the crtrl-F is bound in searchable
components inputMaps, usually in Ancestor_of_focused. ComponentInputMap
bindings _are_ weird One problem is that they are the last to see
that keystroke, that is they don't get it if some handler before in the
chain was interested and consumed it. So it could happen that it's not
the dialog but the owning window who "sees" the keystroke first. Plus if
there are more than one ComponentInputMaps (which is rather common in
real-world apps, as menu bindings are done by them) the order of
processing them is more or less unpredictable. With all those problems,
I try to stay away from them if possible
doohh ... probably not very clear but it's Friday <g>
HTH a bit at least
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 11, 2008 5:43 AM
in response to: Kleopatra
|
|
|
> jdnc-interest@javadesktop.org schrieb:
> > I would have expected the button to not be visible,
> initially, and I would have expected the ctrl F
> invocation to cause the pane to toggle.
> Hmm .. my expectation is a bit different: hidden
> components usually
> don't get keybindings (or do they, not entirely
> sure).
> Not being sure
> means to experiment ... so added another visual test
> method to the
> taskPaneIssues: a plain hidden label doesn't get the
> binding, a hidden
> taskpane child does. Do we want that? Would say no,
> but could be
> convinced
Well, that's one of the reasons I used a JButton in the test case because I know that JLabels get somewhat hinky where key bindings are concerned.
At any rate, before we even get to key bindings, I was very much surprised that the pane was not initially collapsed. I mean, I call setCollapsed(true) before I pack() and setVisible(), so I would expect that, well, the pane is collapsed when I start. But it isn't.
> As to the not opening in your test - could it be that
> the ctrl-F is
> eaten somewhere else?
Nope; that's why the test case is what it is. Very simple, very straightforward.
> HTH a bit at least
Always!
Best,
Laird
|
|
|
|
|
|
|
|
|
Re: JXCollapsiblePane.CollapsiblePaneContainer question
Posted:
Apr 11, 2008 6:04 AM
in response to: ljnelson
|
|
|
Laird,
> Well, that's one of the reasons I used a JButton in the test case because I know that JLabels get somewhat hinky where key bindings are concerned.
>
>
same with button But ...
> At any rate, before we even get to key bindings, I was very much surprised that the pane was not initially collapsed. I mean, I call setCollapsed(true) before I pack() and setVisible(), so I would expect that, well, the pane is collapsed when I start. But it isn't.
>
>
I should have run your example before garbling, clearly answered a
different question from what you asked, sorry. Yeah, that's indeed weird
- no idea what's going on there.
CU
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
java.net RSS
