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.
API for efficient event dispatching is going to be added into debugger core. It's purpose is: 1) to simplify the access to current active elements in the IDE (like current FileObject and editor pane) and 2) to make the events dispatching more efficient - reduce the number of listeners on context switching.
Created attachment 62669 [details] The proposed API change.
Please review this API change. Separate issues will be filled for all debuggers to use this new API in order to improve performance.
V1: I wonder why getCurrentEditorCookie() is neccessary? You already have methods that return JEditorPane and even the line number. What else does EditorCookie give you? V2: Why is getMostRecentEditor() private, but getMostRecentLineNumber() public? Should not they both either be private or public? I would assume this to be symmetrical to getCurrentEditor() and getCurrentLineNumber(). V3: removePropertyChangeListener(mimeType, listener) is commented out, why? V4: Some tests could be useful I think. Also it might be useful to describe a typical usage in javadoc, eg. what does the class track, when are the events fired, who should be using this, etc.
Thanks for your review, Vita. V1: getCurrentEditorCookie() is used to find org.openide.text.Line and current Documet. I've decided to provide just the EditorCookie and not these derived objects. getCurrentLineNumber() is there just for convenience, since the line number is the most typical information that is retrieved by all debuggers. As I go through the usages, it looks like the second most wanted information is org.openide.text.Line, thus I'll consider to add "Line getCurrentLine()" method and remove the getCurrentEditorCookie(), since Document can be retrieved from getCurrentEditor(). It's not so nice, since it needs to be cast to StyledDocument and it's not apparent whether JEditorPane will always contain StyledDocument or not. But if it's so, it can be documented. V2: getMostRecentLineNumber() is used together with getMostRecentFile(), it's used by C/C++ debugger. Since we plan to use that concept in JPDA debugger as well, I've realized now that we'll need also getMostRecentEditor() to be public. I'll change it now so that it does not have to go through API review again in the future. V3: I've extended removePropertyChangeListener(listener) to remove the listener also for all MIME types, so that it works fine with WeakListeners. Therefore removePropertyChangeListener(mimeType, listener) became unnecessary, since typically you need to unregister the listener completely and not from some specific MIME type only. V4: I'll enhance the Javadoc with better description and usage. I've thought about tests; they would have to be GUI tests, since we need the events from TopComponent.Registry. I'll attach a reworked diff with "Line getCurrentLine()" method and extended Javadoc.
Created attachment 62797 [details] The improved version of EditorContextDispatcher according to comments.
I've attached the modified version of EditorContextDispatcher. It contains following public methods now: FileObject getCurrentFile() String getCurrentURLAsString() JEditorPane getCurrentEditor() int getCurrentLineNumber() Line getCurrentLine() FileObject getMostRecentFile() String getMostRecentURLAsString() JEditorPane getMostRecentEditor() int getMostRecentLineNumber() Line getMostRecentLine() void addPropertyChangeListener(PropertyChangeListener l) void addPropertyChangeListener(String MIMEType, PropertyChangeListener l) void removePropertyChangeListener(PropertyChangeListener l) Can someone please confirm whether JEditorPane.getDocument() returns always StyledDocument inside NetBeans IDE? (where JEditorPane comes from EditorCookie.getOpenedPanes(). Thus JEditorPane.getDocument() should be the same as EditorCookie.getDocument(), right?). Thanks.
> Can someone please confirm whether JEditorPane.getDocument() returns always StyledDocument inside NetBeans IDE? Strictly speaking it does not have to, but since everybody is using the same implementation of EditorCookie I think you can safely assume that this always holds true. > Thus JEditorPane.getDocument() should be the same as EditorCookie.getDocument(), right? Yes, even though EditorCookie does not enforce it in any way.
Thanks for the review.
EditorContextDispatcher integrated: changeset: 86445:6cd01160d4a9 http://hg.netbeans.org/main/rev/6cd01160d4a9
Integrated into 'main-golden', available in NB_Trunk_Production #285 build Changeset: http://hg.netbeans.org/main/rev/6cd01160d4a9 User: mentlicher@netbeans.org Log: #137005 - EditorContextDispatcher introduced for efficient handling of context change events.
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.