Skip to main content

Component positioning problem

5 replies [Last post]
Anonymous

Hi again,

I've hit two problems, might be related to a bug.

1. The normal dialog is not shown at the required place
vertically:

Dialog d = new Dialog("");

d.show(40, 40, 40, 40, false);

// just an empty dialog to make it simplest.

When the dialog is shown, the distance on top appears to be 45, instead
of 40.

2. If I create MyDialog (extends Dialog) and add a
MyAnimatedComponent (extends Component implements Animation) to it, the
position of

MyAnimatedComponent is shifted with a deltaX and deltaY of a few pixles
(into tinted area), when animate() returns true. But no shifting when
animate() returns false.

The size of MyAnimatedComponent appears to be the same as returned from
its calcPreferredSize().

Thanks,

Qunhuan

[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Shai Almog

Hi Qunhuan,

> 1. The normal dialog is not shown at the required place
> vertically:
>
> Dialog d = new Dialog("");
> d.show(40, 40, 40, 40, false);
> // just an empty dialog to make it simplest.
>
> When the dialog is shown, the distance on top appears to be 45,
> instead of 40.

There are default margin/padding for various components in LWUIT
usually around the 3 pixel mark. These are arbitrary to have
applications "look good" by default, if you want to make sure
everything is positioned pixel perfect just reset the padding and
margin for components.

In the case of a dialog, the title seems to have some default margin
which can be reset as in the example code bellow:
Display.getInstance().callSerially(new Runnable() {
public void run() {
Form test = new Form("Form & Dialog");
Dialog dlg = new Dialog("Dialog") {
};
test.show();
dlg.addComponent(new Label("Dialog Content"));
dlg.getTitleComponent().getStyle().setMargin
(0, 0, 0, 0);
dlg.show(1, 1, 1, 1, false);
}
});

I'll try to get a fix for that in the next release, I know there were
some issues involved with this so it might not be as simple as I
think ;-)

>
> 2. If I create MyDialog (extends Dialog) and add a
> MyAnimatedComponent (extends Component implements Animation) to it,
> the position of
> MyAnimatedComponent is shifted with a deltaX and deltaY of a few
> pixles (into tinted area), when animate() returns true. But no
> shifting when animate() returns false.
>
> The size of MyAnimatedComponent appears to be the same as returned
> from its calcPreferredSize().
>
This sounds like an application bug since we don't do anything when
you return false... However just to make sure...
When your component is painted extract the tranlateX & translateY
values of the Graphics object received (e.g. graphics.getTranslateX()).
Print them out to the console and see if they differ between calls, I
assume that when you draw you also add the components X/Y location
rather than drawing in 0,0 e.g.:

// fill the entire component drawing region:
g.fillRect(getX(), getY(), getWidth(), getHeight());

// this is incorrect code:
g.fillRect(0, 0, getWidth(), getHeight());

Thanks,
Shai.

[att1.html]

Qunhuan Mei

Hi again Shai,

...

2. If I create MyDialog (extends Dialog) and add a
MyAnimatedComponent (extends Component implements Animation) to it, the
position of

MyAnimatedComponent is shifted with a deltaX and deltaY of a few pixles
(into tinted area), when animate() returns true. But no shifting when
animate() returns false.

The size of MyAnimatedComponent appears to be the same as returned from
its calcPreferredSize().

This sounds like an application bug since we don't do anything when you
return false... However just to make sure...

When your component is painted extract the tranlateX & translateY values
of the Graphics object received (e.g. graphics.getTranslateX()).

Print them out to the console and see if they differ between calls, I
assume that when you draw you also add the components X/Y location
rather than drawing in 0,0 e.g.:

// fill the entire component drawing region:

g.fillRect(getX(), getY(), getWidth(), getHeight());

// this is incorrect code:

g.fillRect(0, 0, getWidth(), getHeight());

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Just to let you know:

1. The "shifting" I mentioned above is the system's behaviour
(e.g. from LWUIT's paint behaviour somewhere, since I removed all code
in my paint() method).

2. The "shifting" appears to be a background cleaning - just a
white rectangular sized as what calcPreferredSize() returns. I did not
set any other data apart from show(61, 61, 20, 20, false).

3. The "shifting" might be margin/padding/translate related, here
is the data:

Shifting amount: x: 10; y: 21 (manually measured), away from the
central part.

