CommonNavigator refresh issues on changing file content type [message #330987] |
Wed, 20 August 2008 15:35  |
Eclipse User |
|
|
|
Hello.
Let me describe my situation.
I have navigatorContent extension in my plugin, which attaches to
ProjectExplorer view and triggers on IFile nodes. Provider for this
extension checks if IFile he has attached to has some specific content
type, and if it has, it then provides additional tree nodes. So it looks
like we can expand file like a folder and navigate through this additional
nodes. It IFile has unsupported content type, then nothing is done
(content provider's getElements() and getChildren() returns null).
Now where is the problem. Let's assume that my content provider supports a
content type derived from standart xml (org.eclipse.core.runtime.xml),
using descriptor on root element
(org.eclipse.core.runtime.content.XMLRootElementContentDescr iber). When I
create the file in my project, it has standart xml content type (because
it's created from a template), so my content provider returns no
additional nodes. Then I change content of my newly created file so it
changes it's content type to mine. And what I see - there is no call to my
content provider's getElements() and getChildren(), so the file has no
additional nodes again. I assumed that changing content type of a file
doesn't call it's refresh in viewer. So I created a listener, which calls
viewer.refresh() on each file which changed it's content type, but there
are still no call to my content provider's getElements() and getChildren().
How can I implement such logics in my application and make my content
provider's getElements() and getChildren() called after changing content
type of a file (or, to make thing simplier, on demand).
Thanks.
|
|
|
Re: CommonNavigator refresh issues on changing file content type [message #330991 is a reply to message #330987] |
Wed, 20 August 2008 16:24   |
Eclipse User |
|
|
|
Sounds like you are doing the right things. What version are you running?
I would try to verify this in the debugger, making sure the
viewer.refresh() is called and your content provider is not.
If your content provider is being called at other times, and you are
refreshing the correct resource, it should be called then. If that's
not happening, then it sounds like a bug.
If you file a bug on this, can you submit a small plugin that has the
test for how it's failing?
Francis
Mikhail Kadan wrote:
> Hello.
>
> Let me describe my situation.
>
> I have navigatorContent extension in my plugin, which attaches to
> ProjectExplorer view and triggers on IFile nodes. Provider for this
> extension checks if IFile he has attached to has some specific content
> type, and if it has, it then provides additional tree nodes. So it looks
> like we can expand file like a folder and navigate through this
> additional nodes. It IFile has unsupported content type, then nothing is
> done (content provider's getElements() and getChildren() returns null).
>
> Now where is the problem. Let's assume that my content provider supports
> a content type derived from standart xml (org.eclipse.core.runtime.xml),
> using descriptor on root element
> (org.eclipse.core.runtime.content.XMLRootElementContentDescr iber). When
> I create the file in my project, it has standart xml content type
> (because it's created from a template), so my content provider returns
> no additional nodes. Then I change content of my newly created file so
> it changes it's content type to mine. And what I see - there is no call
> to my content provider's getElements() and getChildren(), so the file
> has no additional nodes again. I assumed that changing content type of a
> file doesn't call it's refresh in viewer. So I created a listener, which
> calls viewer.refresh() on each file which changed it's content type, but
> there are still no call to my content provider's getElements() and
> getChildren().
>
> How can I implement such logics in my application and make my content
> provider's getElements() and getChildren() called after changing content
> type of a file (or, to make thing simplier, on demand).
>
> Thanks.
>
--
*new* Common Navigator Framework section in:
3.4RC4 Platform Plugin Developer Guide (Programmer's Guide)
http://help.eclipse.org/ganymede/topic/org.eclipse.platform. doc.isv/guide/cnf.htm
http://dev.eclipse.org/blogs/francis
http://wiki.eclipse.org/Common_Navigator_Framework
http://wiki.eclipse.org/Common_Navigator_Framework_Use_Cases
You have brains in your head.
You have feet in your shoes.
- Dr Seuss, Oh the Places You'll Go
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05946 seconds