| paintComponent ignored ? [message #79444] |
Tue, 08 February 2005 05:17  |
Eclipse User |
|
|
|
Originally posted by: mik.c-l-a-s-s-x.it
Hello,
I've extended a JPanel and put some simple test code in the paintComponent:
protected void paintComponent(Graphics g)
{
super.paintComponent(g);
g.setColor(Color.red);
g.fillRect(0, 0, getWidth(), getHeight());
};
It looks like VE completely ignores the code in Design mode. A missing
feature ?
Mik
--
|
|
|
|
|
|
|
| Re: paintComponent ignored ? [message #79931 is a reply to message #79841] |
Fri, 11 February 2005 10:33  |
| Eclipse User |
|
|
|
Originally posted by: mik.c-l-a-s-s-x.it
"Joe Winchester" <winchest@uk.ibm.com> ha scritto nel messaggio
news:cufp4k$it5$1@www.eclipse.org...
> Hi Michele,
>
>> I've extended a JPanel and put some simple test code in the
>> paintComponent:
>>
>> protected void paintComponent(Graphics g)
>> {
>> super.paintComponent(g);
>> g.setColor(Color.red);
>> g.fillRect(0, 0, getWidth(), getHeight());
>> };
>>
>> It looks like VE completely ignores the code in Design mode. A missing
>> feature ?
>
> Quick question. Is this an inner class ? From your other post I assumed
> it was, but re-reading your post you don't mention whether it is or not ?
No it's not the inner-class case. Imagine you want to design your own JPanel
in VE (i.e. a JPanel with a background image).
> If it isn't an inner class and you just extended JPanel and put code
> then this won't be executed until you use the class. At design time we
> don't instantiate the bean being edited - we use the superclass instead.
Ok, that's my case.
> The reason is that the bean being edited may not be compiled, and also
> it's what you're going to be altering as you edit your Java code. While
> you edit the bean isn't necessarily compiled so what we do is instantiate
> the superclass and from analyzing the code work out what properties are
> set and what child JavaBeans there are and then create a prototype
> instance of what we think it will look like at design time. Any custom
> code (like yours) gets passed by.
Well, if you can check for the validity of the compiled class (i.e. it is
compiled without compilation errors), maybe you could use it to render a
preview at design time.
Buggy custom painting code would prevent the rendering of the preview, of
couse (imagine an infinite loop or a stack overflow). In this case you could
give a timeout to the preview rendering thread in order to check and break
the execution of bad custom code. A red X and a stacktrace could help to
find the error.
> You could extend you JPanel once more when you will see your custom code.
Yes, that's what I'm doing now, but I need to extend twice..
Cheers,
Mik
--
============================================================ ================
> ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) <
> Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it <
============================================================ ================
|
|
|
| Re: paintComponent ignored ? [message #80707 is a reply to message #79931] |
Fri, 18 February 2005 18:00 |
| Eclipse User |
|
|
|
Hi Michele,
> Well, if you can check for the validity of the compiled class (i.e. it is
> compiled without compilation errors), maybe you could use it to render a
> preview at design time.
But what if the previous compilation was stale ? As the designer of the
class you might alter the code within your paintComponent(...) method
and expect to see this reflected ? Also what if the previous class has
some components in it and some property settings. If we instantiate the
class itself this will be what the user sees. Then as you alter your
code we couldn't update the design canvas for you as we'd have to wait
for you to do a full save/compile ? By parsing the code and analyzing
what the child components and property settings are it means we can
apply the result of source changes directly to the GUI without having to
wait for a save and compile.
> Yes, that's what I'm doing now, but I need to extend twice..
Sorry about that. The only thing I can think of is that if we had
custom code that recognized certain methods like paintComponent(...) for
example and attempted to somehow execute this using reflection. This is
sort of what we do anyway for child components and property settings
where the parser looks for patterns and then models them and applies
live property settings. The problem with this however is that you can
never be complete as all we'd do is get closer to the solution you want
but never there as there'd be some other situation we wouldn't cope with
- sort of like Xeno's paradox.
Best regards,
Joe Winchester
|
|
|
| Re: paintComponent ignored ? [message #605095 is a reply to message #79444] |
Tue, 08 February 2005 11:28 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
It won't see such overrides in the class that is being edited because we
don't actually create an instance of the class being edited. That is
because since the class is changing it is not yet compiled and we can't
execute it.
We do execute superclasses though.
--
Thanks,
Rich Kulp
|
|
|
| Re: paintComponent ignored ? [message #605100 is a reply to message #79513] |
Tue, 08 February 2005 12:26 |
| Eclipse User |
|
|
|
Ok, but at least you could execute/display it when it has been correctly
compiled, at CTRL-S time.
It's an important feature, even more when creating/editing visual custom
components.
This missing feature sounds like a regression since the good old VAJ days.
Mik
--
"Rich Kulp" <richkulp@us.NO_SPAM.ibm.com> ha scritto nel messaggio
news:cuapbu$qas$1@www.eclipse.org...
> It won't see such overrides in the class that is being edited because we
> don't actually create an instance of the class being edited. That is
> because since the class is changing it is not yet compiled and we can't
> execute it.
>
> We do execute superclasses though.
>
> --
> Thanks,
> Rich Kulp
|
|
|
| Re: paintComponent ignored ? [message #605142 is a reply to message #79527] |
Wed, 09 February 2005 06:38 |
| Eclipse User |
|
|
|
Hi Michele,
> This missing feature sounds like a regression since the good old VAJ days.
I don't think VAJ did anything that would have helped here. VAJ
actually persisted your GUI as a set of serialized objects that it
re-opened on display and it also regenerated the code each time in a top
down fashion. Any custom source code you write (like an inner class)
would never make it to the GUI because it worked from the GUI down and
not from the source up. You can always make your inner class a fully
fledged class and looking at your code unless you really are going to
access non-public methods and state of your outer class I see no reason
not to do that. If you do need to access state of the outer classs just
make stuff package protected and put the two in the same package.
Best regards,
Joe Winchester
|
|
|
| Re: paintComponent ignored ? [message #605183 is a reply to message #79444] |
Thu, 10 February 2005 13:55 |
| Eclipse User |
|
|
|
Hi Michele,
> I've extended a JPanel and put some simple test code in the paintComponent:
>
> protected void paintComponent(Graphics g)
> {
> super.paintComponent(g);
> g.setColor(Color.red);
> g.fillRect(0, 0, getWidth(), getHeight());
> };
>
> It looks like VE completely ignores the code in Design mode. A missing
> feature ?
Quick question. Is this an inner class ? From your other post I
assumed it was, but re-reading your post you don't mention whether it is
or not ?
If it isn't an inner class and you just extended JPanel and put code
then this won't be executed until you use the class. At design time we
don't instantiate the bean being edited - we use the superclass instead.
The reason is that the bean being edited may not be compiled, and also
it's what you're going to be altering as you edit your Java code. While
you edit the bean isn't necessarily compiled so what we do is
instantiate the superclass and from analyzing the code work out what
properties are set and what child JavaBeans there are and then create a
prototype instance of what we think it will look like at design time.
Any custom code (like yours) gets passed by.
You could extend you JPanel once more when you will see your custom code.
Best regards,
Joe
|
|
|
| Re: paintComponent ignored ? [message #605201 is a reply to message #79841] |
Fri, 11 February 2005 10:33 |
| Eclipse User |
|
|
|
"Joe Winchester" <winchest@uk.ibm.com> ha scritto nel messaggio
news:cufp4k$it5$1@www.eclipse.org...
> Hi Michele,
>
>> I've extended a JPanel and put some simple test code in the
>> paintComponent:
>>
>> protected void paintComponent(Graphics g)
>> {
>> super.paintComponent(g);
>> g.setColor(Color.red);
>> g.fillRect(0, 0, getWidth(), getHeight());
>> };
>>
>> It looks like VE completely ignores the code in Design mode. A missing
>> feature ?
>
> Quick question. Is this an inner class ? From your other post I assumed
> it was, but re-reading your post you don't mention whether it is or not ?
No it's not the inner-class case. Imagine you want to design your own JPanel
in VE (i.e. a JPanel with a background image).
> If it isn't an inner class and you just extended JPanel and put code
> then this won't be executed until you use the class. At design time we
> don't instantiate the bean being edited - we use the superclass instead.
Ok, that's my case.
> The reason is that the bean being edited may not be compiled, and also
> it's what you're going to be altering as you edit your Java code. While
> you edit the bean isn't necessarily compiled so what we do is instantiate
> the superclass and from analyzing the code work out what properties are
> set and what child JavaBeans there are and then create a prototype
> instance of what we think it will look like at design time. Any custom
> code (like yours) gets passed by.
Well, if you can check for the validity of the compiled class (i.e. it is
compiled without compilation errors), maybe you could use it to render a
preview at design time.
Buggy custom painting code would prevent the rendering of the preview, of
couse (imagine an infinite loop or a stack overflow). In this case you could
give a timeout to the preview rendering thread in order to check and break
the execution of bad custom code. A red X and a stacktrace could help to
find the error.
> You could extend you JPanel once more when you will see your custom code.
Yes, that's what I'm doing now, but I need to extend twice..
Cheers,
Mik
--
============================================================ ================
> ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) <
> Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it <
============================================================ ================
|
|
|
| Re: paintComponent ignored ? [message #605409 is a reply to message #79931] |
Fri, 18 February 2005 18:00 |
| Eclipse User |
|
|
|
Hi Michele,
> Well, if you can check for the validity of the compiled class (i.e. it is
> compiled without compilation errors), maybe you could use it to render a
> preview at design time.
But what if the previous compilation was stale ? As the designer of the
class you might alter the code within your paintComponent(...) method
and expect to see this reflected ? Also what if the previous class has
some components in it and some property settings. If we instantiate the
class itself this will be what the user sees. Then as you alter your
code we couldn't update the design canvas for you as we'd have to wait
for you to do a full save/compile ? By parsing the code and analyzing
what the child components and property settings are it means we can
apply the result of source changes directly to the GUI without having to
wait for a save and compile.
> Yes, that's what I'm doing now, but I need to extend twice..
Sorry about that. The only thing I can think of is that if we had
custom code that recognized certain methods like paintComponent(...) for
example and attempted to somehow execute this using reflection. This is
sort of what we do anyway for child components and property settings
where the parser looks for patterns and then models them and applies
live property settings. The problem with this however is that you can
never be complete as all we'd do is get closer to the solution you want
but never there as there'd be some other situation we wouldn't cope with
- sort of like Xeno's paradox.
Best regards,
Joe Winchester
|
|
|
Powered by
FUDForum. Page generated in 0.05915 seconds
Home