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 93379 - clone scrolls when editing sibling
Summary: clone scrolls when editing sibling
Status: RESOLVED WONTFIX
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 5.x
Hardware: All All
: P4 blocker (vote)
Assignee: issues@editor
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-29 00:42 UTC by err
Modified: 2009-11-02 11:01 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Basics of a patch (3.36 KB, text/plain)
2007-01-31 20:00 UTC, err 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description err 2007-01-29 00:42:05 UTC 
To reproduce: clone document, now two panes A,B for same Document. Drag a pane
so that both A,B are visible. Position caret near top of document in A, and near
bottom of document in B. Add lines to A, observe that B scrolls.

I did this with .java files.
Comment 1 Miloslav Metelka 2007-01-29 12:59:17 UTC 
I was able to reproduce in trunk. The second view simply retains its visual
bounds (starting coordinates and size of the view's extent) so it does not react
to modifications in any way. If subsequent lines are added to the A then the
caret in B will eventually go outside of the view's extent.
To fix this the second view has to track document's modifications and if they
are before its starting y coordinate it must scroll down/up by the amount of
inserted/removed content.
Comment 2 err 2007-01-31 19:56:48 UTC 
I've fixed this in jVi, its a generic swing issue that has nothing to do with
NB. I am attaching a simple class that can be used anywhere to address the
problem. I use it as an inner class, so its missing imports. 

I don't know how well it fits into NB. Optimally it would only be started on a
JEditorPane that is being deactivated and that has a clone. (jVi does it for any
deactivated editor; since they won't usually get document events, there's not
really much of an impact). Having a "JTextComponent.freezeViewport()" method
seems like what's really needed (I'm assuming that is where the issue is).

Hopefully, I'll be starting an NB6.0 port of jVi relatively soon, after the 5.5
is stable. If this fix looks usable, I might be able to integrate it into NB
with some direction.

(If one is ever working with two views of the same file, I'm sure this priority
would be higher :))
Comment 3 err 2007-01-31 20:00:17 UTC 
Created attachment 37893 [details]
Basics of a patch
Comment 4 Vitezslav Stejskal 2007-02-01 07:39:02 UTC 
Thanks for the patch. We'll have a look.
Comment 5 err 2007-02-13 03:26:15 UTC 
The code I sent has a deadlock problem. If DocumentEvent analysis determines
that viewport should be adjusted, the adjustment must be done in event thread.
Comment 6 David Strupl 2009-03-31 15:47:27 UTC 
Resolving all issues with milestone "future" as LATER. If you feel strongly that
it should be implemented please reopen and set the target milestone to "next".
Comment 7 Quality Engineering 2009-11-02 11:01:34 UTC 
NetBeans.org Migration: changing resolution from LATER to WONTFIX