System query data (within MyAnimatedComponent's paint method):

getX: 10; getY: 117;

translateX: 20; Y: 65

width: 200; height: 29

horizontal margin: 2; padding: 3;

vertical margin: 2; padding: 3

Hope this helps,

Qunhuan

[att1.html]

Shai Almog

Hi Qunhuan,

I'm having a really hard time understanding these values without code/
images to map them. I also don't understand what "centeral part" means?
All our positioning is based on the top/left corner relatively to the
parent container (Dialog has no parent container, it's positioned
relative to the screen itself).

If you can submit a short snippet that demonstrates the problem with
explanation that would help allot.

Thanks,
Shai.
> 1. The “shifting” I mentioned above is the system’s behaviour
> (e.g. from LWUIT’s paint behaviour somewhere, since I removed all
> code in my paint() method).
>
> 2. The “shifting” appears to be a background cleaning – just
> a white rectangular sized as what calcPreferredSize() returns. I
> did not set any other data apart from show(61, 61, 20, 20, false).
>
> 3. The “shifting” might be margin/padding/translate related,
> here is the data:
>
> Shifting amount: x: 10; y: 21 (manually measured), away from the
> central part.
>
> System query data (within MyAnimatedComponent’s paint method):
>
> getX: 10; getY: 117;
>
> translateX: 20; Y: 65
>
> width: 200; height: 29
>
> horizontal margin: 2; padding: 3;
>
> vertical margin: 2; padding: 3
>
> Hope this helps,
>
>
>
> Qunhuan
>
>
>

[att1.html]

Qunhuan Mei

Hi Shai,

I fully understand your feeling - I am so sorry! Hope it did not spoil
your day!

I have sent an isolated code case to your sun's email address so that
you may be able to figure out the problem.

Many thanks,

Qunhuan

From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
Sent: 13 June 2008 11:28
To: users@lwuit.dev.java.net
Subject: Re: Component positioning problem

Hi Qunhuan,

I'm having a really hard time understanding these values without
code/images to map them. I also don't understand what "centeral part"
means?

All our positioning is based on the top/left corner relatively to the
parent container (Dialog has no parent container, it's positioned
relative to the screen itself).

If you can submit a short snippet that demonstrates the problem with
explanation that would help allot.

Thanks,

Shai.

1. The "shifting" I mentioned above is the system's
behaviour (e.g. from LWUIT's paint behaviour somewhere, since I removed
all code in my paint() method).

2. The "shifting" appears to be a background cleaning -
just a white rectangular sized as what calcPreferredSize() returns. I
did not set any other data apart from show(61, 61, 20, 20, false).

3. The "shifting" might be margin/padding/translate
related, here is the data:

Shifting amount: x: 10; y: 21 (manually measured), away from
the central part.

System query data (within MyAnimatedComponent's paint method):

getX: 10; getY: 117;

translateX: 20; Y: 65

width: 200; height: 29

horizontal margin: 2; padding: 3;

vertical margin: 2; padding: 3

Hope this helps,

Qunhuan

[att1.html]

Shai Almog

Hi Qunhuan,
got it and it didn't spoil my day. In fact you found a LWUIT bug,
which is a very good thing ;-)

I understand the problem you were describing much better now...

And I must admit it caught me by surprise.
The problem in the code seems to be a LWUIT bug in FlowLayout (which
is the default layout manager for containers), I worked around it by
adding the following line to your code:
public MyDialog(String message, int width, int height) {
setLayout(new BoxLayout(BoxLayout.Y_AXIS));
// ...

This is what happened:

1. You defined a component with preferred width of 200.

2. You added it to a dialog with a width of 200.

3. It got positioned in x 10 position leaving only 190 pixels.

4. Flow layout has a bug where it actually gave the component a 200
pixel width which it isn't allowed to do since there aren't 200
pixels to give.

5. When painting the component in the proper order (when showing the
dialog) clipping worked as expected since the parent clipping was 200
and clipping will only shrink going down the hierarchy and never grow.

6. When you defined the component as animated the clipping was set to
its size (which the layout manager miscalculated).

I need to track this down to confirm that this is indeed the bug and
that there is a simple solution for the problem, Chen is a bigger
expert in layout managers so I'll consult about this with him but I
think this should be fixable. Thanks!

As a side note its best to register animations in the init method as
such:
protected void initComponent() {
getComponentForm().registerAnimated(this);
}

Also the dialog constructor calls getWidth() which will always return
0 at this stage, you should probably use getPreferredW() or
Display.getInstance().getDisplayWidth().

Thanks,
Shai.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net