| Library Example vs my version gives me DelegatingWrapperItemProvider instead of Impl objects [message #393223] |
Thu, 02 June 2005 22:17  |
 dave mobley
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
So after loading up the Library EMF FormEditor example, I created a
new set of plugins that mirror the Library code, but use my XSD to
generate objects.
So the odd thing that I am seeing is that when the ObjectDetailsPage
objects are instantiated, the input object I receive passed into the
constructor in the Library example plugins are just the impl classes
of the objects in the tree (i.e LibraryImpl, BookImpl, WriterImpl),
but those I get in my instance are of type
DelegatingWrapperItemProvider. To get at the Impl objects, I now
have to cast my input object as a DelegatingWrapperItemProvider and
then do a getValue() on it. Any ideas why this might be happening?
My code, other than passing in my versions of the same objects (i.e.
myeditor vs libraryeditor) is as similar as I can make it.
Any suggestions on why this happens or how I can track it down?
also, another odd thing is that in the library example the 'copy, cut,
paste' commands in the context menus work, but mine are grayed out
(again my code is nearly identical)
If there are suggestions to places I can look, I could post some code
that might help find the specific reason,
thanks,
Dave Mobley
|
|
|
| Re: Library Example vs my version gives me DelegatingWrapperItemProvider instead of Impl objects [message #393224 is a reply to message #393223] |
Fri, 03 June 2005 03:16  |
Steve Blass
Messages: 121
Registered: July 2009 |
Senior Member |
|
|
Dave Mobley wrote:
> So after loading up the Library EMF FormEditor example, I created a
> new set of plugins that mirror the Library code, but use my XSD to
> generate objects.
>
> So the odd thing that I am seeing is that when the ObjectDetailsPage
> objects are instantiated, the input object I receive passed into the
> constructor in the Library example plugins are just the impl classes
> of the objects in the tree (i.e LibraryImpl, BookImpl, WriterImpl),
> but those I get in my instance are of type
> DelegatingWrapperItemProvider. To get at the Impl objects, I now
> have to cast my input object as a DelegatingWrapperItemProvider and
> then do a getValue() on it. Any ideas why this might be happening?
> My code, other than passing in my versions of the same objects (i.e.
> myeditor vs libraryeditor) is as similar as I can make it.
>
> Any suggestions on why this happens or how I can track it down?
>
> also, another odd thing is that in the library example the 'copy, cut,
> paste' commands in the context menus work, but mine are grayed out
> (again my code is nearly identical)
>
> If there are suggestions to places I can look, I could post some code
> that might help find the specific reason,
>
> thanks,
>
> Dave Mobley
Yup, that'll happen.
There are some posts from the middle of October 2004 that address this.
Search for 'Eclipse Forms'. Moving the object Section classes in the
exmaple into their own files will bring on that behavior. The
FormEditor example was meant to be dirt simple and is built to work
directly with the xyzImpl objects. The DelegatingWrapperItemProvider
case seems more common in practice. When you get a
DelegatingWrapperItemProvider instead of an xyzImpl you can query the
DelegatingWrapperItemProvider for the property descriptors or use
getValue() as you mentioned instead of referring directly to object
fields.
Now that you have hit these issues... The gfe plugin on the library
FormEditor example home page
(www.conceptualprocessengineering.com/library) is a cleaner example - it
uses the DWIP approach and the menu items work. It also stands alone
rather than using hacked up EMF library example files. The downside is
you need to already have an EMF model handy to aim the editor at.
-
Steve
|
|
|
Powered by
FUDForum. Page generated in 0.01472 seconds
] 
Search
Help
Register
Login
Home
