Eclipse Community Forums: Visual Editor (VE) » VE preview goes way out of the viewable screen and other strange behaviours

Help

Home

Home » Archived » Visual Editor (VE) » VE preview goes way out of the viewable screen and other strange behaviours

Show: Today's Messages :: Show Polls :: Message Navigator

VE preview goes way out of the viewable screen and other strange behaviours [message #92400]

Tue, 31 May 2005 02:46

Eclipse User

Originally posted by: devmike.netcabo.pt

Hi everyone. I'm using the latest VE integration build I20050526, along
with the correct Eclipse, GEF and EMF versions. These problems also
happen in VE 1.1M1. They don't come up in the 1.0.2.1 release.

The problem happens when I'm using a SWT grid layout with 10 to 12
columns with equal size, the preview goes waaaay out to the side of the
screen. The only way I can see the complete set of beans is if I resize
the composite containing them to a much bigger size and then do a BIG
scroll (2,3 x the width of the screen) to get to the beans. Is this
normal? In 1.0.2.1 VE kept all the widgets in the viewable area of the
screen, no scrolling was necessary.

Also, it seems that sometimes the horizontal fill alignment and the grab
excess space features don't work in certain cases. At runtime things
work as expected but sometimes the preview looks wrong. I know I'm not
being very specific but it seems kind of random to me. I usually get
something working through a lot of trial and error, whereas everything
in 1.0.2.1 seemed to make sense. Since that version lots of weird stuff
happens. Is anyone else experiencing this kind of problems?

Another problem, this one only relative to the I20050526 build. Suppose
I have a composite with two groups inside it, and these groups with a
few beans. If I have the Customize Layout window open, and click the
main composite on the Java Beans view, the composite's properties don't
apeear in the Customize Layout window. It works with every other bean,
but not with the top composite. I can only get the composite properties
to apeear in the window by clicking on the composite area in the preview
window (and sometimes this isn't easy, especially if the Composite is
using Fill Layout). Anyone else noticing this?

Sorry for the long post...

Thanks in advance,
Carlos Barrosa

Report message to a moderator

Re: VE preview goes way out of the viewable screen and other strange behaviours [message #92549 is a reply to message #92400]

Tue, 31 May 2005 16:49

Peter Walker

Messages: 124
Registered: July 2009

Senior Member

Carlos,

> The problem happens when I'm using a SWT grid layout with 10 to 12
> columns with equal size, the preview goes waaaay out to the side of the
> screen. The only way I can see the complete set of beans is if I resize
> the composite containing them to a much bigger size and then do a BIG
> scroll (2,3 x the width of the screen) to get to the beans. Is this
> normal? In 1.0.2.1 VE kept all the widgets in the viewable area of the
> screen, no scrolling was necessary.

It looks like SWT GridLayout has changed from Eclipse 3.0.1 to 3.1.
I created a Shell application with a GridLayout, numColumns=10,
makeColumnsEqualWidth=true... dropped 10 controls. I had to drag the width of
the Shell to the right to fit them in also. But when I run the app, it shows the
same behavior as the VE graph view.
I imported the same app into my VE 1.0.2.1 runtime (which is based on Eclipse
3.0.1), and both the running app and VE graph viewer will try to squeeze the
controls to the smallest size possible depending on the Shell size.. even if it
truncates each of the controls.
For Eclipse 3.1, it sizes each column based on the largest sized control...
which explains why you have to keep resizing the Shell in order to make the
controls fit.
I don't see this as VE bug since this is the same behavior is displayed in the
runtime app as in the VE graph viewer. But I did discover another but while
trying this scenario. The red grid lines don't show the proper column positions
as the Shell is resized and more controls are added. I opened a bug to track
this (https://bugs.eclipse.org/bugs/show_bug.cgi?id=97559).

> Also, it seems that sometimes the horizontal fill alignment and the grab
> excess space features don't work in certain cases. At runtime things
> work as expected but sometimes the preview looks wrong. I know I'm not
> being very specific but it seems kind of random to me.

I couldn't recreate this problem but since you ran across it there may be a bug
somewhere that I would like to fix. Could you provide a scenario that you can
continuously recreate the problem? Or provide a sample application that shows
this problem easily?

> Another problem, this one only relative to the I20050526 build. Suppose
> I have a composite with two groups inside it, and these groups with a
> few beans. If I have the Customize Layout window open, and click the
> main composite on the Java Beans view, the composite's properties don't
> apeear in the Customize Layout window. It works with every other bean,
> but not with the top composite. I can only get the composite properties
> to apeear in the window by clicking on the composite area in the preview
> window (and sometimes this isn't easy, especially if the Composite is
> using Fill Layout). Anyone else noticing this?

I couldn't recreate this problem on a FillLayout but if the layout is null and
click on the Composite in the Beans viewer, the grid properties don't show up.
I opened a bug to track this (https://bugs.eclipse.org/bugs/show_bug.cgi?id=97584)

Thanks for finding these...

Regards...
Peter Walker
VE Development

DevMike wrote:
> Hi everyone. I'm using the latest VE integration build I20050526, along
> with the correct Eclipse, GEF and EMF versions. These problems also
> happen in VE 1.1M1. They don't come up in the 1.0.2.1 release.
>
> The problem happens when I'm using a SWT grid layout with 10 to 12
> columns with equal size, the preview goes waaaay out to the side of the
> screen. The only way I can see the complete set of beans is if I resize
> the composite containing them to a much bigger size and then do a BIG
> scroll (2,3 x the width of the screen) to get to the beans. Is this
> normal? In 1.0.2.1 VE kept all the widgets in the viewable area of the
> screen, no scrolling was necessary.
>
> Also, it seems that sometimes the horizontal fill alignment and the grab
> excess space features don't work in certain cases. At runtime things
> work as expected but sometimes the preview looks wrong. I know I'm not
> being very specific but it seems kind of random to me. I usually get
> something working through a lot of trial and error, whereas everything
> in 1.0.2.1 seemed to make sense. Since that version lots of weird stuff
> happens. Is anyone else experiencing this kind of problems?
>
> Another problem, this one only relative to the I20050526 build. Suppose
> I have a composite with two groups inside it, and these groups with a
> few beans. If I have the Customize Layout window open, and click the
> main composite on the Java Beans view, the composite's properties don't
> apeear in the Customize Layout window. It works with every other bean,
> but not with the top composite. I can only get the composite properties
> to apeear in the window by clicking on the composite area in the preview
> window (and sometimes this isn't easy, especially if the Composite is
> using Fill Layout). Anyone else noticing this?
>
> Sorry for the long post...
>
> Thanks in advance,
> Carlos Barrosa

Report message to a moderator

Re: VE preview goes way out of the viewable screen and other strange behaviours [message #92727 is a reply to message #92549]

Wed, 01 June 2005 01:12

Eclipse User

Originally posted by: devmike.netcabo.pt

Hi Peter, thanks a lot for your help.

> > The problem happens when I'm using a SWT grid layout with 10 to 12
> > columns with equal size, the preview goes waaaay out to the side
of the
> > screen. The only way I can see the complete set of beans is if I
resize
> > the composite containing them to a much bigger size and then do a BIG
> > scroll (2,3 x the width of the screen) to get to the beans. Is this
> > normal? In 1.0.2.1 VE kept all the widgets in the viewable area of the
> > screen, no scrolling was necessary.
>
> It looks like SWT GridLayout has changed from Eclipse 3.0.1 to 3.1.
> I created a Shell application with a GridLayout, numColumns=10,
> makeColumnsEqualWidth=true... dropped 10 controls. I had to drag the
> width of the Shell to the right to fit them in also. But when I run the
> app, it shows the same behavior as the VE graph view.
> I imported the same app into my VE 1.0.2.1 runtime (which is based on
> Eclipse 3.0.1), and both the running app and VE graph viewer will try to
> squeeze the controls to the smallest size possible depending on the
> Shell size.. even if it truncates each of the controls.
> For Eclipse 3.1, it sizes each column based on the largest sized
> control... which explains why you have to keep resizing the Shell in
> order to make the controls fit.
> I don't see this as VE bug since this is the same behavior is displayed
> in the runtime app as in the VE graph viewer. But I did discover another
> but while trying this scenario. The red grid lines don't show the proper
> column positions as the Shell is resized and more controls are added. I
> opened a bug to track this
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=97559).

I agree that this might not be a VE fault, but I still think the
behaviour should be different for usabilty purposes. In my opinion, I
would prefer if VE (or SWT for that matter) kept all the controls inside
the Shell. The scrolling thing is not practical at all. If I'm not using
a enormous amount of controls in a row, I think they should be resized
to fit the size of the Shell until it's not possible to do so (if I
resize it to a very small size). After all, I think that's one of the
main reasons to use a layout right? To keep stuff in place in case of
resising the container. What do you think?

> > Also, it seems that sometimes the horizontal fill alignment and
the grab
> > excess space features don't work in certain cases. At runtime things
> > work as expected but sometimes the preview looks wrong. I know I'm not
> > being very specific but it seems kind of random to me.
>
> I couldn't recreate this problem but since you ran across it there may
> be a bug somewhere that I would like to fix. Could you provide a
> scenario that you can continuously recreate the problem? Or provide a
> sample application that shows this problem easily?
>

I found why this was happening but it's really strange abd I still can't
find a pattern because sometimes it works well. The reason why the
horizontal fill alignment wasn't working was because the changes I made
in the Customize Layout Window weren't being reflected in the VE
generated code. I created a composite, assigned it a grid layout,
dropped a few controls and then tried to change the horizontal fill
alignment in a button and although the Customize Layout Window had the
button checked, the corresponding code wasn't being generated by VE.
Could this be related to the other problem with refreshing Customize
Layout Window properties when clicking the beans view?

----------------------------------------------

Also, this afternon I was fooling around with simple experiments with VE
for a couple of hours and another issue came up. This happenned twice
although a couldn't find a pattern and couldn't reproduce it anymore but
it went as follows: I created a composite and added a few controls,
something like 2 buttons and a text. After messing around with the
controls a bit, I changed the button name (not the text, the actual
name) in the bean properties view and this caused the text control to
disappear. It's weird but that's what happened. It wasn't in the code,
the bean view or the graphical viewer anymore.

-----------------------------------------------

All this stuff happened while doing very simple experiments with VE.
Things like creating a composite, creating two sub-groups on it,
assigning them a grid layout (that's what I use the most) dropping 5 or
6 controls on each, changing the alignment, fill, a few renames, etc.
After a while weird stuff starts to happen.

I used 1.0.2.1 for hours and it worked just the way I expected and
everything made sense. Could I suggest to you trying to do something
similar to what I described? Just create a class, drop a few controls
and fool with them for a while. At least in my system it doesn't take to
long for strange stuff to start happening. I'm sorry I can't be more
specific...

Thanks a lot, and I hope I'm not being a pain with these long posts...

Miguel Barrosa

Report message to a moderator

Re: VE preview goes way out of the viewable screen and other strange behaviours [message #93236 is a reply to message #92727]

Thu, 09 June 2005 22:28

Peter Walker

Messages: 124
Registered: July 2009

Senior Member

Miguel,
Sorry to take so long to reply... been heads down trying to get M2 out the door.

>In my opinion, I
> would prefer if VE (or SWT for that matter) kept all the controls inside
> the Shell. The scrolling thing is not practical at all. If I'm not using
> a enormous amount of controls in a row, I think they should be resized
> to fit the size of the Shell...

I tend to agree with you but there is nothing VE can do about it since this
behavior comes directly from SWT. I would recommend opening a bug against
Eclipse 3.1 - the SWT component - and see what they say.
BTW... I tried this with a RowLayout with wrap & pack turned off... same thing
occurs.

I've recently made a lot of changes to GridLayout and null... and many fixes in
general have been made to VE for 1.1M2. Another integration build will be
available on 6/10 which is a candidate for M2. If you get a chance, please try
some of your GridLayout scenarios on this build and report any bugs you find.

Thanks...
Peter Walker

DevMike wrote:

> Hi Peter, thanks a lot for your help.
>
>
> > > The problem happens when I'm using a SWT grid layout with 10 to 12
> > > columns with equal size, the preview goes waaaay out to the side
> of the
> > > screen. The only way I can see the complete set of beans is if I
> resize
> > > the composite containing them to a much bigger size and then do a BIG
> > > scroll (2,3 x the width of the screen) to get to the beans. Is this
> > > normal? In 1.0.2.1 VE kept all the widgets in the viewable area of
> the
> > > screen, no scrolling was necessary.
> >
> > It looks like SWT GridLayout has changed from Eclipse 3.0.1 to 3.1.
> > I created a Shell application with a GridLayout, numColumns=10,
> > makeColumnsEqualWidth=true... dropped 10 controls. I had to drag the
> > width of the Shell to the right to fit them in also. But when I run the
> > app, it shows the same behavior as the VE graph view.
> > I imported the same app into my VE 1.0.2.1 runtime (which is based on
> > Eclipse 3.0.1), and both the running app and VE graph viewer will try to
> > squeeze the controls to the smallest size possible depending on the
> > Shell size.. even if it truncates each of the controls.
> > For Eclipse 3.1, it sizes each column based on the largest sized
> > control... which explains why you have to keep resizing the Shell in
> > order to make the controls fit.
> > I don't see this as VE bug since this is the same behavior is displayed
> > in the runtime app as in the VE graph viewer. But I did discover another
> > but while trying this scenario. The red grid lines don't show the proper
> > column positions as the Shell is resized and more controls are added. I
> > opened a bug to track this
> > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=97559).
>
>
> I agree that this might not be a VE fault, but I still think the
> behaviour should be different for usabilty purposes. In my opinion, I
> would prefer if VE (or SWT for that matter) kept all the controls inside
> the Shell. The scrolling thing is not practical at all. If I'm not using
> a enormous amount of controls in a row, I think they should be resized
> to fit the size of the Shell until it's not possible to do so (if I
> resize it to a very small size). After all, I think that's one of the
> main reasons to use a layout right? To keep stuff in place in case of
> resising the container. What do you think?
>
>
>
>
>
> > > Also, it seems that sometimes the horizontal fill alignment and
> the grab
> > > excess space features don't work in certain cases. At runtime things
> > > work as expected but sometimes the preview looks wrong. I know I'm
> not
> > > being very specific but it seems kind of random to me.
> >
> > I couldn't recreate this problem but since you ran across it there may
> > be a bug somewhere that I would like to fix. Could you provide a
> > scenario that you can continuously recreate the problem? Or provide a
> > sample application that shows this problem easily?
> >
>
>
> I found why this was happening but it's really strange abd I still can't
> find a pattern because sometimes it works well. The reason why the
> horizontal fill alignment wasn't working was because the changes I made
> in the Customize Layout Window weren't being reflected in the VE
> generated code. I created a composite, assigned it a grid layout,
> dropped a few controls and then tried to change the horizontal fill
> alignment in a button and although the Customize Layout Window had the
> button checked, the corresponding code wasn't being generated by VE.
> Could this be related to the other problem with refreshing Customize
> Layout Window properties when clicking the beans view?
>
> ----------------------------------------------
>
>
> Also, this afternon I was fooling around with simple experiments with VE
> for a couple of hours and another issue came up. This happenned twice
> although a couldn't find a pattern and couldn't reproduce it anymore but
> it went as follows: I created a composite and added a few controls,
> something like 2 buttons and a text. After messing around with the
> controls a bit, I changed the button name (not the text, the actual
> name) in the bean properties view and this caused the text control to
> disappear. It's weird but that's what happened. It wasn't in the code,
> the bean view or the graphical viewer anymore.
>
> -----------------------------------------------
>
>
> All this stuff happened while doing very simple experiments with VE.
> Things like creating a composite, creating two sub-groups on it,
> assigning them a grid layout (that's what I use the most) dropping 5 or
> 6 controls on each, changing the alignment, fill, a few renames, etc.
> After a while weird stuff starts to happen.
>
> I used 1.0.2.1 for hours and it worked just the way I expected and
> everything made sense. Could I suggest to you trying to do something
> similar to what I described? Just create a class, drop a few controls
> and fool with them for a while. At least in my system it doesn't take to
> long for strange stuff to start happening. I'm sorry I can't be more
> specific...
>
>
> Thanks a lot, and I hope I'm not being a pain with these long posts...
>
> Miguel Barrosa

Report message to a moderator

Re: VE preview goes way out of the viewable screen and other strange behaviours [message #93268 is a reply to message #93236]

Fri, 10 June 2005 07:00

Eclipse User

Originally posted by: devmike.netcabo.pt

This is a multi-part message in MIME format.
--------------070907080600090607080709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Peter.

I'd like to open a bug regarding the SWT behaviour we discussed, but
it's not clear to me how I should describe the problem, since I don't
really understand what changed in the SWT layouts to cause the problem.
Can you help me describe the problem so that I can fill the bug report?

As for 1.1M2 it feels much better. However I came across two issues:

1) Try opening the attached file in VE and then try to add a button or a
label before the button labeled 'Apagar'. In my system, the new bean
always appears after the last button (the one labeled 'Imprimir'), no
matter where I drop it. How does it work for you?

2) Create a new visual class (Composite), assign it a gridlayout with 3
columns, drop a button so that the grid appears. Now make the columns
equal width.
In 1.0.2.1 making the colums equal width made the 3 columns' width
expand until they completely filled the composite's width (equally
divided by three, of course).
In 1.1M2 the same action makes all the columns' width equal to the
width of the widest column of the 3 (that is, of course, the first
column which contains the button).
I don't know if this change was intentional, but I prefer the 1.0.2.1
behaviour.

If you have the time and patience I'd like to ask you a question
regarding my use of GridLayout in the attached file:

If I wanted the 'Apagar' and 'Imprimir' buttons right aligned and with
the same size, do you think it's good practice to set the main
Composite's GridLayout to, say 10 columns (more or less, depending on
the preferred button size), make the columns equal width, and drop a
invisible label to the left of the buttons spanning 8 columns to make
the buttons go to the right? Of course, both groupJop and groupPacient
would have to horizontally span 10 columns in order to get to the next row.

Thanks a lot in advance,
Miguel Barrosa

Peter Walker wrote:
> Miguel,
> Sorry to take so long to reply... been heads down trying to get M2 out
> the door.
>
> >In my opinion, I
> > would prefer if VE (or SWT for that matter) kept all the controls inside
> > the Shell. The scrolling thing is not practical at all. If I'm not using
> > a enormous amount of controls in a row, I think they should be resized
> > to fit the size of the Shell...
>
> I tend to agree with you but there is nothing VE can do about it since
> this behavior comes directly from SWT. I would recommend opening a bug
> against Eclipse 3.1 - the SWT component - and see what they say.
> BTW... I tried this with a RowLayout with wrap & pack turned off... same
> thing occurs.
>
> I've recently made a lot of changes to GridLayout and null... and many
> fixes in general have been made to VE for 1.1M2. Another integration
> build will be available on 6/10 which is a candidate for M2. If you get
> a chance, please try some of your GridLayout scenarios on this build and
> report any bugs you find.
>
> Thanks...
> Peter Walker
>
>
> DevMike wrote:
>
>> Hi Peter, thanks a lot for your help.
>>
>>
>> > > The problem happens when I'm using a SWT grid layout with 10 to 12
>> > > columns with equal size, the preview goes waaaay out to the side
>> of the
>> > > screen. The only way I can see the complete set of beans is if I
>> resize
>> > > the composite containing them to a much bigger size and then do
>> a BIG
>> > > scroll (2,3 x the width of the screen) to get to the beans. Is this
>> > > normal? In 1.0.2.1 VE kept all the widgets in the viewable area
>> of the
>> > > screen, no scrolling was necessary.
>> >
>> > It looks like SWT GridLayout has changed from Eclipse 3.0.1 to 3.1.
>> > I created a Shell application with a GridLayout, numColumns=10,
>> > makeColumnsEqualWidth=true... dropped 10 controls. I had to drag the
>> > width of the Shell to the right to fit them in also. But when I run
>> the
>> > app, it shows the same behavior as the VE graph view.
>> > I imported the same app into my VE 1.0.2.1 runtime (which is based on
>> > Eclipse 3.0.1), and both the running app and VE graph viewer will
>> try to
>> > squeeze the controls to the smallest size possible depending on the
>> > Shell size.. even if it truncates each of the controls.
>> > For Eclipse 3.1, it sizes each column based on the largest sized
>> > control... which explains why you have to keep resizing the Shell in
>> > order to make the controls fit.
>> > I don't see this as VE bug since this is the same behavior is
>> displayed
>> > in the runtime app as in the VE graph viewer. But I did discover
>> another
>> > but while trying this scenario. The red grid lines don't show the
>> proper
>> > column positions as the Shell is resized and more controls are
>> added. I
>> > opened a bug to track this
>> > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=97559).
>>
>>
>> I agree that this might not be a VE fault, but I still think the
>> behaviour should be different for usabilty purposes. In my opinion, I
>> would prefer if VE (or SWT for that matter) kept all the controls
>> inside the Shell. The scrolling thing is not practical at all. If I'm
>> not using a enormous amount of controls in a row, I think they should
>> be resized to fit the size of the Shell until it's not possible to do
>> so (if I resize it to a very small size). After all, I think that's
>> one of the main reasons to use a layout right? To keep stuff in place
>> in case of resising the container. What do you think?
>>
>>
>>
>>
>>
>> > > Also, it seems that sometimes the horizontal fill alignment and
>> the grab
>> > > excess space features don't work in certain cases. At runtime
>> things
>> > > work as expected but sometimes the preview looks wrong. I know
>> I'm not
>> > > being very specific but it seems kind of random to me.
>> >
>> > I couldn't recreate this problem but since you ran across it there may
>> > be a bug somewhere that I would like to fix. Could you provide a
>> > scenario that you can continuously recreate the problem? Or provide a
>> > sample application that shows this problem easily?
>> >
>>
>>
>> I found why this was happening but it's really strange abd I still
>> can't find a pattern because sometimes it works well. The reason why
>> the horizontal fill alignment wasn't working was because the changes I
>> made in the Customize Layout Window weren't being reflected in the VE
>> generated code. I created a composite, assigned it a grid layout,
>> dropped a few controls and then tried to change the horizontal fill
>> alignment in a button and although the Customize Layout Window had the
>> button checked, the corresponding code wasn't being generated by VE.
>> Could this be related to the other problem with refreshing Customize
>> Layout Window properties when clicking the beans view?
>>
>> ----------------------------------------------
>>
>>
>> Also, this afternon I was fooling around with simple experiments with
>> VE for a couple of hours and another issue came up. This happenned
>> twice although a couldn't find a pattern and couldn't reproduce it
>> anymore but it went as follows: I created a composite and added a few
>> controls, something like 2 buttons and a text. After messing around
>> with the controls a bit, I changed the button name (not the text, the
>> actual name) in the bean properties view and this caused the text
>> control to disappear. It's weird but that's what happened. It wasn't
>> in the code, the bean view or the graphical viewer anymore.
>>
>> -----------------------------------------------
>>
>>
>> All this stuff happened while doing very simple experiments with VE.
>> Things like creating a composite, creating two sub-groups on it,
>> assigning them a grid layout (that's what I use the most) dropping 5
>> or 6 controls on each, changing the alignment, fill, a few renames,
>> etc. After a while weird stuff starts to happen.
>>
>> I used 1.0.2.1 for hours and it worked just the way I expected and
>> everything made sense. Could I suggest to you trying to do something
>> similar to what I described? Just create a class, drop a few controls
>> and fool with them for a while. At least in my system it doesn't take
>> to long for strange stuff to start happening. I'm sorry I can't be
>> more specific...
>>
>>
>> Thanks a lot, and I hope I'm not being a pain with these long posts...
>>
>> Miguel Barrosa

--------------070907080600090607080709
Content-Type: text/plain;
name="VisCmpMainDataJob.java"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="VisCmpMainDataJob.java"

package org.primos.gprot;

import org.eclipse.jface.dialogs.MessageDialog;
import org.eclipse.swt.SWT;
import org.eclipse.swt.graphics.Point;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Control;
import org.eclipse.swt.widgets.Group;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Text;

public class VisCmpMainDataJob extends Composite
{
// My vars
private Composite parent;

private Button buttonPrint = null;
private Group groupPacient = null;
private Label label11 = null;
private Text textName = null;
private Label label12 = null;
private Text textSex = null;
private Label label13 = null;
private Text textBirthdate = null;
private Label label14 = null;
private Text textFace = null;
private Label label5 = null;
private Text textAge = null;
private Label label7 = null;
private Text textAddress = null;
private Label label8 = null;
private Text textBi = null;
private Label label9 = null;
private Text textContrib = null;
private Group groupJob = null;
private Label label10 = null;
private Text textDescription = null;
private Label label15 = null;
private Text textDoc = null;
private Label label16 = null;
private Text textLab = null;
private Label label2 = null;
private Text textJobName = null;
private Button buttonDelete = null;
private Label label = null;
private Text textPhone1 = null;
private Label label1 = null;
private Text textPhone2 = null;
private Label label3 = null;
private Text textCellPhone1 = null;
private Label label4 = null;
private Text textCellPhone2 = null;
private Label label17 = null;
private Text textPostalCode = null;
private Button buttonEditPacient = null;
private Label label18 = null;
private Text textGroup = null;
private Label label19 = null;
private Button buttonEditJob = null;

public VisCmpMainDataJob(Composite parent, int style)
{
super(parent, style);
this.parent = parent;
initialize();
populateFields();
}
// End VisCmpMainDataJob

void populateFields()
{
Job t = Common.jobMng.getActiveJob();

if(t == null) // Ainda n

Report message to a moderator

Re: VE preview goes way out of the viewable screen and other strange behaviours [message #93515 is a reply to message #93268]

Fri, 10 June 2005 20:10

Peter Walker

Messages: 124
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------070701050704030606070205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Miguel,
> I'd like to open a bug regarding the SWT behavior we discussed, but
> it's not clear to me how I should describe the problem, since I don't
> really understand what changed in the SWT layouts to cause the problem.
> Can you help me describe the problem so that I can fill the bug report?

I opened a bug report --> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99441
You may want to add yourself to the CC: list show you can follow the responses.

> 1) Try opening the attached file in VE and then try to add a button or a
> label before the button labeled 'Apagar'. In my system, the new bean
> always appears after the last button (the one labeled 'Imprimir'), no
> matter where I drop it. How does it work for you?

I tried this and it worked fine for me. I selected a button from the palette,
dragged the mouse to just before the button 'Apagar', a solid black line appears
before it, and released the mouse. The button was placed before the button
'Apagar'. Are you using the Graph view or Beans view to drop the button? In the
graph viewer you always get a double thick black line on a GridLayout (I
increased the width of the insertion line because it was sometimes hard to see).

> 2) Create a new visual class (Composite), assign it a gridlayout with 3
> columns, drop a button so that the grid appears. Now make the columns
> equal width.
> In 1.0.2.1 making the columns equal width made the 3 columns' width
> expand until they completely filled the composite's width (equally
> divided by three, of course).
> In 1.1M2 the same action makes all the columns' width equal to the
> width of the widest column of the 3 (that is, of course, the first
> column which contains the button).
> I don't know if this change was intentional, but I prefer the 1.0.2.1
> behavior.

Again... this is the current behavior you are now experiencing with Eclipse SWT
3.1 GridLayout and VE doesn't have control over this. All we can do is provide
lines and helpers where ever the columns and rows show. We can't re-layout the
composite... even if we did, it wouldn't show right at runtime. The bug I opened
against Eclipse SWT is to address this problem.

> If I wanted the 'Apagar' and 'Imprimir' buttons right aligned and with
> the same size, do you think it's good practice to set the main
> Composite's GridLayout to, say 10 columns (more or less, depending on
> the preferred button size), make the columns equal width, and drop a
> invisible label to the left of the buttons spanning 8 columns to make
> the buttons go to the right? Of course, both groupJop and groupPacient
> would have to horizontally span 10 columns in order to get to the next row.

