Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Any way to get an IWorkingCopy from IStorage? 
Ok, I have narrowed down the problem a bit.

I have the following code:

  IStorage ancestorStorage;
  if (ancestorState != null) {
	ancestorStorage = ancestorState.getStorage(monitor);
  // Get the working copy and connect to input.
  SourceEditorInput input = new SourceEditorInput(ancestorStorage);
  IWorkingCopyManager manager = CUIPlugin.getDefault()
					.getWorkingCopyManager();
  manager.connect(input);

  IWorkingCopy workingCopy = manager.getWorkingCopy(input);
where SourceEditorInput is a form of IStorageEditorInput (copied from DSF code for now).
What happens is that the CDocumentProvider connect() calls the TextfileDocumentProvider connect() method (via super()) which does the following: 

	public void connect(Object element) throws CoreException {
		FileInfo info= (FileInfo) fFileInfoMap.get(element);
		if (info == null) {

			info= createFileInfo(element);
			if (info == null)  {
				getParentProvider().connect(element);
				return;
			}

			info.fElement= element;
			fFileInfoMap.put(element, info);
			storeFileBufferMapping(element, info);
		}
		++ info.fCount;
	}
The createFileInfo() call returns null so it ends up calling the getParentProvider().connect() for the IStorageEditorInput we provide. This eventually finds the StorageDocumentProvider and the connect is done. We return immediately after this and do not modify the fFileInfoMap.
When we attempt to get a working copy, the CDT ends up calling CDocumentProvider getWorkingCopy(): 

        public IWorkingCopy getWorkingCopy(Object element) {
		FileInfo fileInfo = getFileInfo(element);
		if (fileInfo instanceof TranslationUnitInfo) {
			TranslationUnitInfo info =
                           (TranslationUnitInfo) fileInfo;
			return info.fCopy;
		}
		return null;
	}
which will return null if it does not find a TranslationUnitInfo from getFileInfo(). The getFileInfo() call looks at the fFileInfoMap of TextDocumentProvider which we never modified and so null is returned from getWorkingCopy().
So, the question is: do you still think it should work or should this be an RFE? 

-- Jeff J.


On 01/02/10 10:12 AM, Leherbauer, Anton (Toni) wrote:



Unfortunately, the C WorkingCopyManager passed back from
CUIPlugin uses
a CDocumentProvider and this expects an IFileEditorInput.


The CDocumentProvider can also deal with IStorageEditorInput.
If there are problems, please feel free to file a bug.

HTH,
Toni



-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff Johnston
Sent: Thursday, January 28, 2010 8:53 PM
To: CDT General developers list.
Subject: [cdt-dev] Any way to get an IWorkingCopy from IStorage?

For the Eclipse ChangeLog plug-in, we compare a local file to
one in the
repository (such as CVS or SVN) and create an entry on behalf of the
user.  For C and C++ files, we want to specify functions or
methods that
have changed within the file so the user can fill in appropriate
comments regarding the changes.  For example,

2010-01-28  Jeff Johnston<jjohnstn@xxxxxxxxxx>

	* a.c (funca):
	(funcb):

Using Team interfaces, we end-up with a 3-way diff whereby
changes are
noted as ranges within the local file and ranges within the
repository file.

The current logic of the C/C++ ChangeLog parser uses an
IFileEditorInput
created for the local modified file to get the IWorkingCopy
from which
it gets the ICElement for changed lines in the modified local file.

	public String parseCurrentFunction(IEditorInput input,
                          int offset)
			throws CoreException {

		String currentElementName;

		// Get the working copy and connect to input.		
		IWorkingCopyManager manager = CUIPlugin.getDefault()
				.getWorkingCopyManager();
		manager.connect(input);

		// Retrieve the C/C++ Element in question.
		IWorkingCopy workingCopy =
                     manager.getWorkingCopy(input);
		ICElement method =
                     workingCopy.getElementAtOffset(offset);

		manager.disconnect(input);

This works fine for additions and changes to existing
functions, but it
does not work for method or function removal because the
functions are
no longer in the local file.  We need to look at changes with
respect to
the ancestor file.

When we do the diff, we are given an IStorage representation of the
ancestor file.

I would like to use the CDT to calculate the ICElement for
change lines
within the ancestor storage (thereby I can add entries for
functions/methods that don't show up in the modified
file...hence handle
removal).

Unfortunately, the C WorkingCopyManager passed back from
CUIPlugin uses
a CDocumentProvider and this expects an IFileEditorInput.

Is there a way to wrapper the IStorage so I can connect to it via the
WorkingCopyManager or do I have to create a local file from
the storage
contents somehow?  Perhaps there is another alternative?

Thanks,

-- Jeff J.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top