| Changing of the initializing parameter in the property sheet [message #86461] |
Mon, 11 April 2005 06:44  |
Eclipse User |
|
|
|
Hello,
I use the allocation feature to initialize my component.
MyButton mb = new MyButton("test");
There is a string variable "argument" in the class MyButton. There is an
implementation of "getBeanDescritor" in the class "MyButtonBeanInfo".
public BeanDescriptor getBeanDescriptor() {
BeanDescriptor descriptor = new BeanDescriptor(EdmJButton.class);
descriptor.setValue("argument", "test");
return descriptor;
}
But if I change the value of an "argument" in the property sheet,
one more line will be inserted:
mb.setArgument("newvalue");
I would like that the string variable "test" changes to "newvalue" and
there will be not inserted any other line.
Is the class "MyButtonBeanInfo" not enough for that?
How do I have to change the funktion "getBeanDescriptor" to get it working
?
Can you give me a tip?
Thank you in advance
Elena
|
|
|
|
| Re: Changing of the initializing parameter in the property sheet [message #86502 is a reply to message #86474] |
Mon, 11 April 2005 08:47  |
| Eclipse User |
|
|
|
Hi Elena,
> Actually I want to have a list in the property sheet with different
> values (valu1, value2, value3) for an "argument".
Usually properties have a getter and setter. I think what you want is
to have a setter with >1 argument where you can expand the property in
the property sheet to be able to set the child arguments ?
This is something we've kicked around but not implemented, mainly cause
it's not part of the JavaBeans specification. We use child properties
in the property sheet to allow the properties of the property value to
be expanded and set further (although we don't really support this
properly because we don't handle the implicit value lookup of the
property although we should have this fixed very soon).
The property sheet also lets you see the current value of a property
which is easy for a simple getFoo() and setFoo(String), but hard if
there is a getFoo(String) and setFoo(String,Object). What would be the
value of the argument in the getter ?
One part of the JavaBeans specification we don't currently support (but
should implement) is indexed properties. These are identified as arrays
of a property in which case we were thinking of haveing the children in
the property sheet be the elements of the array with the property editor
allowing you to expand or collapse them, although this might be
confusing as the visual metaphor to add or remove an indexed property
setting might be sort of kludgey to fit on the property sheet. It might
be that an additional custom property editor dialog launched via a ...
button would be the way to go.
I know it's a hacky workaround, but for your method that takes three
arguments, e.g.
MyClass.setFoo(String arg1, Object arg2, int arg3);
what if you made three individual properties, e.g.
MyClass.setFoo(String arg1);
MyClass.setObject(Object arg2);
and if you had getters then reflection would pick them up.
I think we should support a way of setting generic method calls and we
do have the need to do this for unary methods like addSeparator() and
stuff, but at the moment I don't think we have a clean visual design for
how to do multi-arg methods which you want. Can you think of a good way
we could design this ? Please feel free to open a bugzilla feature
request and we can discuss and track this there.
Best regards,
Joe Winchester
|
|
|
|
| Re: Changing of the initializing parameter in the property sheet [message #86676 is a reply to message #86531] |
Mon, 11 April 2005 11:56 |
| Eclipse User |
|
|
|
Hi Elena,
> I want to implement two things:
>
> - the first is what you mean: adding values to the initializing string;
>
> - the second one: something like the SWT Widgets do. For example if I
> drop a button from the palette, this code will be generated:
>
> (a) button = new Button(sShell, SWT.NONE);
>
> if I change the property "style" the generated code will be changed to
>
> (b) button = new Button(sShell, SWT.PUSH);
Look at how we do this for the palette items for SWT CheckBox and
RadioButton. These are defined in the swtpalette.xml file as being
instances of EMFPrototypeToolEntry.
<cmpEntries xsi:type="palette:EMFPrototypeToolEntry"
icon16Name=" platform:/plugin/org.eclipse.ve.swt/icons/full/clcl16/checkb ox_obj.gif "
prototypeURI="platform:/plugin/org.eclipse.ve.swt/CheckBox.xmi#CheckBox_1 ">
<entryLabel xsi:type="utility:ConstantString" xmi:id="string1"
string="CheckBox"/>
</cmpEntries>
This points to the file Checkbox.xml and the instance CheckBox_1. This
is defined in the file in the SWT plugin as follows:
<swt:Button xmi:id="CheckBox_1">
<allocation
xsi:type="org.eclipse.jem.internal.instantiation:ParseTreeAllocation ">
<expression
xsi:type=" org.eclipse.jem.internal.instantiation:PTClassInstanceCreati on "
type="org.eclipse.swt.widgets.Button">
<arguments
xsi:type="org.eclipse.jem.internal.instantiation:PTName"
name="{parentComposite}"/>
<arguments
xsi:type="org.eclipse.jem.internal.instantiation:PTFieldAccess "
field="CHECK">
<receiver
xsi:type="org.eclipse.jem.internal.instantiation:PTName"
name="org.eclipse.swt.SWT"/>
</arguments>
</expression>
</allocation>
</swt:Button>
If you look at this it describes the parse tree allocation that sets up
the initial constructor for the checkbox. The formatting is kinda icked
up in this e-mail but if you look at the original files in
org.eclipse.ve.swt you should get an idea for what's going on.
>
> The Initializing string (a) I implemented with a help of allocation
> feature.
> My question is how can I implement (b). I'm trying it with BeanInfo class.
I think this will do what you want. There is still a problem where the
user could select your class from ChooseBean and want to get the default
parse tree allocation overridden and we do have an API for that but we
want want to marry the two so we will probably have something like the
default prototype to use as a value on the ClassDescriptorDecorator or
something. It depends on whether the palette entry you're adding is for
a new class that wants to have a non-default parse tree set, or just
different flavors of the same class (as occurs for the different SWT
Buton styles).
Best regards,
Joe Winchester
|
|
|
|
| Re: Changing of the initializing parameter in the property sheet [message #607100 is a reply to message #86474] |
Mon, 11 April 2005 08:47 |
| Eclipse User |
|
|
|
Hi Elena,
> Actually I want to have a list in the property sheet with different
> values (valu1, value2, value3) for an "argument".
Usually properties have a getter and setter. I think what you want is
to have a setter with >1 argument where you can expand the property in
the property sheet to be able to set the child arguments ?
This is something we've kicked around but not implemented, mainly cause
it's not part of the JavaBeans specification. We use child properties
in the property sheet to allow the properties of the property value to
be expanded and set further (although we don't really support this
properly because we don't handle the implicit value lookup of the
property although we should have this fixed very soon).
The property sheet also lets you see the current value of a property
which is easy for a simple getFoo() and setFoo(String), but hard if
there is a getFoo(String) and setFoo(String,Object). What would be the
value of the argument in the getter ?
One part of the JavaBeans specification we don't currently support (but
should implement) is indexed properties. These are identified as arrays
of a property in which case we were thinking of haveing the children in
the property sheet be the elements of the array with the property editor
allowing you to expand or collapse them, although this might be
confusing as the visual metaphor to add or remove an indexed property
setting might be sort of kludgey to fit on the property sheet. It might
be that an additional custom property editor dialog launched via a ...
button would be the way to go.
I know it's a hacky workaround, but for your method that takes three
arguments, e.g.
MyClass.setFoo(String arg1, Object arg2, int arg3);
what if you made three individual properties, e.g.
MyClass.setFoo(String arg1);
MyClass.setObject(Object arg2);
and if you had getters then reflection would pick them up.
I think we should support a way of setting generic method calls and we
do have the need to do this for unary methods like addSeparator() and
stuff, but at the moment I don't think we have a clean visual design for
how to do multi-arg methods which you want. Can you think of a good way
we could design this ? Please feel free to open a bugzilla feature
request and we can discuss and track this there.
Best regards,
Joe Winchester
|
|
|
| Re: Changing of the initializing parameter in the property sheet [message #607102 is a reply to message #86502] |
Mon, 11 April 2005 09:21 |
| Eclipse User |
|
|
|
Thank you for a detailed explanation. It was really nice of you.
I want to implement two things:
- the first is what you mean: adding values to the initializing string;
- the second one: something like the SWT Widgets do. For example if I drop
a button from the palette, this code will be generated:
(a) button = new Button(sShell, SWT.NONE);
if I change the property "style" the generated code will be changed to
(b) button = new Button(sShell, SWT.PUSH);
The Initializing string (a) I implemented with a help of allocation
feature.
My question is how can I implement (b). I'm trying it with BeanInfo class.
Thank you in advance
Elena
|
|
|
| Re: Changing of the initializing parameter in the property sheet [message #607112 is a reply to message #86531] |
Mon, 11 April 2005 11:56 |
| Eclipse User |
|
|
|
Hi Elena,
> I want to implement two things:
>
> - the first is what you mean: adding values to the initializing string;
>
> - the second one: something like the SWT Widgets do. For example if I
> drop a button from the palette, this code will be generated:
>
> (a) button = new Button(sShell, SWT.NONE);
>
> if I change the property "style" the generated code will be changed to
>
> (b) button = new Button(sShell, SWT.PUSH);
Look at how we do this for the palette items for SWT CheckBox and
RadioButton. These are defined in the swtpalette.xml file as being
instances of EMFPrototypeToolEntry.
<cmpEntries xsi:type="palette:EMFPrototypeToolEntry"
icon16Name=" platform:/plugin/org.eclipse.ve.swt/icons/full/clcl16/checkb ox_obj.gif "
prototypeURI="platform:/plugin/org.eclipse.ve.swt/CheckBox.xmi#CheckBox_1 ">
<entryLabel xsi:type="utility:ConstantString" xmi:id="string1"
string="CheckBox"/>
</cmpEntries>
This points to the file Checkbox.xml and the instance CheckBox_1. This
is defined in the file in the SWT plugin as follows:
<swt:Button xmi:id="CheckBox_1">
<allocation
xsi:type="org.eclipse.jem.internal.instantiation:ParseTreeAllocation ">
<expression
xsi:type=" org.eclipse.jem.internal.instantiation:PTClassInstanceCreati on "
type="org.eclipse.swt.widgets.Button">
<arguments
xsi:type="org.eclipse.jem.internal.instantiation:PTName"
name="{parentComposite}"/>
<arguments
xsi:type="org.eclipse.jem.internal.instantiation:PTFieldAccess "
field="CHECK">
<receiver
xsi:type="org.eclipse.jem.internal.instantiation:PTName"
name="org.eclipse.swt.SWT"/>
</arguments>
</expression>
</allocation>
</swt:Button>
If you look at this it describes the parse tree allocation that sets up
the initial constructor for the checkbox. The formatting is kinda icked
up in this e-mail but if you look at the original files in
org.eclipse.ve.swt you should get an idea for what's going on.
>
> The Initializing string (a) I implemented with a help of allocation
> feature.
> My question is how can I implement (b). I'm trying it with BeanInfo class.
I think this will do what you want. There is still a problem where the
user could select your class from ChooseBean and want to get the default
parse tree allocation overridden and we do have an API for that but we
want want to marry the two so we will probably have something like the
default prototype to use as a value on the ClassDescriptorDecorator or
something. It depends on whether the palette entry you're adding is for
a new class that wants to have a non-default parse tree set, or just
different flavors of the same class (as occurs for the different SWT
Buton styles).
Best regards,
Joe Winchester
|
|
|
Powered by
FUDForum. Page generated in 0.04331 seconds
Home