Re: [cdt-dev] Ccontents of wrong file displayed in CContentOutlinePage,

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

Hello Sadik,

That is a very interesting question. I don't know exactly what is going wrong here, but it is very good that you have a reproducible test case. Unfortunately I can't reproduce this with a simple/quick try. If you can file a bug report with more details and add me to the CC'list we can continue discussing on there.

In the meantime, there is one part of your analysis that needs some additional investigation if you can. Two objects can have the same hash code, it just puts them in the same bucket in the hash map. The key to getting the correct one out is the equals method, so it is there that you should look to identify the problem. In particular I would expect that eventually the parent of the two files with the same name will have a parent with different folder or project names.

I hope that helps,

Jonah

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

On Wed, 10 Apr 2019 at 08:27, Sadik <soezoguz@xxxxxxxxxxx> wrote:

Hi all,

I'm part of a team developing an eclipse plugin. In this plugin, files with
a certain extensions are opened with a CEditor. When opening two different
files with the same name, the Outline View only shows contents from the
first file. Also the highlighting gets wrong.

The following code comes from CEditor and is called from its public
getOutlinePage() method.

        private static void setOutlinePageInputIfNotSame(CContentOutlinePage
page, IEditorInput input) {
                if (page != null) {
                        IWorkingCopyManager manager =
CUIPlugin.getDefault().getWorkingCopyManager();
                        IWorkingCopy workingCopy = manager.getWorkingCopy(input);
                        if (workingCopy != page.getRoot()) {
                                page.setInput(workingCopy);
                        }
                }
        }

When switching the editor to an editor showing a file with the same file
name, the line IWorkingCopy workingCopy = manager.getWorkingCopy(input);
returns a workingCopy with the wrong resource, although "input" contains the
correct file path.

I think this is due to the implementation of hashCode in CElement, where it
takes a combination of an element's name and its parent's hash code. This
has been made clear in the documentation, where it says: By default, the
hash code for an element is a combination of its name and parent's hash
code. Elements with other requirements override this method.

The problem appears in CModelManager's getSharedWorkingCopy method

    public IWorkingCopy getSharedWorkingCopy(IBufferFactory factory,
ITranslationUnit tu, IProblemRequestor requestor,
                        IProgressMonitor monitor) throws CModelException {
                // if factory is null, default factory must be used
                if (factory == null)
                        factory = BufferManager.getDefaultBufferManager();

                Map<ITranslationUnit, WorkingCopy> perFactoryWorkingCopies =
sharedWorkingCopies.get(factory);
                if (perFactoryWorkingCopies == null) {
                        perFactoryWorkingCopies = new HashMap<>();
                        sharedWorkingCopies.put(factory, perFactoryWorkingCopies);
                }
                WorkingCopy workingCopy = perFactoryWorkingCopies.get(tu);
                if (workingCopy != null) {
                        workingCopy.useCount++;
                        return workingCopy;
                }
                CreateWorkingCopyOperation op = new CreateWorkingCopyOperation(tu,
perFactoryWorkingCopies, factory, requestor);
                op.runOperation(monitor);
                return (IWorkingCopy) op.getResultElements()[0];
        }

In the line WorkingCopy workingCopy = perFactoryWorkingCopies.get(tu);. the
wrong object is returned, because both objects have the same hash code.

Now what would be a good way to solve this for me? I'm new to CDT and it
seems to me that I need to extend a lot of classes just to change this
behaviour.






--
Sent from: http://eclipse.1072660.n5.nabble.com/Eclipse-CDT-Development-f46177.html
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev