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.
This came up with the Completion API on a JTextField that came out of a JComboBox. Firstly, register CompletionProvider in layer.xml, when the JComboBox is created, do something like: jtc.getDocument().putProperty("mimeType", "text/x-vicommand"); Then when enter Ctrl-SPACE nothing happened. The Completion API depends on EditorRegistry.lastFocusedComponent(). So need to register the JTextField. There is no convenient way to do this, although everything of interest is public. (The only code I found that added something to the registry is BaseTextUI). For a workaround I used reflection: // register combo's editor with infrastructure try { Class c = ((ClassLoader)(Lookup.getDefault() .lookup(ClassLoader.class))).loadClass( "org.netbeans.modules.editor.lib2" + ".EditorApiPackageAccessor"); Method get = c.getMethod("get"); Object instance = get.invoke(null); Method register = c.getMethod("register", JTextComponent.class); register.invoke(instance, ce.getTextComponent()); } catch(ClassNotFoundException ex) {...
The obvious solution would be to make EditorRegistry.register(JTextComponent) public, but I am not sure if it's the best solution. IMO, we should have something like CompletionSupport.bind(JTextComponent) which would do all the magic needed to set up code completion for a JTextComponent. This can be called automatically for standard editors and manually by modules for nomadic text fields.
I purposefully made the summary general. Might there be other APIs that would work with JTC if... I'm inclined to agree that making EditorRegistry.register public is overkill. When you say > do all the magic needed to set up code completion would this include setting the mime type? A signature like CompletionSupport.bind(JTextComponent, String mimeType). I suppose if mimeType is null, then that's assumed already taken care of.
> CompletionSupport.bind(JTextComponent, String mimeType) Could be..
Should be solved by DialogBinding.bindComponentToFile(...) call.
I don't see how the signature static JavaSource bindComponentToFile(FileObject fileObject, int offset, int length, JTextComponent component) from http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-java-sourceui/org/netbeans/api/java/source/ui/DialogBinding.html , is applicable for this case. I couldn't find the source, tried looking online at http://hg.netbeans.org/main/file/52197f2ea247/java.source/src/org/netbeans/api/java/source/ and this has no ui directory. Could you provide some pointers/links for investigation? There is no FileObject in this use case. jVi is using the completion API hooked to a JComboBox's JTextField to pop up a list of file names which are currently open in the editor. If you want to see it in action, with jVi in NB you can do ":e#" then enter Ctrl-Space, type chars to winnow the list, RETURN to move editor focus to selected file.
Personally I would prefer to create an API inside editor.lib2 that would either create (or maybe just install-into) a JEditorPane (or possibly more generically JTextComponent in case of install-into way). Besides the requested completion on/off and other functionality this would also cover NbDocument.customEditor() functionality. We've already talked about this with Vita in the past. Regarding the passed flags better than passing extra parameters into the methods the API could contain (assuming we would use install-into JTextComponent functionality) property name constants that would be used for JTextComponent.putClientProperty() prior calling of the API's method(s). If we agree on this I would create it then.
As discussed in Issue 166937 the "install into" paradigm could work well, as long as there is a way to specify what level of support to install. (added a couple of "blocks" issues since this one seems to be the controlling issue)
*** Issue 166937 has been marked as a duplicate of this issue. ***
Huh? Can someone please specify exactly what API is required by this issue? If you reopened you most probably have a clue what is needed. Can you please suggest the new method that is required (and where)? Thanks a lot, David
Hi David, > what API is required by this issue? In comment 1, Vita suggested an API something like CompletionSupport.bind(JTextComponent) since he didn't want to expose "EditorRegistry.register(JTextComponent). In comment 2 I suggested CompletionSupport.bind(JTextComponent, String mimeType) which handles a related issue as mentioned in comment 1. I guess accepting a null mimeType would make sense, morphing it into Vita's suggestion. Either of the above two APIs remove the need for the reflection code in the description of this issue. Then, in comment 6, Mila suggests something possibly more aligned with long term architectural goals. But as noted in comment 7 care must be taken so that JTextComponent is supported. Since reflection is required to successfully use an NB feature, I don't this is an enhancement request; set it back if I am incorrect.
I would restrict defect to user visible defects. Wrt API: adding a new method is IMHO ENH.
> adding a new method is IMHO ENH. Not my call, but note that this used to work, and the original bug 166937 about these issues was marked REGRESSION. > I would restrict defect to user visible defects So plugin providers aren't considered users of the platform?
There are tens of platform users. There are tens or maybe even hundreds of thousands users of the IDE. So yes, platform users are also users but there are not that many of them ...
I just tracked down a problem in jVi with code completion for a JTextComponent that argues for Mila's "install-into" API proposal discussed in comment 6 and comment 7. CompletionProvider.getAutoQueryTypes is never getting invoked. The reason is that the JTextComponent's default key actions do not use DocumentUtilities.setTypingModification() as needed. Presumably the proposed API would use appropriate key actions.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss