|
|
Re: Custom cell editor [message #129637 is a reply to message #129511] |
Mon, 07 August 2006 14:40 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
That would be difficult to do. That is because standard property
descriptors only change one property. If it changed two, then it could
not be undone. That is because the property sheet uses a standard set
command, and the standard set command would only know about the one
property setting and so could not undo the other.
With the VE you would instead need to use an ICommandPropertyDescriptor.
This allows you to create two commands and one compound command, one for
each property, that can then be returned to the property sheet. This
will allow undo to work correctly.
--
Thanks,
Rich Kulp
|
|
|
Re: Custom cell editor [message #129660 is a reply to message #129637] |
Mon, 07 August 2006 18:29 |
hung Messages: 117 Registered: July 2009 |
Senior Member |
|
|
Again, Thank you Rich for your reply.
For a single property, this is how I currently do it:
1. Add an extension "org.eclipse.jem.beaninfo.registrations" to point
to my override file.
2. In my override file, I have the following :
<objectsToAttach
cellEditorClassname=" org.eclipse.ve.swt/org.eclipse.ve.internal.swt.JVEDialogCell Editor:com.ibm.hats/com.ibm.hats.studio.jve.BlockScreenRegio nPropertyEditor "
labelProviderClassname=" com.ibm.hats/com.ibm.hats.studio.jve.BlockScreenRegionLabelP rovider "
xmi:id="_eAnnotations"
xsi:type=" org.eclipse.ve.internal.cde.decorators:BasePropertyDecorator ">
</objectsToAttach>
3. My BlockScreenRegionLabelProvider would implement the followings:
public class BlockScreenRegionPropertyEditor implements
PropertyEditor,INeedData
The rest are handled by JVE beautifully.
Would you be nice enough to show me briefly step by step what need to be
done to accomplish what I want to do. Should I have the same entry in
plugin.xml and override file, and instead of implement
PropertyDescriptor, I have to implement ICommandPropertyDescriptor
instead? Sorry, I am still pretty new to JVE. Thanks in advance.
Rich Kulp wrote:
> That would be difficult to do. That is because standard property
> descriptors only change one property. If it changed two, then it could
> not be undone. That is because the property sheet uses a standard set
> command, and the standard set command would only know about the one
> property setting and so could not undo the other.
>
> With the VE you would instead need to use an ICommandPropertyDescriptor.
> This allows you to create two commands and one compound command, one for
> each property, that can then be returned to the property sheet. This
> will allow undo to work correctly.
>
|
|
|
Re: Custom cell editor [message #129665 is a reply to message #129660] |
Mon, 07 August 2006 21:37 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Take a look at the jfc.BoundsPropertyDescriptor.
When you set bounds, you need to unset size/location (if they were set).
Otherwise there would be conflicts. So in this case we are changing more
than one value.
See jfc/Component.override to see how we specify the
BoundsPropertyDescriptor as the property descriptor for the "bounds"
property.
--
Thanks,
Rich Kulp
|
|
|
|
Re: Custom cell editor [message #129676 is a reply to message #129671] |
Tue, 08 August 2006 23:45 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Your cell editor can only update one property. That is all the property
sheet understands. What happens is that the ICommandPropertyDescriptor
will then set the other property depending on the value sent into that
came from the cell editor.
If the value of the other property cannot be determined from the setting
of the one property then you will need to do something special. Instead
of returning a single property value from the cell editor, return an
instance of a class that you will write that contains both properties.
Then in your property descriptor adapter it should check to see if the
value is an instance of your special class, and if it is, it should go
and create a compound command that sets both of the properties.
--
Thanks,
Rich Kulp
|
|
|
|
Re: Custom cell editor [message #129687 is a reply to message #129681] |
Wed, 09 August 2006 14:49 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Yeah, I think the default JVEDialogCellEditor expects to get back only
IJavaInstances and not generic objects.
--
Thanks,
Rich Kulp
|
|
|
|
|
Re: Custom cell editor [message #129710 is a reply to message #129704] |
Wed, 09 August 2006 16:06 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Yes, that is its purpose. It allows the cell editor to get the source of
the property so that you can ask for other properties or other info
about the source.
Note that unless you made the property incompatible with others, you can
actually get more than one source object if more than one child is
selected on the graph/tree viewer. The purpose of this is to allow
setting more than one child to have the same value for the property.
--
Thanks,
Rich Kulp
|
|
|
|
Re: Custom cell editor [message #613726 is a reply to message #129511] |
Mon, 07 August 2006 14:40 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
That would be difficult to do. That is because standard property
descriptors only change one property. If it changed two, then it could
not be undone. That is because the property sheet uses a standard set
command, and the standard set command would only know about the one
property setting and so could not undo the other.
With the VE you would instead need to use an ICommandPropertyDescriptor.
This allows you to create two commands and one compound command, one for
each property, that can then be returned to the property sheet. This
will allow undo to work correctly.
--
Thanks,
Rich Kulp
|
|
|
Re: Custom cell editor [message #613732 is a reply to message #129637] |
Mon, 07 August 2006 18:29 |
hung Messages: 117 Registered: July 2009 |
Senior Member |
|
|
Again, Thank you Rich for your reply.
For a single property, this is how I currently do it:
1. Add an extension "org.eclipse.jem.beaninfo.registrations" to point
to my override file.
2. In my override file, I have the following :
<objectsToAttach
cellEditorClassname=" org.eclipse.ve.swt/org.eclipse.ve.internal.swt.JVEDialogCell Editor:com.ibm.hats/com.ibm.hats.studio.jve.BlockScreenRegio nPropertyEditor "
labelProviderClassname=" com.ibm.hats/com.ibm.hats.studio.jve.BlockScreenRegionLabelP rovider "
xmi:id="_eAnnotations"
xsi:type=" org.eclipse.ve.internal.cde.decorators:BasePropertyDecorator ">
</objectsToAttach>
3. My BlockScreenRegionLabelProvider would implement the followings:
public class BlockScreenRegionPropertyEditor implements
PropertyEditor,INeedData
The rest are handled by JVE beautifully.
Would you be nice enough to show me briefly step by step what need to be
done to accomplish what I want to do. Should I have the same entry in
plugin.xml and override file, and instead of implement
PropertyDescriptor, I have to implement ICommandPropertyDescriptor
instead? Sorry, I am still pretty new to JVE. Thanks in advance.
Rich Kulp wrote:
> That would be difficult to do. That is because standard property
> descriptors only change one property. If it changed two, then it could
> not be undone. That is because the property sheet uses a standard set
> command, and the standard set command would only know about the one
> property setting and so could not undo the other.
>
> With the VE you would instead need to use an ICommandPropertyDescriptor.
> This allows you to create two commands and one compound command, one for
> each property, that can then be returned to the property sheet. This
> will allow undo to work correctly.
>
|
|
|
Re: Custom cell editor [message #613733 is a reply to message #129660] |
Mon, 07 August 2006 21:37 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Take a look at the jfc.BoundsPropertyDescriptor.
When you set bounds, you need to unset size/location (if they were set).
Otherwise there would be conflicts. So in this case we are changing more
than one value.
See jfc/Component.override to see how we specify the
BoundsPropertyDescriptor as the property descriptor for the "bounds"
property.
--
Thanks,
Rich Kulp
|
|
|
|
Re: Custom cell editor [message #613735 is a reply to message #129671] |
Tue, 08 August 2006 23:45 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Your cell editor can only update one property. That is all the property
sheet understands. What happens is that the ICommandPropertyDescriptor
will then set the other property depending on the value sent into that
came from the cell editor.
If the value of the other property cannot be determined from the setting
of the one property then you will need to do something special. Instead
of returning a single property value from the cell editor, return an
instance of a class that you will write that contains both properties.
Then in your property descriptor adapter it should check to see if the
value is an instance of your special class, and if it is, it should go
and create a compound command that sets both of the properties.
--
Thanks,
Rich Kulp
|
|
|
|
Re: Custom cell editor [message #613739 is a reply to message #129681] |
Wed, 09 August 2006 14:49 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Yeah, I think the default JVEDialogCellEditor expects to get back only
IJavaInstances and not generic objects.
--
Thanks,
Rich Kulp
|
|
|
|
|
Re: Custom cell editor [message #613743 is a reply to message #129704] |
Wed, 09 August 2006 16:06 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Yes, that is its purpose. It allows the cell editor to get the source of
the property so that you can ask for other properties or other info
about the source.
Note that unless you made the property incompatible with others, you can
actually get more than one source object if more than one child is
selected on the graph/tree viewer. The purpose of this is to allow
setting more than one child to have the same value for the property.
--
Thanks,
Rich Kulp
|
|
|
Powered by
FUDForum. Page generated in 0.02731 seconds