| reference evaluation issue in the Properties View [message #15046] |
Thu, 15 January 2004 07:31  |
Eclipse User |
|
|
|
Hi all,
We have an issue with some of the properties from the Visual Editor
Properties View.
First of all, I have a Component which has a few methods that passes
JButtons as parameters:
Example:
public void setBtnAccept(JButton pBtnAceptar) {...some code...}
public JButton getBtnAccept() {... some code...}
VE doesn't allow to manipulate this type of properties (objects instead of
Strings) from the properties sheet. Simply, it does nothing when I click in
the property cell.
By looking at the Color background property of a JButton component, it seems
that the only way to do this is by clicking on a icon that opens up a window
choser. Moreover, the code that is generated with that color picker window
is a new Color (jButton.setBackground(new java.awt.Color(130,205,255));)
The code that we would need is the following:
JButton myButton = new JButton();
setBtnAceptar(myButton);
instead of
setBtnAceptar(new javax.swing.JButton());
If I follow the window chooser possible solution for "object parameter"
types, I am able to generate setBtnAceptar(myButton), but with the following
issues:
VE says that myButton is too complicated to be evaluated. In addition, when
I select another property, the value in that property in the Properties
views disappears but if I select the propertie again the value shows it
again. If I close the form and reopen the frame I don
|
|
|
| Re: reference evaluation issue in the Properties View [message #15057 is a reply to message #15046] |
Fri, 16 January 2004 05:53  |
| Eclipse User |
|
|
|
Hi Miguel,
> VE doesn't allow to manipulate this type of properties (objects instead of
> Strings) from the properties sheet. Simply, it does nothing when I click in
> the property cell.
The property viewer uses a set of rules to determine the property editor to
use. First, if there is a BeanInfo class with a java.beans.PropertyDescriptor
for the given property then this is checked to see whether a
java.beans.PropertyEditor exists. If not, the type of the property is checked,
which in your case I presume is java.awt.Component or either
javax.swing.JButton. IF a property editor could be registered against this type
it would be used. We provide property editors for things like Color, Font,
String, numbers, image, etc... We don't have one for JButton so that's why you
just get no-op behavior.
One thing you could do in the meantime is drop the JButton somewhere else on the
GUI - it can just go onto the visual canvas on its own (i.e. not as part of any
other parent container). Then in code go and set the property value
myComponent.setBtnAccept(getJButton1());
The Visual editor should parse this and do the association for you.
We do have a property editor that lets you do this kind of association where a
property value points to another JavaBean, so it's a by reference lookup rather
than by value. This isn't part of the JavaBeans spec so you can't set it from
the BeanInfo. To see an example of it drop some java.awt.Checkbox objects, then
a java.awt.CheckboxGroup and look at the behavior of the property editor for
checkboxGroup on the checkboxes. This lets you make the association - it this
the kind of behavior you'd ideally like to know how to enable for your btnAccept
property ?
Best regards,
Joe
|
|
|
|
|
|
| Re: reference evaluation issue in the Properties View [message #15871 is a reply to message #15837] |
Tue, 20 January 2004 19:49 |
| Eclipse User |
|
|
|
Hi Miguel,
> Do you mean that we can´t implement this functionality today by changing the
> VE code, that is, can we follow the CheckboxGroup mechanism somehow?
It can be done, but it requires building a plugin and using unsupported APIs.
On the mailing list we are discussing this and other topics related to plugin
development for people wanting to extend the VEP, so rather than engage
newsgroup cycles on this I'd just rather take the discussion away to there. All
of the CVS comitters are on the mailing list and it's the place where we will be
discussing extension APIs for people building plugins. One of the first things
you might want to post there is a wish list of how you would imagine that in a
perfect world how this kind of API would be available to you
Look forward to seeing you on the mailing list
Joe Winchester
|
|
|
| Re: reference evaluation issue in the Properties View [message #578333 is a reply to message #15046] |
Fri, 16 January 2004 05:53 |
| Eclipse User |
|
|
|
Hi Miguel,
> VE doesn't allow to manipulate this type of properties (objects instead of
> Strings) from the properties sheet. Simply, it does nothing when I click in
> the property cell.
The property viewer uses a set of rules to determine the property editor to
use. First, if there is a BeanInfo class with a java.beans.PropertyDescriptor
for the given property then this is checked to see whether a
java.beans.PropertyEditor exists. If not, the type of the property is checked,
which in your case I presume is java.awt.Component or either
javax.swing.JButton. IF a property editor could be registered against this type
it would be used. We provide property editors for things like Color, Font,
String, numbers, image, etc... We don't have one for JButton so that's why you
just get no-op behavior.
One thing you could do in the meantime is drop the JButton somewhere else on the
GUI - it can just go onto the visual canvas on its own (i.e. not as part of any
other parent container). Then in code go and set the property value
myComponent.setBtnAccept(getJButton1());
The Visual editor should parse this and do the association for you.
We do have a property editor that lets you do this kind of association where a
property value points to another JavaBean, so it's a by reference lookup rather
than by value. This isn't part of the JavaBeans spec so you can't set it from
the BeanInfo. To see an example of it drop some java.awt.Checkbox objects, then
a java.awt.CheckboxGroup and look at the behavior of the property editor for
checkboxGroup on the checkboxes. This lets you make the association - it this
the kind of behavior you'd ideally like to know how to enable for your btnAccept
property ?
Best regards,
Joe
|
|
|
| Re: reference evaluation issue in the Properties View [message #578360 is a reply to message #15057] |
Fri, 16 January 2004 07:30 |
| Eclipse User |
|
|
|
Hi Joe,
I see you understood quite well my message.
Certainly, the example you gave us with the CheckboxGroup is what we are
looking for. One component (checkbox) is able to see the other ones
(CheckboxGroup) in the code and display them in a listbox.
Could you give me some guidelines of how to implement this functionality?
I guess that in order to make the myComponent.setBtnAccept(getJButton1());
work I might have to change something else.
Again, Thanks in advance,
Miguel Tato
"Joe Winchester" <winchest@uk.ibm.com> escribi
|
|
|
| Re: reference evaluation issue in the Properties View [message #578538 is a reply to message #15062] |
Tue, 20 January 2004 05:48 |
| Eclipse User |
|
|
|
Hi Miguel,
> Certainly, the example you gave us with the CheckboxGroup is what we are
> looking for. One component (checkbox) is able to see the other ones
> (CheckboxGroup) in the code and display them in a listbox.
> Could you give me some guidelines of how to implement this functionality?
> I guess that in order to make the myComponent.setBtnAccept(getJButton1());
> work I might have to change something else.
Unfortunately there is no straightforward public API to do what you want. We do
want to open up the internal API more and there is discussion bout this on the
mailing list.
Joe Winchester
|
|
|
|
| Re: reference evaluation issue in the Properties View [message #578715 is a reply to message #15837] |
Tue, 20 January 2004 19:49 |
| Eclipse User |
|
|
|
Hi Miguel,
> Do you mean that we can´t implement this functionality today by changing the
> VE code, that is, can we follow the CheckboxGroup mechanism somehow?
It can be done, but it requires building a plugin and using unsupported APIs.
On the mailing list we are discussing this and other topics related to plugin
development for people wanting to extend the VEP, so rather than engage
newsgroup cycles on this I'd just rather take the discussion away to there. All
of the CVS comitters are on the mailing list and it's the place where we will be
discussing extension APIs for people building plugins. One of the first things
you might want to post there is a wish list of how you would imagine that in a
perfect world how this kind of API would be available to you
Look forward to seeing you on the mailing list
Joe Winchester
|
|
|
Powered by
FUDForum. Page generated in 0.04595 seconds
Home