Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 110237 - JTextField with EditorRegistry dependent APIs has problems
JTextField with EditorRegistry dependent APIs has problems
Status: RESOLVED WONTFIX
Product: editor
Classification: Unclassified
Component: -- Other --
6.x
All All
: P3 with 2 votes (vote)
: TBD
Assigned To: Milutin Kristofic
issues@editor
: API
: 166937 (view as bug list)
Depends on:
Blocks: 179047 166937 167427
  Show dependency treegraph
 
Reported: 2007-07-19 04:09 UTC by err
Modified: 2016-07-07 07:28 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description err 2007-07-19 04:09:05 UTC
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) {...
Comment 1 Vitezslav Stejskal 2007-07-19 10:35:22 UTC
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.
Comment 2 err 2007-07-19 18:12:34 UTC
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.
Comment 3 Vitezslav Stejskal 2007-07-20 11:01:55 UTC
> CompletionSupport.bind(JTextComponent, String mimeType)
Could be..
Comment 4 Dusan Balek 2008-11-14 14:39:25 UTC
Should be solved by DialogBinding.bindComponentToFile(...) call.
Comment 5 err 2008-11-16 23:44:32 UTC
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.
Comment 6 Miloslav Metelka 2009-06-15 09:47:19 UTC
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.
Comment 7 err 2009-06-21 18:39:18 UTC
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)
Comment 8 err 2009-06-23 15:51:46 UTC
*** Issue 166937 has been marked as a duplicate of this issue. ***
Comment 9 David Strupl 2010-11-04 14:52:06 UTC
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
Comment 10 err 2010-11-04 16:25:22 UTC
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.
Comment 11 David Strupl 2010-11-04 16:30:25 UTC
I would restrict defect to user visible defects. Wrt API: adding a new method is IMHO ENH.
Comment 12 err 2010-11-04 16:40:14 UTC
> 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?
Comment 13 David Strupl 2010-11-04 20:18:45 UTC
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 ...
Comment 14 err 2010-11-27 21:08:25 UTC
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.
Comment 15 Martin Balin 2016-07-07 07:28:22 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo