Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Visual Editor (VE) » Q re order of execution in construcing the design view.
Q re order of execution in construcing the design view. [message #90991] Fri, 13 May 2005 18:07 Go to next message
Eclipse UserFriend
Originally posted by: no.ddress.here

I need to better understand how VE is working to construct the design
view. Specifically, it appears that VE is evaluating statements to
create the design view in a significantly different order than presented
in my code.

Here is the source of my test routine and log traces that show the order
of evaluation/execution.

www.certiv.net/download/VETest4.java
www.certiv.net/download/DesignViewTrace.txt
www.certiv.net/download/ExecutionTrace.txt

The source references two custom components: JDecorator is a minor
JLabel extension; JFormPanel extends JPanel and overrides addImpl(...)
method in order to tweak the layout constraints of components as they
are added to the JFormPanel.

To initialize the JFormPanel to enable correct tweaking, the
setColumnSpec(...), setRowSpec(...), setSlotSpec(...), and setFormLayout
(true) statements *must* be executed before components are added to the
panel. When I use VE to initially drop components on the JFormPanel,
the code in the VETest4#getJFormPanel() method is created in the correct
ordering.

The execution trace shows the actual order of statement execution - the
executed app has the correct, tweaked appearance.

The problem becomes evident when I close and reopen the design view: the
design view representation of the JFormPanel is empty of the contained
components. The contained components are correctly shown in VE's Java
Bean view. There are no errors in the log files.

The design view trace produced when VE is loading the JFormPanel to
create the design view indicates that all components are added *before*
VE executes the various setColumnSpec, etc statements to initialize the
JFormPanel. (Also, the components are added using a method signature
(add(Component)) that is different from the actual code statement (add
(Component, Object)); I am overriding that method too, so it causes no
harm in this case - but it is unexpected.)

Is this the intended behavior? Is there something that can be done or
that I need to do to correct VE's order of evaluating statements in
constructing the design view?

Thanks,
Gerald
Re: Q re order of execution in construcing the design view. [message #91023 is a reply to message #90991] Fri, 13 May 2005 19:29 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: richkulp.us.NO_SPAM.ibm.com

You are absolutely right. Currently they are applied in the order the
properties decorations are introspected from the class, not the order
they appear in the code. We really need to fix this but the current
implementation makes this difficult and we have much on our plate.

This is the bug for it:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=48580


--
Thanks,
Rich Kulp
Re: Q re order of execution in construcing the design view. [message #91052 is a reply to message #91023] Fri, 13 May 2005 22:27 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: no.ddress.here

In article <d62vns$sth$1@news.eclipse.org>, richkulp@us.NO_SPAM.ibm.com
says...
> You are absolutely right. Currently they are applied in the order the
> properties decorations are introspected from the class, not the order
> they appear in the code. We really need to fix this but the current
> implementation makes this difficult and we have much on our plate.
>
> This is the bug for it:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=48580

OK, thanks for the pointer. Did not recoginize it in the bug list.

So, I will need to implement a design time workaround. Should not be
too difficult for JFormPanel to internally record those components added
before the JFormPanel is initialized. When finally initialized, the
JFormPanel can then go back and apply the appropriate layout constraints
to each of the components.

The question is whether then doing a revalidate() and repaint() will be
sufficient to trigger VE into fully displaying the components in the
design view subject to their newly applied constraints. Is there
something more or different I should do to get VE to fully update the
display?

Or would it be better for VE's purposes to buffer the pre-init component
adds until JFormPanel initialization is complete and then reissue the
adds?

Finally, is there anything similar to Beans.isDesignTime() that I can
use to determine if my bean is running specifically in VE?

Thanks,
Gerald
Re: Q re order of execution in construcing the design view. [message #91065 is a reply to message #91052] Fri, 13 May 2005 23:08 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: richkulp.us.NO_SPAM.ibm.com

The following is true with the next driver we put out:

At the very end after setting all of the properties we do a revalidate
ourselves. If all you do is an invalidate at the point you receive a
complete set of settings (i.e. you know you have what you need) that
should be sufficient because we will then come through and revalidate
and get a fresh image.

Actually the above may work in the older driver you have, we've always
tried to do something similiar, but before our new driver we used
asyncExec to do the final revalidate, and most of the time that worked.
But you can't control when the exec will run. With our new way we
control it such that it will not happen until the very end after all of
the settings have been applied.

--
Thanks,
Rich Kulp
Re: Q re order of execution in construcing the design view. [message #91079 is a reply to message #91065] Sat, 14 May 2005 08:41 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: no.ddress.here

In article <d63cil$9vg$1@news.eclipse.org>, richkulp@us.NO_SPAM.ibm.com
says...
> The following is true with the next driver we put out:
>
> At the very end after setting all of the properties we do a revalidate
> ourselves. If all you do is an invalidate at the point you receive a
> complete set of settings (i.e. you know you have what you need) that
> should be sufficient because we will then come through and revalidate
> and get a fresh image.
>
> Actually the above may work in the older driver you have, we've always
> tried to do something similiar, but before our new driver we used
> asyncExec to do the final revalidate, and most of the time that worked.
> But you can't control when the exec will run. With our new way we
> control it such that it will not happen until the very end after all of
> the settings have been applied.
>

Running with the VE 1.1.0 Stream Stable Build, works perfectly.

Many thanks!
Re: Q re order of execution in construcing the design view. [message #91256 is a reply to message #91052] Mon, 16 May 2005 17:58 Go to previous messageGo to next message
Joe Winchester is currently offline Joe WinchesterFriend
Messages: 496
Registered: July 2009
Senior Member
Hi Gerald,

> Finally, is there anything similar to Beans.isDesignTime() that I can
> use to determine if my bean is running specifically in VE?

The VE sets the flag to true, so if you query it you will get true which
means you can condition any design time logic.

At the moment we have no specific "isVE()" flag because we haven't had
the requirement for it yet. We could put a marker class that you'd just
try to load and see if it failed, but if we create a class to check with
an API then that'd also have to be part of the runtime so it could be
loaded and tested which seems a waste.

Best regards,

Joe
Re: Q re order of execution in construcing the design view. [message #91905 is a reply to message #91079] Sat, 21 May 2005 08:06 Go to previous message
Eclipse UserFriend
Originally posted by: no.ddress.here

In article <d64e80$2fn$1@news.eclipse.org>, no@ddress.here says...
> In article <d63cil$9vg$1@news.eclipse.org>, richkulp@us.NO_SPAM.ibm.com
> says...
> > The following is true with the next driver we put out:
> >
> > At the very end after setting all of the properties we do a revalidate
> > ourselves. If all you do is an invalidate at the point you receive a
> > complete set of settings (i.e. you know you have what you need) that
> > should be sufficient because we will then come through and revalidate
> > and get a fresh image.
> >
> > Actually the above may work in the older driver you have, we've always
> > tried to do something similiar, but before our new driver we used
> > asyncExec to do the final revalidate, and most of the time that worked.
> > But you can't control when the exec will run. With our new way we
> > control it such that it will not happen until the very end after all of
> > the settings have been applied.
> >
>
> Running with the VE 1.1.0 Stream Stable Build, works perfectly.
>
> Many thanks!
>
Eclipse 3.1M7
VE 20050519 nightly build

I am now getting an invalidate/paint sequence from VE following a
customizer close that results in my custom panels being repainted at
incorrect sizes.

JFormPanel extends JPanel and overrides the validate, etc methods to log
calls before calling the corresponding super routine in the JPanel.

Below is the log generated following from an OK click in my customizer.
(The setColumnSpec() call originates from VE to finally implement a
value change made while the customizer was live.)

Towards the end of the log, there is a doLayout() that I believe is the
call you mentioned in your ealier post. However, it is now followed by
an invalidate() before the paint(). This results in the painting of the
panel effectively at its invalidated size.

This doLayout/invalidate/paint sequence only occurs following the
OK/close of a customizer.

If I change my invalidate override from

super.invalidate()

to

super.getLayout().invalidateLayout(this);
super.getLayout().layoutContainer(this);

each JFormPanel is painted at the correct size and with the correct
contents.



net.certiv.swing.JFormPanel - getPreferredSize() [w,h]: 500:36
net.certiv.swing.JFormPanel - getMinimumSize() [w,h]: 500:36
net.certiv.swing.JFormPanel - getLayout() - type:
net.certiv.swing.FormLayoutProxy
net.certiv.swing.JFormPanel - getLayout() - super type:
net.certiv.swing.FormLayoutProxy
net.certiv.swing.FormLayoutProxy - proxy layout .hashCode() called.
net.certiv.swing.FormLayoutProxy - proxy layout .hashCode() called.
net.certiv.swing.FormLayoutProxy - proxy layout .equals() called
against: net.certiv.swing.FormLayoutProxy
net.certiv.swing.JFormPanel - setColumnSpec: 3dlu, Pref, Pref, 4dlu,
Pref, 10dlu:Grow, Pref, 4dlu, Pref, 4dlu, Pref, 10dlu:Grow, Pref,
4dlu:Grow
net.certiv.swing.JFormPanel - invalidate() called ...
net.certiv.swing.JFormPanel - invalidate() called ...
net.certiv.swing.JFormPanel - invalidate() called ...
net.certiv.swing.JFormPanel - doLayout() called ...
net.certiv.swing.JFormPanel - invalidate() called ...
net.certiv.swing.JFormPanel - paint() called ...
net.certiv.swing.JFormPanel - paint() called ...
net.certiv.swing.JFormPanel - getMaximumSize() [w,h]:
2147483647:2147483647
net.certiv.swing.JFormPanel - getMinimumSize() [w,h]: 78:10
net.certiv.swing.JFormPanel - getPreferredSize() [w,h]: 78:10
Re: Q re order of execution in construcing the design view. [message #607757 is a reply to message #90991] Fri, 13 May 2005 19:29 Go to previous message
Eclipse UserFriend
Originally posted by: richkulp.us.NO_SPAM.ibm.com

You are absolutely right. Currently they are applied in the order the
properties decorations are introspected from the class, not the order
they appear in the code. We really need to fix this but the current
implementation makes this difficult and we have much on our plate.

This is the bug for it:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=48580


--
Thanks,
Rich Kulp
Re: Q re order of execution in construcing the design view. [message #607759 is a reply to message #91023] Fri, 13 May 2005 22:27 Go to previous message
Gerald Rosenberg is currently offline Gerald RosenbergFriend
Messages: 106
Registered: July 2009
Senior Member
In article <d62vns$sth$1@news.eclipse.org>, richkulp@us.NO_SPAM.ibm.com
says...
> You are absolutely right. Currently they are applied in the order the
> properties decorations are introspected from the class, not the order
> they appear in the code. We really need to fix this but the current
> implementation makes this difficult and we have much on our plate.
>
> This is the bug for it:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=48580

OK, thanks for the pointer. Did not recoginize it in the bug list.

So, I will need to implement a design time workaround. Should not be
too difficult for JFormPanel to internally record those components added
before the JFormPanel is initialized. When finally initialized, the
JFormPanel can then go back and apply the appropriate layout constraints
to each of the components.

The question is whether then doing a revalidate() and repaint() will be
sufficient to trigger VE into fully displaying the components in the
design view subject to their newly applied constraints. Is there
something more or different I should do to get VE to fully update the
display?

Or would it be better for VE's purposes to buffer the pre-init component
adds until JFormPanel initialization is complete and then reissue the
adds?

Finally, is there anything similar to Beans.isDesignTime() that I can
use to determine if my bean is running specifically in VE?

Thanks,
Gerald
Re: Q re order of execution in construcing the design view. [message #607760 is a reply to message #91052] Fri, 13 May 2005 23:08 Go to previous message
Eclipse UserFriend
Originally posted by: richkulp.us.NO_SPAM.ibm.com

The following is true with the next driver we put out:

At the very end after setting all of the properties we do a revalidate
ourselves. If all you do is an invalidate at the point you receive a
complete set of settings (i.e. you know you have what you need) that
should be sufficient because we will then come through and revalidate
and get a fresh image.

Actually the above may work in the older driver you have, we've always
tried to do something similiar, but before our new driver we used
asyncExec to do the final revalidate, and most of the time that worked.
But you can't control when the exec will run. With our new way we
control it such that it will not happen until the very end after all of
the settings have been applied.

--
Thanks,
Rich Kulp
Re: Q re order of execution in construcing the design view. [message #607761 is a reply to message #91065] Sat, 14 May 2005 08:41 Go to previous message
Gerald Rosenberg is currently offline Gerald RosenbergFriend
Messages: 106
Registered: July 2009
Senior Member
In article <d63cil$9vg$1@news.eclipse.org>, richkulp@us.NO_SPAM.ibm.com
says...
> The following is true with the next driver we put out:
>
> At the very end after setting all of the properties we do a revalidate
> ourselves. If all you do is an invalidate at the point you receive a
> complete set of settings (i.e. you know you have what you need) that
> should be sufficient because we will then come through and revalidate
> and get a fresh image.
>
> Actually the above may work in the older driver you have, we've always
> tried to do something similiar, but before our new driver we used
> asyncExec to do the final revalidate, and most of the time that worked.
> But you can't control when the exec will run. With our new way we
> control it such that it will not happen until the very end after all of
> the settings have been applied.
>

Running with the VE 1.1.0 Stream Stable Build, works perfectly.

Many thanks!
Re: Q re order of execution in construcing the design view. [message #607773 is a reply to message #91052] Mon, 16 May 2005 17:58 Go to previous message
Joe Winchester is currently offline Joe WinchesterFriend
Messages: 496
Registered: July 2009
Senior Member
Hi Gerald,

> Finally, is there anything similar to Beans.isDesignTime() that I can
> use to determine if my bean is running specifically in VE?

The VE sets the flag to true, so if you query it you will get true which
means you can condition any design time logic.

At the moment we have no specific "isVE()" flag because we haven't had
the requirement for it yet. We could put a marker class that you'd just
try to load and see if it failed, but if we create a class to check with
an API then that'd also have to be part of the runtime so it could be
loaded and tested which seems a waste.

Best regards,

Joe
Re: Q re order of execution in construcing the design view. [message #607816 is a reply to message #91079] Sat, 21 May 2005 08:06 Go to previous message
Gerald Rosenberg is currently offline Gerald RosenbergFriend
Messages: 106
Registered: July 2009
Senior Member
In article <d64e80$2fn$1@news.eclipse.org>, no@ddress.here says...
> In article <d63cil$9vg$1@news.eclipse.org>, richkulp@us.NO_SPAM.ibm.com
> says...
> > The following is true with the next driver we put out:
> >
> > At the very end after setting all of the properties we do a revalidate
> > ourselves. If all you do is an invalidate at the point you receive a
> > complete set of settings (i.e. you know you have what you need) that
> > should be sufficient because we will then come through and revalidate
> > and get a fresh image.
> >
> > Actually the above may work in the older driver you have, we've always
> > tried to do something similiar, but before our new driver we used
> > asyncExec to do the final revalidate, and most of the time that worked.
> > But you can't control when the exec will run. With our new way we
> > control it such that it will not happen until the very end after all of
> > the settings have been applied.
> >
>
> Running with the VE 1.1.0 Stream Stable Build, works perfectly.
>
> Many thanks!
>
Eclipse 3.1M7
VE 20050519 nightly build

I am now getting an invalidate/paint sequence from VE following a
customizer close that results in my custom panels being repainted at
incorrect sizes.

JFormPanel extends JPanel and overrides the validate, etc methods to log
calls before calling the corresponding super routine in the JPanel.

Below is the log generated following from an OK click in my customizer.
(The setColumnSpec() call originates from VE to finally implement a
value change made while the customizer was live.)

Towards the end of the log, there is a doLayout() that I believe is the
call you mentioned in your ealier post. However, it is now followed by
an invalidate() before the paint(). This results in the painting of the
panel effectively at its invalidated size.

This doLayout/invalidate/paint sequence only occurs following the
OK/close of a customizer.

If I change my invalidate override from

super.invalidate()

to

super.getLayout().invalidateLayout(this);
super.getLayout().layoutContainer(this);

each JFormPanel is painted at the correct size and with the correct
contents.



net.certiv.swing.JFormPanel - getPreferredSize() [w,h]: 500:36
net.certiv.swing.JFormPanel - getMinimumSize() [w,h]: 500:36
net.certiv.swing.JFormPanel - getLayout() - type:
net.certiv.swing.FormLayoutProxy
net.certiv.swing.JFormPanel - getLayout() - super type:
net.certiv.swing.FormLayoutProxy
net.certiv.swing.FormLayoutProxy - proxy layout .hashCode() called.
net.certiv.swing.FormLayoutProxy - proxy layout .hashCode() called.
net.certiv.swing.FormLayoutProxy - proxy layout .equals() called
against: net.certiv.swing.FormLayoutProxy
net.certiv.swing.JFormPanel - setColumnSpec: 3dlu, Pref, Pref, 4dlu,
Pref, 10dlu:Grow, Pref, 4dlu, Pref, 4dlu, Pref, 10dlu:Grow, Pref,
4dlu:Grow
net.certiv.swing.JFormPanel - invalidate() called ...
net.certiv.swing.JFormPanel - invalidate() called ...
net.certiv.swing.JFormPanel - invalidate() called ...
net.certiv.swing.JFormPanel - doLayout() called ...
net.certiv.swing.JFormPanel - invalidate() called ...
net.certiv.swing.JFormPanel - paint() called ...
net.certiv.swing.JFormPanel - paint() called ...
net.certiv.swing.JFormPanel - getMaximumSize() [w,h]:
2147483647:2147483647
net.certiv.swing.JFormPanel - getMinimumSize() [w,h]: 78:10
net.certiv.swing.JFormPanel - getPreferredSize() [w,h]: 78:10
Previous Topic:Need help with a design view cache/reload problem
Next Topic:M7 / GTK / AMD64: not working
Goto Forum:
  


Current Time: Thu Mar 28 21:50:12 GMT 2024

Powered by FUDForum. Page generated in 0.03713 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top