This would work fine... I've seen it as a common practice to "fill" columns in a
grid layout with empty labels. If fact, we are looking a making some
enhancements to the VE gridlayout such that when you insert a control at the end
or beginning of a row, in order to keep controls from reflowing, increase the
numColumns by one and add empty labels into other rows so as to preserve the
original positions of the neighboring controls. What do you think about this idea?
Another option for you is to insert a Composite with the two buttons on it and
have the Composite (with the buttons) span across all the columns (8 or 10). Of
course the Composite layout would also be a GridLayout with two columns.
Then play with the Customize Layout window for each of the buttons to get them
over to the far right side of the Composite. Attached is just one example of
what can be done.

Thanks for input!

Regards...

Peter Walker
VE Development

DevMike wrote:

> Hi Peter.
>
> I'd like to open a bug regarding the SWT behaviour we discussed, but
> it's not clear to me how I should describe the problem, since I don't
> really understand what changed in the SWT layouts to cause the problem.
> Can you help me describe the problem so that I can fill the bug report?
>
>
> As for 1.1M2 it feels much better. However I came across two issues:
>
> 1) Try opening the attached file in VE and then try to add a button or a
> label before the button labeled 'Apagar'. In my system, the new bean
> always appears after the last button (the one labeled 'Imprimir'), no
> matter where I drop it. How does it work for you?
>
> 2) Create a new visual class (Composite), assign it a gridlayout with 3
> columns, drop a button so that the grid appears. Now make the columns
> equal width.
> In 1.0.2.1 making the colums equal width made the 3 columns' width
> expand until they completely filled the composite's width (equally
> divided by three, of course).
> In 1.1M2 the same action makes all the columns' width equal to the
> width of the widest column of the 3 (that is, of course, the first
> column which contains the button).
> I don't know if this change was intentional, but I prefer the 1.0.2.1
> behaviour.
>
>
> If you have the time and patience I'd like to ask you a question
> regarding my use of GridLayout in the attached file:
>
> If I wanted the 'Apagar' and 'Imprimir' buttons right aligned and with
> the same size, do you think it's good practice to set the main
> Composite's GridLayout to, say 10 columns (more or less, depending on
> the preferred button size), make the columns equal width, and drop a
> invisible label to the left of the buttons spanning 8 columns to make
> the buttons go to the right? Of course, both groupJop and groupPacient
> would have to horizontally span 10 columns in order to get to the next row.
>
> Thanks a lot in advance,
> Miguel Barrosa
>
>
>
> Peter Walker wrote:
>
>> Miguel,
>> Sorry to take so long to reply... been heads down trying to get M2 out
>> the door.
>>
>> >In my opinion, I
>> > would prefer if VE (or SWT for that matter) kept all the controls
>> inside
>> > the Shell. The scrolling thing is not practical at all. If I'm not
>> using
>> > a enormous amount of controls in a row, I think they should be resized
>> > to fit the size of the Shell...
>>
>> I tend to agree with you but there is nothing VE can do about it since
>> this behavior comes directly from SWT. I would recommend opening a bug
>> against Eclipse 3.1 - the SWT component - and see what they say.
>> BTW... I tried this with a RowLayout with wrap & pack turned off...
>> same thing occurs.
>>
>> I've recently made a lot of changes to GridLayout and null... and many
>> fixes in general have been made to VE for 1.1M2. Another integration
>> build will be available on 6/10 which is a candidate for M2. If you
>> get a chance, please try some of your GridLayout scenarios on this
>> build and report any bugs you find.
>>
>> Thanks...
>> Peter Walker
>>
>>
>> DevMike wrote:
>>
>>> Hi Peter, thanks a lot for your help.
>>>
>>>
>>> > > The problem happens when I'm using a SWT grid layout with 10 to 12
>>> > > columns with equal size, the preview goes waaaay out to the
>>> side of the
>>> > > screen. The only way I can see the complete set of beans is if
>>> I resize
>>> > > the composite containing them to a much bigger size and then do
>>> a BIG
>>> > > scroll (2,3 x the width of the screen) to get to the beans. Is
>>> this
>>> > > normal? In 1.0.2.1 VE kept all the widgets in the viewable area
>>> of the
>>> > > screen, no scrolling was necessary.
>>> >
>>> > It looks like SWT GridLayout has changed from Eclipse 3.0.1 to 3.1.
>>> > I created a Shell application with a GridLayout, numColumns=10,
>>> > makeColumnsEqualWidth=true... dropped 10 controls. I had to drag the
>>> > width of the Shell to the right to fit them in also. But when I
>>> run the
>>> > app, it shows the same behavior as the VE graph view.
>>> > I imported the same app into my VE 1.0.2.1 runtime (which is based on
>>> > Eclipse 3.0.1), and both the running app and VE graph viewer will
>>> try to
>>> > squeeze the controls to the smallest size possible depending on the
>>> > Shell size.. even if it truncates each of the controls.
>>> > For Eclipse 3.1, it sizes each column based on the largest sized
>>> > control... which explains why you have to keep resizing the Shell in
>>> > order to make the controls fit.
>>> > I don't see this as VE bug since this is the same behavior is
>>> displayed
>>> > in the runtime app as in the VE graph viewer. But I did discover
>>> another
>>> > but while trying this scenario. The red grid lines don't show the
>>> proper
>>> > column positions as the Shell is resized and more controls are
>>> added. I
>>> > opened a bug to track this
>>> > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=97559).
>>>
>>>
>>> I agree that this might not be a VE fault, but I still think the
>>> behaviour should be different for usabilty purposes. In my opinion, I
>>> would prefer if VE (or SWT for that matter) kept all the controls
>>> inside the Shell. The scrolling thing is not practical at all. If I'm
>>> not using a enormous amount of controls in a row, I think they should
>>> be resized to fit the size of the Shell until it's not possible to do
>>> so (if I resize it to a very small size). After all, I think that's
>>> one of the main reasons to use a layout right? To keep stuff in place
>>> in case of resising the container. What do you think?
>>>
>>>
>>>
>>>
>>>
>>> > > Also, it seems that sometimes the horizontal fill alignment and
>>> the grab
>>> > > excess space features don't work in certain cases. At runtime
>>> things
>>> > > work as expected but sometimes the preview looks wrong. I know
>>> I'm not
>>> > > being very specific but it seems kind of random to me.
>>> >
>>> > I couldn't recreate this problem but since you ran across it there
>>> may
>>> > be a bug somewhere that I would like to fix. Could you provide a
>>> > scenario that you can continuously recreate the problem? Or provide a
>>> > sample application that shows this problem easily?
>>> >
>>>
>>>
>>> I found why this was happening but it's really strange abd I still
>>> can't find a pattern because sometimes it works well. The reason why
>>> the horizontal fill alignment wasn't working was because the changes
>>> I made in the Customize Layout Window weren't being reflected in the
>>> VE generated code. I created a composite, assigned it a grid layout,
>>> dropped a few controls and then tried to change the horizontal fill
>>> alignment in a button and although the Customize Layout Window had
>>> the button checked, the corresponding code wasn't being generated by
>>> VE. Could this be related to the other problem with refreshing
>>> Customize Layout Window properties when clicking the beans view?
>>>
>>> ----------------------------------------------
>>>
>>>
>>> Also, this afternon I was fooling around with simple experiments with
>>> VE for a couple of hours and another issue came up. This happenned
>>> twice although a couldn't find a pattern and couldn't reproduce it
>>> anymore but it went as follows: I created a composite and added a few
>>> controls, something like 2 buttons and a text. After messing around
>>> with the controls a bit, I changed the button name (not the text, the
>>> actual name) in the bean properties view and this caused the text
>>> control to disappear. It's weird but that's what happened. It wasn't
>>> in the code, the bean view or the graphical viewer anymore.
>>>
>>> -----------------------------------------------
>>>
>>>
>>> All this stuff happened while doing very simple experiments with VE.
>>> Things like creating a composite, creating two sub-groups on it,
>>> assigning them a grid layout (that's what I use the most) dropping 5
>>> or 6 controls on each, changing the alignment, fill, a few renames,
>>> etc. After a while weird stuff starts to happen.
>>>
>>> I used 1.0.2.1 for hours and it worked just the way I expected and
>>> everything made sense. Could I suggest to you trying to do something
>>> similar to what I described? Just create a class, drop a few controls
>>> and fool with them for a while. At least in my system it doesn't take
>>> to long for strange stuff to start happening. I'm sorry I can't be
>>> more specific...
>>>
>>>
>>> Thanks a lot, and I hope I'm not being a pain with these long posts...
>>>
>>> Miguel Barrosa
>
>
>
> ------------------------------------------------------------ ------------
>
> package org.primos.gprot;
>
> import org.eclipse.jface.dialogs.MessageDialog;
> import org.eclipse.swt.SWT;
> import org.eclipse.swt.graphics.Point;
> import org.eclipse.swt.layout.FillLayout;
> import org.eclipse.swt.layout.GridData;
> import org.eclipse.swt.layout.GridLayout;
> import org.eclipse.swt.widgets.Button;
> import org.eclipse.swt.widgets.Composite;
> import org.eclipse.swt.widgets.Control;
> import org.eclipse.swt.widgets.Group;
> import org.eclipse.swt.widgets.Label;
> import org.eclipse.swt.widgets.Shell;
> import org.eclipse.swt.widgets.Text;
>
> public class VisCmpMainDataJob extends Composite
> {
> // My vars
> private Composite parent;
>
> private Button buttonPrint = null;
> private Group groupPacient = null;
> private Label label11 = null;
> private Text textName = null;
> private Label label12 = null;
> private Text textSex = null;
> private Label label13 = null;
> private Text textBirthdate = null;
> private Label label14 = null;
> private Text textFace = null;
> private Label label5 = null;
> private Text textAge = null;
> private Label label7 = null;
> private Text textAddress = null;
> private Label label8 = null;
> private Text textBi = null;
> private Label label9 = null;
> private Text textContrib = null;
> private Group groupJob = null;
> private Label label10 = null;
> private Text textDescription = null;
> private Label label15 = null;
> private Text textDoc = null;
> private Label label16 = null;
> private Text textLab = null;
> private Label label2 = null;
> private Text textJobName = null;
> private Button buttonDelete = null;
> private Label label = null;
> private Text textPhone1 = null;
> private Label label1 = null;
> private Text textPhone2 = null;
> private Label label3 = null;
> private Text textCellPhone1 = null;
> private Label label4 = null;
> private Text textCellPhone2 = null;
> private Label label17 = null;
> private Text textPostalCode = null;
> private Button buttonEditPacient = null;
> private Label label18 = null;
> private Text textGroup = null;
> private Label label19 = null;
> private Button buttonEditJob = null;
>
> public VisCmpMainDataJob(Composite parent, int style)
> {
> super(parent, style);
> this.parent = parent;
> initialize();
> populateFields();
> }
> // End VisCmpMainDataJob
>
>
> void populateFields()
> {
> Job t = Common.jobMng.getActiveJob();
>
> if(t == null) // Ainda n

Report message to a moderator

Re: VE preview goes way out of the viewable screen and other strange behaviours [message #94350 is a reply to message #93515]

Sun, 19 June 2005 16:09

Eclipse User

Originally posted by: devmike.netcabo.pt

Hi Peter. Sorry for taking this long to reply, I've been away on
vacation for the whole week.

> Miguel,
> > I'd like to open a bug regarding the SWT behavior we discussed, but
> > it's not clear to me how I should describe the problem, since I don't
> > really understand what changed in the SWT layouts to cause the
problem.
> > Can you help me describe the problem so that I can fill the bug
report?
>
> I opened a bug report -->
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99441
> You may want to add yourself to the CC: list show you can follow the
> responses.

Thanks for opening the bug report for me. One question: do you think
this bug addresses the behaviour we discussed earlier, where the beans
appeared way out of the visible screen area? Or is it a different
problem? If it's a different problem, could I suggest opening a new bug
report for SWT? For me this is the most annoying aspect of the changes
in SWT 3.1's GridLayout. Again, I would gladly do it myself but I don't
think I can describe the problem clearly.

> > 1) Try opening the attached file in VE and then try to add a
button or a
> > label before the button labeled 'Apagar'. In my system, the new bean
> > always appears after the last button (the one labeled 'Imprimir'), no
> > matter where I drop it. How does it work for you?
>
> I tried this and it worked fine for me. I selected a button from the
> palette, dragged the mouse to just before the button 'Apagar', a solid
> black line appears before it, and released the mouse. The button was
> placed before the button 'Apagar'. Are you using the Graph view or Beans
> view to drop the button? In the graph viewer you always get a double
> thick black line on a GridLayout (I increased the width of the insertion
> line because it was sometimes hard to see).

Ok, Peter, I don't know what happened. Tried this again and it worked
fine. I'm pretty sure it happened the first time, though.

> > If I wanted the 'Apagar' and 'Imprimir' buttons right aligned and with
> > the same size, do you think it's good practice to set the main
> > Composite's GridLayout to, say 10 columns (more or less, depending on
> > the preferred button size), make the columns equal width, and drop a
> > invisible label to the left of the buttons spanning 8 columns to make
> > the buttons go to the right? Of course, both groupJop and groupPacient
> > would have to horizontally span 10 columns in order to get to the
> next row.
>
> This would work fine... I've seen it as a common practice to "fill"
> columns in a grid layout with empty labels. If fact, we are looking a
> making some enhancements to the VE gridlayout such that when you insert
> a control at the end or beginning of a row, in order to keep controls
> from reflowing, increase the numColumns by one and add empty labels into
> other rows so as to preserve the original positions of the neighboring
> controls. What do you think about this idea?
> Another option for you is to insert a Composite with the two buttons on
> it and have the Composite (with the buttons) span across all the columns
> (8 or 10). Of course the Composite layout would also be a GridLayout
> with two columns.
> Then play with the Customize Layout window for each of the buttons to
> get them over to the far right side of the Composite. Attached is just
> one example of what can be done.
>
> Thanks for input!
>
> Regards...
>
> Peter Walker
> VE Development

Again, thanks for your help and suggestions regarding this. As for the
VE enhancement you mentioned, it seems to be a nice idea. However, I
think it would be more flexible to make that behaviour optional (and
maybe not enabled by default) because other users might be used to the
current behaviour and find the new one a bit unexpected. I'm saying this
because, as far as I can tell, this would be the first time when VE
would automatically generate new beans without user intervention, which
might surprise some users. My opinion in this kind of thing is not to be
to conservative, and if it improves the product, it should be done, but
keeping the previous behaviour available.

>
>
> DevMike wrote:
>
>> Hi Peter.
>>
>> I'd like to open a bug regarding the SWT behaviour we discussed, but
>> it's not clear to me how I should describe the problem, since I don't
>> really understand what changed in the SWT layouts to cause the
>> problem. Can you help me describe the problem so that I can fill the
>> bug report?
>>
>>
>> As for 1.1M2 it feels much better. However I came across two issues:
>>
>> 1) Try opening the attached file in VE and then try to add a button or
>> a label before the button labeled 'Apagar'. In my system, the new bean
>> always appears after the last button (the one labeled 'Imprimir'), no
>> matter where I drop it. How does it work for you?
>>
>> 2) Create a new visual class (Composite), assign it a gridlayout with
>> 3 columns, drop a button so that the grid appears. Now make the
>> columns equal width.
>> In 1.0.2.1 making the colums equal width made the 3 columns' width
>> expand until they completely filled the composite's width (equally
>> divided by three, of course).
>> In 1.1M2 the same action makes all the columns' width equal to the
>> width of the widest column of the 3 (that is, of course, the first
>> column which contains the button).
>> I don't know if this change was intentional, but I prefer the 1.0.2.1
>> behaviour.
>>
>>
>> If you have the time and patience I'd like to ask you a question
>> regarding my use of GridLayout in the attached file:
>>
>> If I wanted the 'Apagar' and 'Imprimir' buttons right aligned and
>> with the same size, do you think it's good practice to set the main
>> Composite's GridLayout to, say 10 columns (more or less, depending on
>> the preferred button size), make the columns equal width, and drop a
>> invisible label to the left of the buttons spanning 8 columns to make
>> the buttons go to the right? Of course, both groupJop and groupPacient
>> would have to horizontally span 10 columns in order to get to the next
>> row.
>>
>> Thanks a lot in advance,
>> Miguel Barrosa
>>
>>
>>
>> Peter Walker wrote:
>>
>>> Miguel,
>>> Sorry to take so long to reply... been heads down trying to get M2
>>> out the door.
>>>
>>> >In my opinion, I
>>> > would prefer if VE (or SWT for that matter) kept all the controls
>>> inside
>>> > the Shell. The scrolling thing is not practical at all. If I'm not
>>> using
>>> > a enormous amount of controls in a row, I think they should be
>>> resized
>>> > to fit the size of the Shell...
>>>
>>> I tend to agree with you but there is nothing VE can do about it
>>> since this behavior comes directly from SWT. I would recommend
>>> opening a bug against Eclipse 3.1 - the SWT component - and see what
>>> they say.
>>> BTW... I tried this with a RowLayout with wrap & pack turned off...
>>> same thing occurs.
>>>
>>> I've recently made a lot of changes to GridLayout and null... and
>>> many fixes in general have been made to VE for 1.1M2. Another
>>> integration build will be available on 6/10 which is a candidate for
>>> M2. If you get a chance, please try some of your GridLayout scenarios
>>> on this build and report any bugs you find.
>>>
>>> Thanks...
>>> Peter Walker
>>>
>>>
>>> DevMike wrote:
>>>
>>>> Hi Peter, thanks a lot for your help.
>>>>
>>>>
>>>> > > The problem happens when I'm using a SWT grid layout with 10
>>>> to 12
>>>> > > columns with equal size, the preview goes waaaay out to the
>>>> side of the
>>>> > > screen. The only way I can see the complete set of beans is if
>>>> I resize
>>>> > > the composite containing them to a much bigger size and then
>>>> do a BIG
>>>> > > scroll (2,3 x the width of the screen) to get to the beans. Is
>>>> this
>>>> > > normal? In 1.0.2.1 VE kept all the widgets in the viewable
>>>> area of the
>>>> > > screen, no scrolling was necessary.
>>>> >
>>>> > It looks like SWT GridLayout has changed from Eclipse 3.0.1 to 3.1.
>>>> > I created a Shell application with a GridLayout, numColumns=10,
>>>> > makeColumnsEqualWidth=true... dropped 10 controls. I had to drag
>>>> the
>>>> > width of the Shell to the right to fit them in also. But when I
>>>> run the
>>>> > app, it shows the same behavior as the VE graph view.
>>>> > I imported the same app into my VE 1.0.2.1 runtime (which is
>>>> based on
>>>> > Eclipse 3.0.1), and both the running app and VE graph viewer will
>>>> try to
>>>> > squeeze the controls to the smallest size possible depending on the
>>>> > Shell size.. even if it truncates each of the controls.
>>>> > For Eclipse 3.1, it sizes each column based on the largest sized
>>>> > control... which explains why you have to keep resizing the Shell in
>>>> > order to make the controls fit.
>>>> > I don't see this as VE bug since this is the same behavior is
>>>> displayed
>>>> > in the runtime app as in the VE graph viewer. But I did discover
>>>> another
>>>> > but while trying this scenario. The red grid lines don't show the
>>>> proper
>>>> > column positions as the Shell is resized and more controls are
>>>> added. I
>>>> > opened a bug to track this
>>>> > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=97559).
>>>>
>>>>
>>>> I agree that this might not be a VE fault, but I still think the
>>>> behaviour should be different for usabilty purposes. In my opinion,
>>>> I would prefer if VE (or SWT for that matter) kept all the controls
>>>> inside the Shell. The scrolling thing is not practical at all. If
>>>> I'm not using a enormous amount of controls in a row, I think they
>>>> should be resized to fit the size of the Shell until it's not
>>>> possible to do so (if I resize it to a very small size). After all,
>>>> I think that's one of the main reasons to use a layout right? To
>>>> keep stuff in place in case of resising the container. What do you
>>>> think?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > > Also, it seems that sometimes the horizontal fill alignment
>>>> and the grab
>>>> > > excess space features don't work in certain cases. At runtime
>>>> things
>>>> > > work as expected but sometimes the preview looks wrong. I know
>>>> I'm not
>>>> > > being very specific but it seems kind of random to me.
>>>> >
>>>> > I couldn't recreate this problem but since you ran across it
>>>> there may
>>>> > be a bug somewhere that I would like to fix. Could you provide a
>>>> > scenario that you can continuously recreate the problem? Or
>>>> provide a
>>>> > sample application that shows this problem easily?
>>>> >
>>>>
>>>>
>>>> I found why this was happening but it's really strange abd I still
>>>> can't find a pattern because sometimes it works well. The reason why
>>>> the horizontal fill alignment wasn't working was because the changes
>>>> I made in the Customize Layout Window weren't being reflected in the
>>>> VE generated code. I created a composite, assigned it a grid layout,
>>>> dropped a few controls and then tried to change the horizontal fill
>>>> alignment in a button and although the Customize Layout Window had
>>>> the button checked, the corresponding code wasn't being generated by
>>>> VE. Could this be related to the other problem with refreshing
>>>> Customize Layout Window properties when clicking the beans view?
>>>>
>>>> ----------------------------------------------
>>>>
>>>>
>>>> Also, this afternon I was fooling around with simple experiments
>>>> with VE for a couple of hours and another issue came up. This
>>>> happenned twice although a couldn't find a pattern and couldn't
>>>> reproduce it anymore but it went as follows: I created a composite
>>>> and added a few controls, something like 2 buttons and a text. After
>>>> messing around with the controls a bit, I changed the button name
>>>> (not the text, the actual name) in the bean properties view and this
>>>> caused the text control to disappear. It's weird but that's what
>>>> happened. It wasn't in the code, the bean view or the graphical
>>>> viewer anymore.
>>>>
>>>> -----------------------------------------------
>>>>
>>>>
>>>> All this stuff happened while doing very simple experiments with VE.
>>>> Things like creating a composite, creating two sub-groups on it,
>>>> assigning them a grid layout (that's what I use the most) dropping 5
>>>> or 6 controls on each, changing the alignment, fill, a few renames,
>>>> etc. After a while weird stuff starts to happen.
>>>>
>>>> I used 1.0.2.1 for hours and it worked just the way I expected and
>>>> everything made sense. Could I suggest to you trying to do something
>>>> similar to what I described? Just create a class, drop a few
>>>> controls and fool with them for a while. At least in my system it
>>>> doesn't take to long for strange stuff to start happening. I'm sorry
>>>> I can't be more specific...
>>>>
>>>>
>>>> Thanks a lot, and I hope I'm not being a pain with these long posts...
>>>>
>>>> Miguel Barrosa

Report message to a moderator