Home » Archived » Visual Editor (VE) » How does VE render beans at design time?
| How does VE render beans at design time? [message #96646] |
Thu, 07 July 2005 18:26  |
Eclipse User |
|
|
|
Originally posted by: eclipse.downeyfarnsworth.com
I'm working on a math graphing application (webcompmath at sourceforge) and
am trying to get it to work with VE and have encountered some puzzling
issues with how/when VE renders images.
Background: The application has a class, DisplayCanvas, that extends JPanel.
All of the graph drawing is done on a DisplayCanvas by Drawable objects
(axes, graphs, points, etc). Drawable extends Object (not one of the AWT or
Swing classes). DisplayCanvas has an add method for adding these types, and
it's paintComponent method asks all its Drawable members to draw themselves
on the panel.
I created a new Swing applet as a visual class in Eclipse and dragged a
DisplayCanvas bean to it. I found that I then can't drag a Drawable bean to
the DisplayCanvas in VE, and it appears this is because Drawables are not
Components (and I assume that VE doesn't know about the overloaded add
method in my DisplayCanvas class). I can drag a Drawable bean to the top
level and it shows up as a non-visual bean. I assume I can fix this with a
plugin, once I understand the Orme/Mendel/Winchester tutorial on extending
VE.
If I manually insert a line of code to my visual class to add( ) the
Drawable bean to the DisplayCanvas, VE now shows the Drawable as a child of
the DisplayCanvas in the JavaBean view (presumably because it parsed the add
method call). But the Drawable doesn't get rendered in the design view (but
does when I run the applet). This is not surprising.
What surprised me was when, instead of calling add( ) to add the Drawable to
the DisplayCanvas, I used a setter. For example, to add an Axes object
(which extends Drawable), I used setAxes and getAxes in DisplayCanvas. The
setAxes method just calls add( ) to add the axes object to the
DisplayCanvas. I used the property editor in VE to point this property an
Axes object that I had dropped at the top level, which generates the
appropriate setAxes call in the code. Voila! The axes get displayed on the
design view (and when I run the applet).
In both cases, the applet when run shows the same graph with axes. It seems
that when the add( ) method is "hidden" from VE (in the setter case, the
add( ) call lives in the DisplayCanvas code), VE seems to cause to be called
DisplayCanvas.paintComponent, which has had its axes property set, which
caused the axes to get added to it, and hence get displayed. When the add( )
call instead resides in the visual applet being edited by VE, then for some
reason this add( ) doesn't seem to do anything (if it did, then the Axes
would have been added to the DisplayCanvas in the design VM and would have
displayed when the DsiplayCanvas is asked to paint itself).
Before I dive into the VE code, is there a simple explanation for what's
going on?
|
|
|
| Re: How does VE render beans at design time? [message #96661 is a reply to message #96646] |
Thu, 07 July 2005 18:36  |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
The problem is the add method is overloaded. We don't know of the
add(Drawable) method. When we see add, we assume add(Component). When
you try dropping a Drawable, since it is not a Component, we won't allow
it. But when you do the add yourself, we think it is add(Component) so
we add it, but since it is not really a Component, the add(Component)
method rejects it (since we have to use reflection to find the methods
to add, and we find add(Component). Unlike the compiler which is smart
enough to see add(Drawable)).
Now when you use setAxes that is different. It is probably
setAxes(Drawable). Since it is a new property and not an overload of an
existing one from the super class, we can see it. We can see that it
takes a Drawable and we can find the setAxes(Drawable) method and
execute it. So that is why it works for setAxes. However, to us this is
just a property and not a child. The concept of a child is not part of
the BeanInfo specification so we need to supply code to understand a
child. Since there is no code in the Eclipse VE for handling
DisplayCanvas, there is no way to know that add(Drawable) is a child
setting.
--
Thanks,
Rich Kulp
|
|
|
| Re: How does VE render beans at design time? [message #96736 is a reply to message #96661] |
Thu, 07 July 2005 22:12 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.downeyfarnsworth.com
Thanks, this helps.
> The problem is the add method is overloaded. We don't know of the
> add(Drawable) method. When we see add, we assume add(Component). When you
> try dropping a Drawable, since it is not a Component, we won't allow it.
> But when you do the add yourself, we think it is add(Component) so we add
> it, but since it is not really a Component, the add(Component) method
> rejects it (since we have to use reflection to find the methods to add,
> and we find add(Component). Unlike the compiler which is smart enough to
> see add(Drawable)).
Could VE not assume add means add(Component), and instead use reflection to
find the add(Drawable) method by finding the class of the argument to add( )
and using that when introspecting (e.g., in a getMethod call)? Why the
assumption of add(Component) (other than it is probably right most of the
time)? but, since I'd really like to drop a bean into a DisplayCanvas,
instead of hand-editing the code, this is not very important.
As an experiment, I made my Drawable class extend Component, and now VE lets
me drop Axes (a Drawable) onto the DisplayCanvas. The applet runs fine and
shows the axes on the graph (I want to do more testing, but maybe having
Drawable extend Component doesn't break anything in the existing code). But,
the Axes drawable still doesn't display in the design view (if I select the
axes object in the JavaBeans view, a small black square shows up on the
design view).
Of course, now that I type this, it makes more sense. VE is still finding
the add(Component) method, not the add(Drawable) method; it's just that the
drop->add is now allowed, since the Drawable is now a Component. So VE is
inserting the add( ) method, instead of me doing it by hand. Hence, the
add(Drawable) still isn't getting called, so it's work isn't getting done.
So, that suggested the obvious experiment of overriding the add(Component)
method in DisplayCanvas, so that this overridden method calls add(Drawable)
to do the proper work. It's actually add(Component, Object) that needs to be
overridden, as I found out; the code VE adds when I drop an Axes bean is
displayCanvas.add(getAxes(), null);
The applet still runs fine and displays its axes; I used the debugger to
verify that my overriden add method is actually called. But, the VE design
view still does not show the axes. I had expected that this would work, as I
had expected VE to now find my DisplayCanvas.add(Component, Object) method
(to match the code it generates when I dropped the Axes bean). But, that
doesn't seem to be the case.
So I'm still slightly confused...
Tom
>
> Now when you use setAxes that is different. It is probably
> setAxes(Drawable). Since it is a new property and not an overload of an
> existing one from the super class, we can see it. We can see that it takes
> a Drawable and we can find the setAxes(Drawable) method and execute it. So
> that is why it works for setAxes. However, to us this is just a property
> and not a child. The concept of a child is not part of the BeanInfo
> specification so we need to supply code to understand a child. Since there
> is no code in the Eclipse VE for handling DisplayCanvas, there is no way
> to know that add(Drawable) is a child setting.
>
>
> --
> Thanks,
> Rich Kulp
|
|
|
| Re: How does VE render beans at design time? [message #96752 is a reply to message #96736] |
Thu, 07 July 2005 22:47 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
VE can only discover single value properties. There is no general way to
know about multi-value properties that are not standard BeanInfo Indexed
Properties (which we don't currently handle).
What I'm trying to say is we have special code that says
Container.add(...) means we are adding a child to the Container.
Otherwise we wouldn't know that add(...) is any different then addXYZ(),
but add(Component) means we are adding a visual and we are interested in
that while addXYZ() means something else and we have no idea what it
means, and so it should be ignored. Since there is no way to tell the
difference just by looking at it we have to hard-code that
Container.add() means add a child visual that is of interest. So if you
just happen to put an add somewhere else we would ignore it because we
don't know what it is supposed to mean.
--
Thanks,
Rich Kulp
|
|
|
| Re: How does VE render beans at design time? [message #96782 is a reply to message #96752] |
Fri, 08 July 2005 02:25 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.downeyfarnsworth.com
If I understand what you are saying, overriding Container.add() (which is
what I tried) doesn't work, because the VE code calls Container.add()
directly, and not the overriding method. So I have to decide which I like
better: being able to drop a drawable on a displayCanvas in VE and having VE
add the add() method, but not seeing drawables until I run the applet for
real, or giving up on dropping and using property setters, so I can see
things at design time. Right now I'll probably go with a mixture; a setter
works fine for the axes (which you only add one of to a graph), but I want
to be able to add multiple functions to a graph, so those I'll go with
dropping them and wait until run time to see the results. Not great, but
still, using VE to do all the rest of the GUI design (sliders, buttons, text
fields, etc) is still a huge, huge win over doing it manually.
Much thanks, and VE is great!
Tom
> What I'm trying to say is we have special code that says
> Container.add(...) means we are adding a child to the Container. Otherwise
> we wouldn't know that add(...) is any different then addXYZ(), but
> add(Component) means we are adding a visual and we are interested in that
> while addXYZ() means something else and we have no idea what it means, and
> so it should be ignored. Since there is no way to tell the difference just
> by looking at it we have to hard-code that Container.add() means add a
> child visual that is of interest. So if you just happen to put an add
> somewhere else we would ignore it because we don't know what it is
> supposed to mean.
>
>
>
> --
> Thanks,
> Rich Kulp
|
|
| | |
| Re: How does VE render beans at design time? [message #97472 is a reply to message #97064] |
Tue, 12 July 2005 20:35 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.downeyfarnsworth.com
Well, some progress. I found that if I override addImpl(Component, Object,
int), then not only can I drop a Drawable onto a DisplayCanvas, but now it
displays! My problem was that I overrode add(Component, Object), which is
what VE puts into the source code, but apparently VE actually invokes
addImpl on the target VM.
But, going further, I noticed that, while my objects now display properly,
they don't update when I set their properties. They visually update only
when I reload VE synchronization, or when I edit the property of a Swing
component.
What triggers VE to actually change the visual display when a setter is
called?
Tom
|
|
|
| Re: How does VE render beans at design time? [message #97487 is a reply to message #97472] |
Tue, 12 July 2005 21:18 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
This is done through the ComponentProxyAdapter. Whenever any property on
a component is changed, the default applySetting will call revalidate.
This causes a new image to retrieved at the end of the transaction. If
you overrode applied instead of appliedSetting, you will need to do the
revalidate yourself.
Now if the property was set on a property, and not on a Component, then
revalidate would not be called on the Component. What usually happens in
our stuff when have this condition (such as some change the x value of
the rectangle that is the bounds set into a Component) is that we
populate these up to the Component by doing the set of the bounds on the
Component after we set the x value in the bounds. This is done
automatically by the property sheet.
Note1: This is for VE 1.1 drivers (as of about a month ago). Before this
you still needed to call revalidate, but it was done in a different method.
Note2: We do not call addImpl under the covers. We call add(Component,
Object) or we call add(Component, Object, int) or we call add(Component).
tsd wrote:
> Well, some progress. I found that if I override addImpl(Component, Object,
> int), then not only can I drop a Drawable onto a DisplayCanvas, but now it
> displays! My problem was that I overrode add(Component, Object), which is
> what VE puts into the source code, but apparently VE actually invokes
> addImpl on the target VM.
>
> But, going further, I noticed that, while my objects now display properly,
> they don't update when I set their properties. They visually update only
> when I reload VE synchronization, or when I edit the property of a Swing
> component.
>
> What triggers VE to actually change the visual display when a setter is
> called?
>
> Tom
>
>
--
Thanks,
Rich Kulp
|
|
|
| Re: How does VE render beans at design time? [message #608994 is a reply to message #96646] |
Thu, 07 July 2005 18:36 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
The problem is the add method is overloaded. We don't know of the
add(Drawable) method. When we see add, we assume add(Component). When
you try dropping a Drawable, since it is not a Component, we won't allow
it. But when you do the add yourself, we think it is add(Component) so
we add it, but since it is not really a Component, the add(Component)
method rejects it (since we have to use reflection to find the methods
to add, and we find add(Component). Unlike the compiler which is smart
enough to see add(Drawable)).
Now when you use setAxes that is different. It is probably
setAxes(Drawable). Since it is a new property and not an overload of an
existing one from the super class, we can see it. We can see that it
takes a Drawable and we can find the setAxes(Drawable) method and
execute it. So that is why it works for setAxes. However, to us this is
just a property and not a child. The concept of a child is not part of
the BeanInfo specification so we need to supply code to understand a
child. Since there is no code in the Eclipse VE for handling
DisplayCanvas, there is no way to know that add(Drawable) is a child
setting.
--
Thanks,
Rich Kulp
|
|
|
| Re: How does VE render beans at design time? [message #608999 is a reply to message #96661] |
Thu, 07 July 2005 22:12 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.downeyfarnsworth.com
Thanks, this helps.
> The problem is the add method is overloaded. We don't know of the
> add(Drawable) method. When we see add, we assume add(Component). When you
> try dropping a Drawable, since it is not a Component, we won't allow it.
> But when you do the add yourself, we think it is add(Component) so we add
> it, but since it is not really a Component, the add(Component) method
> rejects it (since we have to use reflection to find the methods to add,
> and we find add(Component). Unlike the compiler which is smart enough to
> see add(Drawable)).
Could VE not assume add means add(Component), and instead use reflection to
find the add(Drawable) method by finding the class of the argument to add( )
and using that when introspecting (e.g., in a getMethod call)? Why the
assumption of add(Component) (other than it is probably right most of the
time)? but, since I'd really like to drop a bean into a DisplayCanvas,
instead of hand-editing the code, this is not very important.
As an experiment, I made my Drawable class extend Component, and now VE lets
me drop Axes (a Drawable) onto the DisplayCanvas. The applet runs fine and
shows the axes on the graph (I want to do more testing, but maybe having
Drawable extend Component doesn't break anything in the existing code). But,
the Axes drawable still doesn't display in the design view (if I select the
axes object in the JavaBeans view, a small black square shows up on the
design view).
Of course, now that I type this, it makes more sense. VE is still finding
the add(Component) method, not the add(Drawable) method; it's just that the
drop->add is now allowed, since the Drawable is now a Component. So VE is
inserting the add( ) method, instead of me doing it by hand. Hence, the
add(Drawable) still isn't getting called, so it's work isn't getting done.
So, that suggested the obvious experiment of overriding the add(Component)
method in DisplayCanvas, so that this overridden method calls add(Drawable)
to do the proper work. It's actually add(Component, Object) that needs to be
overridden, as I found out; the code VE adds when I drop an Axes bean is
displayCanvas.add(getAxes(), null);
The applet still runs fine and displays its axes; I used the debugger to
verify that my overriden add method is actually called. But, the VE design
view still does not show the axes. I had expected that this would work, as I
had expected VE to now find my DisplayCanvas.add(Component, Object) method
(to match the code it generates when I dropped the Axes bean). But, that
doesn't seem to be the case.
So I'm still slightly confused...
Tom
>
> Now when you use setAxes that is different. It is probably
> setAxes(Drawable). Since it is a new property and not an overload of an
> existing one from the super class, we can see it. We can see that it takes
> a Drawable and we can find the setAxes(Drawable) method and execute it. So
> that is why it works for setAxes. However, to us this is just a property
> and not a child. The concept of a child is not part of the BeanInfo
> specification so we need to supply code to understand a child. Since there
> is no code in the Eclipse VE for handling DisplayCanvas, there is no way
> to know that add(Drawable) is a child setting.
>
>
> --
> Thanks,
> Rich Kulp
|
|
|
| Re: How does VE render beans at design time? [message #609000 is a reply to message #96736] |
Thu, 07 July 2005 22:47 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
VE can only discover single value properties. There is no general way to
know about multi-value properties that are not standard BeanInfo Indexed
Properties (which we don't currently handle).
What I'm trying to say is we have special code that says
Container.add(...) means we are adding a child to the Container.
Otherwise we wouldn't know that add(...) is any different then addXYZ(),
but add(Component) means we are adding a visual and we are interested in
that while addXYZ() means something else and we have no idea what it
means, and so it should be ignored. Since there is no way to tell the
difference just by looking at it we have to hard-code that
Container.add() means add a child visual that is of interest. So if you
just happen to put an add somewhere else we would ignore it because we
don't know what it is supposed to mean.
--
Thanks,
Rich Kulp
|
|
|
| Re: How does VE render beans at design time? [message #609002 is a reply to message #96752] |
Fri, 08 July 2005 02:25 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.downeyfarnsworth.com
If I understand what you are saying, overriding Container.add() (which is
what I tried) doesn't work, because the VE code calls Container.add()
directly, and not the overriding method. So I have to decide which I like
better: being able to drop a drawable on a displayCanvas in VE and having VE
add the add() method, but not seeing drawables until I run the applet for
real, or giving up on dropping and using property setters, so I can see
things at design time. Right now I'll probably go with a mixture; a setter
works fine for the axes (which you only add one of to a graph), but I want
to be able to add multiple functions to a graph, so those I'll go with
dropping them and wait until run time to see the results. Not great, but
still, using VE to do all the rest of the GUI design (sliders, buttons, text
fields, etc) is still a huge, huge win over doing it manually.
Much thanks, and VE is great!
Tom
> What I'm trying to say is we have special code that says
> Container.add(...) means we are adding a child to the Container. Otherwise
> we wouldn't know that add(...) is any different then addXYZ(), but
> add(Component) means we are adding a visual and we are interested in that
> while addXYZ() means something else and we have no idea what it means, and
> so it should be ignored. Since there is no way to tell the difference just
> by looking at it we have to hard-code that Container.add() means add a
> child visual that is of interest. So if you just happen to put an add
> somewhere else we would ignore it because we don't know what it is
> supposed to mean.
>
>
>
> --
> Thanks,
> Rich Kulp
|
|
| | |
| Re: How does VE render beans at design time? [message #609043 is a reply to message #97064] |
Tue, 12 July 2005 20:35 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.downeyfarnsworth.com
Well, some progress. I found that if I override addImpl(Component, Object,
int), then not only can I drop a Drawable onto a DisplayCanvas, but now it
displays! My problem was that I overrode add(Component, Object), which is
what VE puts into the source code, but apparently VE actually invokes
addImpl on the target VM.
But, going further, I noticed that, while my objects now display properly,
they don't update when I set their properties. They visually update only
when I reload VE synchronization, or when I edit the property of a Swing
component.
What triggers VE to actually change the visual display when a setter is
called?
Tom
|
|
|
| Re: How does VE render beans at design time? [message #609044 is a reply to message #97472] |
Tue, 12 July 2005 21:18 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
This is done through the ComponentProxyAdapter. Whenever any property on
a component is changed, the default applySetting will call revalidate.
This causes a new image to retrieved at the end of the transaction. If
you overrode applied instead of appliedSetting, you will need to do the
revalidate yourself.
Now if the property was set on a property, and not on a Component, then
revalidate would not be called on the Component. What usually happens in
our stuff when have this condition (such as some change the x value of
the rectangle that is the bounds set into a Component) is that we
populate these up to the Component by doing the set of the bounds on the
Component after we set the x value in the bounds. This is done
automatically by the property sheet.
Note1: This is for VE 1.1 drivers (as of about a month ago). Before this
you still needed to call revalidate, but it was done in a different method.
Note2: We do not call addImpl under the covers. We call add(Component,
Object) or we call add(Component, Object, int) or we call add(Component).
tsd wrote:
> Well, some progress. I found that if I override addImpl(Component, Object,
> int), then not only can I drop a Drawable onto a DisplayCanvas, but now it
> displays! My problem was that I overrode add(Component, Object), which is
> what VE puts into the source code, but apparently VE actually invokes
> addImpl on the target VM.
>
> But, going further, I noticed that, while my objects now display properly,
> they don't update when I set their properties. They visually update only
> when I reload VE synchronization, or when I edit the property of a Swing
> component.
>
> What triggers VE to actually change the visual display when a setter is
> called?
>
> Tom
>
>
--
Thanks,
Rich Kulp
|
|
|
Goto Forum:
Current Time: Thu Apr 25 08:46:34 GMT 2024
Powered by FUDForum. Page generated in 0.03973 seconds |
] 
Search
Help
Register
Login
Home
