Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] Possible bug in NewContainerWizardPage ?

Hi Gerald,

Yes, you are correct, but this could happen only in special cases.
It will happend for example if you try to create DLTK element with DLTK
Wizard in java project, using JDT Package Explorer.  (And same for java
elemens in DLTK project using Script Explorer).

But it could not be done because JavaProject will not be correct DLTK
element, so wizard could not be finished in any case.

So I think this is not a bug.

But, if you need to perform such logic, please add DLTK nature to
JavaProject, and it will work.

Best regards,
Andrei.
> Implementing a WizardPage that inherits from NewContainerWizardPage
> and have run into a bug (I think).
>
> In NewContainerWizardPage#getInitialScriptElement, an attempt is made
> to retrieve an adapter for the initial IStructuredSelection:
>
> protected IModelElement getInitialScriptElement(IStructuredSelection
> selection) {
>         IModelElement scriptElement = null;
>
>         // Check selection
>         if (selection != null && !selection.isEmpty()) {
>                 Object selectedElement = selection.getFirstElement();
>                 // Check for adapters
>                 if (selectedElement instanceof IAdaptable) {
>                         IAdaptable adaptable = (IAdaptable)
> selectedElement;
>                         scriptElement = (IModelElement)
> adaptable.getAdapter(IModelElement.class);
>                         ...
>
> If the selection is a PackageFragment, which is certainly reasonable,
> then that last #getAdapter will always fail, since a PackageFragment
> is not a IModelElement.  Looks like the inteface was changed from
> IJavaElement to IModelElement when copied out of the JDT. 
> IJavaElement works as expected, since PackageFragment is an IJavaElement.
>
> The result is that the scriptElement returned for a PackageFragment
> selection is wrong.
>
> Afraid I am still not familiar enough with DLTK internals to propose a
> fix.
>
> Thanks,
> Gerald
> ------------------------------------------------------------------------
>
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>   



Back to the top