[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Preferences
|
>
> Doesn't seem to be very easy.
>
8-)
> Invocation of metod getSomething of class CCompletionContribution
> connected with a particular editor. The editor in turn is connected to
> resource. Resource belongs to project. So the first possible solution is:
>
...
>
> Another opportunity is your CCompletionContribution object to become a
> workbench window IPartSite listener:
>
..
> Then in place you need IProject use last three lines of the second
> method to get it.
>
> Seem to be more complex. And also adding of new workbench pages or
> closing existing pages should be processed.
>
> This is just the first idea, maybe there can be something more simple.
>
This is all good, except that this contribution should not be necessary
bind to the editors, i.e. I may want to extract some info to do some
code analysis for say.. building dependencies.
Maybe the simplest way is to change the interface:
(a)
ICCompletionContributor.iniatialize(IProject prj);
or add
(b)
ICCompletionContriubutor.setProject(IProject prj);
(c)
? Any others ?
Now this can get even more complex when we will add the notion of Targets, for
example a project compiling for MIPS, you do not want to show X86 information.
But .. let's not worry about it.
So chris what will work for you (a), (b) or do you have a (c) in mind ?
> If you'd like to continue this topic, I think it is better to send mail
> directly to my address to avoid annoyance this mayling list readers .
>
>
> Chris Moller wrote:
>
> > I'm writing a CDT CompletionContributor plugin [public class Libhover
> > implements ICCompletionContributor {...}] that extends
> > org.eclipse.cdt.ui.CCompletionContributor. This plugin [public class
> > LibhoverPlugin extends AbstractUIPlugin {...}] has a properties page
> > [public class LibhoverPropertyPage extends PropertyPage {...}] that
> > extends org.eclipse.ui.propertyPages on objectClass
> > org.eclipse.core.resources.IProject. The properties page is supposed
> > to provide things like a search path along which the completion
> > contributor looks for certain information.
> >
> > So what I'm trying to do is set things up such that a user can, e.g.,
> > create a new project, setting up paths unique to that project -- not
> > just to the plugin -- using Project>Properties>Libhover. Then,
> > subsequently, when Libhover is triggered by the editor, I want the
> > class to retrieve the persistent info stored by the PropertyPage
> > extension in <project.whatever>/.cdtproject.
> >
> > The problem seems to be that, on the one hand, I've got the
> > AbstractUIPlugin/PropertyPage extensions that understand about
> > projects (i.e., LibhoverPropertyPage.getProject() returns non-null)
> > and on the other hand the CCompletionContributor that doesn't (every
> > tortured variation of getProject() I've tried returns null).
> >
> > So, there's my question: How do I pass information between these
> > separate classes, with, I suppose, different sets of ancestors. Can I
> > do some sort of multiple inhertiance thingy? Would that work? Or is
> > there something obvious I'm missing? I'm in a good bit over my head;
> > my familiarity with Eclipse internals is exactly co-extensive with my
> > familiarity with Java -- close to zip.
> >
> > Thanks,
> > Chris
> >
> > Alex Chapiro wrote:
> >
> >> Probably there is misunderstanding from my side. Preferences are
> >> workspace-specific, properties - resource-specific. If "whatever" is
> >> a correct object that represents existing resource, its method
> >> getProject() never returns null, does not matter from where it was
> >> called from. Opposite to properties which can be stored in resource
> >> belonged to project (such as .cdtproject) preferences should be
> >> stored in metadata (usually in the plugin storage) and can be
> >> accessed via plugin class methods such as getPluginPreferences().
> >> Sorry if I'm writing things well known for you, I'm just trying to
> >> extract your problem.
> >>
> >> Chris Moller wrote:
> >>
> >>> Thanks for the reply, but where do you get the "project" arg for
> >>> getCProjectDescription(project, false)? So far as I can figure out,
> >>> the only circumstance under which any variation of
> >>> whatever.getProject() returns anything but null is from inside the a
> >>> PropertyPage extension. There has to be a way to communicate
> >>> preferences out of the PropertyPage class, but damned if I can find it.
> >>>
> >>> Chris Moller
> >>>
> >>> Alex Chapiro wrote:
> >>>
> >>>> I use for that ICDescriptor class instance
> >>>>
> >>>> ICDescriptor descriptor =
> >>>> CCorePlugin.getDefault().getCProjectDescription(project, false);
> >>>> Element element = descriptor.getProjectData(SECTION_ID);
> >>>>
> >>>> And then move through DOM elements tree:
> >>>>
> >>>>
> >>>> for(Node child = element.getFirstChild();
> >>>> null != child;
> >>>> child = child.getNextSibling()) {
> >>>> if(!(child instanceof Element))
> >>>> continue;
> >>>> if(MyName.equals(child.getNodeName())) {
> >>>> doSomething();
> >>>> } }
> >>>>
> >>>>
> >>>>
> >>>> Chris Moller wrote:
> >>>>
> >>>>> A question for the world at large:
> >>>>>
> >>>>> In CDT, I've written a plugin that, as part of what it does, sets
> >>>>> up a PropertyPage that ultimately stores info in the per-project
> >>>>> .cdtproject file. Now, how do I retreive that info from
> >>>>> elsewhere in the plugin?
> >>>>>
> >>>>> Any hints would be appreciated.
> >>>>>
> >>>>> Chris Moller
> >>>>> Senior Hacker
> >>>>> Red Hat, Inc.
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> cdt-dev mailing list
> >>>> cdt-dev@xxxxxxxxxxx
> >>>> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> >>>
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> cdt-dev mailing list
> >> cdt-dev@xxxxxxxxxxx
> >> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
--
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!
