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.
I found in CompilerDisplayer.java that line.markError is used. Please rewrite the code to use new Annotation API. Document of openide.text package is now updated and contains all info which you should need. The change should be quite easy: instead of Line l = ...; l.markError(); you should use: Annotation errorAnno = new Annotation() { public abstract String getAnnotationType() { return "your_type"; } public abstract String getShortDescription() { return "your_tooltip_text"; } } Line l = ...; errorAnno.attach(l); and to unmark error line: errroAnno.detach(); The XML file for the "your_type" must be defined. For the example of XML file you can check ant\src\org\apache\tools\ant\module\resources\error-annotation.xml
Assigning to the core owner, as the occurrence in CompilerDisplayer should be fixed in the core. Also, shouldn't the default implementation of DocumentLine.markError () and DocumentLine.unmarkError() be changed to use the annotation APIs (while keeping these methods deprecated) ? That way, everyone who uses markError and unmarkError will be using the new APIs. There is one occurrence of markError and unmarkError in the webapps support module, filed separate task: 15105.
assigning
I prefer to solve 15319 first, though not needed.
Fixed in main trunk.
Guys, using annotation api is correct, but you should keep the original behaviour: 1. only one errorline per a document is selected. 2. when somebody tries to type to the document (or into the selected line) the error selection is hidden Please fix it somehow.
David should think about this a bit more, I guess.
ad 1.) this can be easily solved in CompilerDisplayer.java. Right now ErrorCtl extends Annotation. This is not OK, because for each error, the new instance of ErrorCtl is created. I would suggest to create private inner class CompilerAnnotation which implements getAnnotationType as it is done right now, but has also setter for ShortDescription. The CompilerDisplayer than will have one (and only one) instance of this Annotation and rest is the same. Attaching this annotation to some line causes that it is removed from previous line and so we have back our NB3.2 behaviour. Ales, it will also save you your "Map coveredLines" which will be then useless. ad 2.) I'm still thinking about it.
ad 2.) In Annotation API it is job of annotation provider (e.g. compiler in this case) to handle such a annotation specific tasks like "after the editation of the document started, the annotation must be removed". So the question is if the annotation providers have enough support from OpenIDE to learn that document is going to be editted, document is going to be closed/opened, etc. If they have, the provider of compiler annotation simply listen on Document to which they attached an annotation and once they receive from Document insertUpdate or removeUpdate event, they can simply remove annotation. (but right now I'm afraid that providers cannot listen for example on DocumentOpened or DocumentClosed, right?) Optionally it might be useful to add into Annotatable property like PROP_ANNOTATABLE_CONTENT_WAS_MODIFIED which would be fired whenever the content of Annotatable was externally modified (e.g. by user in editor). What do you think?
Ales, could you please fix the first problem. I think it is more important and I will in the meantime work on some solution for the second problem. After you finish your work, please assign this issue back to me. Thanx, David
Fixed on my side.
*** Issue 15762 has been marked as a duplicate of this issue. ***
*** Issue 15774 has been marked as a duplicate of this issue. ***
A nicer solution to problem number two would be to extend annotateable or at least Line with: String getText (); and than fire PROP_TEXT instead of having artifitial property CONTENT_HAS_CHANGED... I am not sure how hard it is to implement this. If hard, it might be nice to use javax.swing.text.Segment or java.text.CharacterIterator instead of String But please notice that in JDK1.4 there is a new abstract interface implemented by String, StringBuffer, Segment, etc...
Created attachment 2677 [details] diff.txt
Yarda, that should be quite easy. I tried it and it works (see my patch in attachement please - it is first "draft" version). I adde into DocumentLine.Set DocumentListener and on any change in document the handle() is called which enumerates all instances of Line and compares them to changed region. In case of intersection, the Annotatable.PROP_TEXT is fired. Does it sounds (looks) OK? However, one thing is still not possible - if the module would want to remove annotation when document is going to be closed, there is no way to learn it. We don't need it right now, but I think it might be handy to know that. Please let me know your opinion and I would continue with the implementation (the same must be done for Line.Part). Thanx, David
getText should probably be abstract, DocumentLine.Part should implement it. DocumentLine.Set should not implement the listener interface, it is a public class, I guess. As concern the notification of deletation - we have isDeleted property and also we could state that getText returns null iff deleted/document closed. Ok?
*** Issue 15873 has been marked as a duplicate of this issue. ***
I agree with your corrections. I will commit it today. As for the "deleted/document closed" vs. "getText() == null" yes, it is possible, but it is again more hack than standard API.
Ales, I just commited the proposed change into openide.text package. Now you should be able to listen on Annotatable.PROP_TEXT property to learn that content of your ErrorAnnotation is being modified and so you can remove the ErrorAnnotation from Document. (solution for problem 2.) Because this bug is on the list of Q-build stoppers, please fix it as soon as possible, if possible today, so that we still have some time for testing. David PS: what is still remain to do is to implement the same for Line.Part. I'm starting the work on that immediatelly.
fixed in main trunk. http://www.netbeans.org/source/browse/core/src/org/netbeans/core/compiler/CompilerDisplayer.java.diff?r1=1.39&r2=1.40
Safer than (ev.getPropertyName().equals(Annotatable.PROP_TEXT) is Annotatable.PROP_TEXT.equals (ev.getPropertyName ()) the name can be null. Reopened with P5
fixed in main trunk. http://www.netbeans.org/source/browse/core/src/org/netbeans/core/compiler/CompilerDisplayer.java.diff?r1=1.41&r2=1.42
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.