Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Preferences
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

Attachment: signature.asc
Description: OpenPGP digital signature

Back to the top