This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 28034 - OutputWindow.selectPage() regression.
Summary: OutputWindow.selectPage() regression.
Status: RESOLVED FIXED
Alias: None
Product: qa
Classification: Unclassified
Component: Jellytools (show other bugs)
Version: 3.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Adam Sotona
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-15 23:36 UTC by Michael Ottati
Modified: 2002-10-24 08:44 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Ottati 2002-10-15 23:36:55 UTC
After doing a trunk update from a Thursday Oct 10 
distrubution to a Tuesday Oct 15 distrubution, I had a 
regression. 

When using OutputWindowOperator.selectPage(string) a test 
that used to work failed. In the case of this test, the 
output window has two sets of tabbed output in it, the 
left half for outputs such as compilation, the right half, 
with a different set of tabs with the execution view.

Tests that worked on Friday failed after todays trunk 
update. I note that If I undock the execution window and 
redock it into the left half of the output window, 
OutputWindow.selectPage() works as before.

This appears to be a regression.

This bug brings up an interesting issue as to the meaning 
of the OutputWindow.selectPage() method. Since it is 
possible for several pages to be contained in the output 
window, it would seem logical that the 
OutputWindow.selectPage() should consider them all. In 
looking into the implementation, this does not appear to 
be the case.

It looks as if selectPage will only work in one of the 
portions of the split window.

Marked as P2 because it causes a testing regression. OK to 
lower the priority if you can provide a forward compatable 
work around.
Comment 1 Jiri Skrivanek 2002-10-17 15:23:00 UTC
It doesn't seem to be a regression on jellytools side because
OutputWindowOperator and its parent NbFrameOperator were changed in
August last time.
Anyway, you are right it is inaccuracy in Jellytools. As a part of
other improvements we are proposing OutputWindow.selectPage() will
have impact only on tabbed pane docked in the center of window.
Comment 2 Adam Sotona 2002-10-23 09:17:37 UTC
fixed - used tabbed pane from center of output window only
Comment 3 Michael Ottati 2002-10-23 18:21:18 UTC
I have some questions about this, my questions are based 
solely on reading the bug, I have not looked at your 
changes yet.

1:  What does "center" mean. In my original report I 
described an Output window with two tabbed panes.

2: Would it not make more sense to consider ALL of the 
possible tabbed panes in the output window? This would 
perhaps mean traversing multiple tabbed pane containers 
but that seems to be more in line with the what one would 
expect with OutputWindow.selectPage() to mean. I would 
expect all possible pages within the window to be 
considered.

3: If for some reason I change the docking within the 
output window of the output tabs and the execution tab, 
will your fix continue to work? e. g. I put execution on 
the left and program output on the right?

Comment 4 Adam Sotona 2002-10-24 08:44:10 UTC
OutputWindow, EditorWindow and Explorer are just different instancies
of frame or internal frame with PerimeterPane inside. Any TopComponent
can be docked anywhere and thus there are lot of combinations. For
example:
new SomeOperator(outWinOpInstance.perimeterPane().east(), ...);



OutputWindowOperator contains getter for PerimeterPaneOperator now.
Accessing any component inside NORTH, SOUTH, EAST, WEST or CENTER part
is possible through this operator. This is one way, complicated but
complex.

.selectPage() method provides simplified access to most common
center-docked Terms. There are usualy no more than one component at
right and no other components at other sides. This is
backward-compatible way.

Any TopComponentOperator (TermOperator, EditorOperator ...) can be now
accessed independently on its location in current workspace. You can
use its constructor without defining ContainerOperator and
TopComponent should be make visible and ready. This is new and the
simplest way.
Example:
new TermOperator("myFile").dosomething...

ad 1: It means only components docked to the center of window.

ad 2: Common behaviour of JTabbedPaneOperator, which is used for
switching the tabs, is to traverse only through one tabbed pane. We
don't know how many tabbed panes could be there, some of them could
disappear. We expect just one at center, but there are no obstacles to
create now JTabbedPaneOperators from other parts when you expect them.

ad 3: This fix will work just for center part. If you dock your Term
elsewhere (west part, Explorer, Editor ...), you should use different
way to locate it. But once you have TermOperator instance, it is
connected to the Term forever and almost whenever :)