Reflection Dialog formatting for Completion Dialog

[GoogleCodeExporter]

In my particular application which uses JSyntaxPane I have found myself
using the Completion Dialog to display possible methods as opposed to the
Reflection Dialog.  The reason is because in my application I know the
exact objects that exist in the current scope, and what their classes are.
 I use reflection myself to dynamically populate the combo completion
dialog with all of the methods for all of the objects in scope at the time
the dialog is displayed.  This has worked perfectly thus far thanks to your
implementation for my enhancement request for dynamic completion dialog items.

What I am requesting is an enhancement that will allow me to make the
Completion Dialog as pretty as your Reflection Dialog.  There are many ways
to accomplish this.  Maybe the Completion Dialog could accept two values
for each entry in the list, where the first is the value that would get
inserted into the code, and the second describes a way to format the entry
in the dialog.

Maybe it is possible to abstract some of the functionality of the
Reflection Dialog and allow the Completion Dialog to take advantage of it
as well?

Original issue reported on code.google.com by chad.dor...@gmail.com on 8 Apr 2009 at 12:59

[GoogleCodeExporter]

After browsing the code for the Completion Dialog and Reflection Dialog, I have 
a
more concise enhancement request.  Instead of accepting a List<String> for the
ComboCompletion items, can this be changed to List<Object>?  Along with that 
can we
allow the registration of custom List Cell Renderers on a per class basis for 
the
Completion Dialog?  This would allow me to pass in any number of different 
object
types to the Completion Dialog, and have them each displayed exactly how I want 
them
to be displayed.  In fact, I could even pass Member objects and re-use the same 
Cell
Renderers that are used in the Reflection Dialog.  Of course, if no Cell 
Renderer was
specified for a given object, the default cell renderer would be used on the 
object's
toString() value.

Original comment by chad.dor...@gmail.com on 8 Apr 2009 at 7:42

[GoogleCodeExporter]

You seem to know how to do it :-)
I'm currently busy with other projects, so will not have much time to look into 
that.
 Your idea seems pretty good.  
It might be better to use the ReflectionDialog, it has better code i think.  
But what
I think will cause you an issue is that the ReflectionDialog currently has a 
combobox
to select the Object to Reflect on. This is a silly hack as I was not able to 
easily
guess the Object type under the cursor, so I had to select it somehow.

Original comment by ayman.al...@gmail.com on 9 Apr 2009 at 6:08

[GoogleCodeExporter]

I'd love to take a stab at this.  Just to clarify, you think it would be a good 
idea
to replace the Completion Dialog with a variation of the Reflection Dialog plus 
this
enhancement?

If so, I believe it might make sense to do the following:
   - Make a new Dialog class modeled after the Reflection Dialog
   - Use this class as the replacement for the Completion Dialog
   - Make the Reflection Dialog simply be a subclass of the new Dialog class with an
added combo box

Does that sound like a good idea?

Original comment by chad.dor...@gmail.com on 9 Apr 2009 at 9:19

[GoogleCodeExporter]

yeah.  that sounds good to me.  looking forward to see a working sample :-)
Just to clarify, your code will be contributed to the project, your name will be
there as author/modifier, up to you, and it will be under the Apache license.

Original comment by ayman.al...@gmail.com on 10 Apr 2009 at 4:24

[GoogleCodeExporter]

If it ever works, yes, I will  contribute the code under those conditions :)

Original comment by chad.dor...@gmail.com on 10 Apr 2009 at 6:08