Problem opening forms

You are here:

Hello,
I open severals forms with f.show() in my aplication. When I have opened 7 or 8 forms I get this error: "An exception occured during transition paint this might be valid in case of a resize in the middle of a transition
java.lang.OutOfMemoryError
Uncaught exception java/lang/OutOfMemoryError."

Hi Matteo,
essentially what you want it a more complex data type which you can
solve using a domain object and a renderer.
Rather than build a list of Strings and their values (with the
hashtable) build something like this:

If you want to save on the additional class you can use an array
instead for every value within the list (first element in the array
would be key and the second would be value).

For more details see the renderer demo and the tutorial/developer guide.

Thanks,
Shai.

> Hi all,
> I need your advice.
> I store some data into a Hashtable, now I need to show these
> elements into a
> List.
> The List constructor can only accept an Object array or a Vector.
>
> How can I efficiently convert the Hashtable to a Vector or an array?
>
>
>
> Thanks in advance,
> Matteo
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

I have a networked thread that gets a list of serialized objects from the
server.
Each object has an ID (integer).
My "view" must render this objects list... as a List.

So, this is the solution I thought of:
The 'model' is an in-memory DB (the list never exceeds some dozen of items).
It stores internally the items collection that it gets from the network
thread. I chose the Hashtable as the data structure to store the items in
(key=ID, value=Object)
The model is kept updated by the thread, as it receives new data from the
server (in a true push way, I'm using a socket connection), so that's why I
thought of the Hashtable (so when I get an update, it's only a matter of
calling myHash.get(object.id) to retrieve the stored item and update it)

The view List has the 'model' as its ListModel, so when the model gets
updated, the changes are (hopefully) instantly reflected.

I don't see why you need the Hashtable?
If you don't have many objects in the model then you can just search
the model and update the object, to refresh the list call
DefaultListModel.setItem(int, Object) which will automatically
refresh the list view without a need for repaint.
Adding elements to the model should be doable from your network
thread since the DefaultListModel is thread "aware" meaning that you
should still modify it only from one thread, but it doesn't have to
be the EDT.

Hope that helps,
Shai.

> Ok, let me try to better expand this one (if I'm going OT please
> tell me,
> dont' want to abuse your help)
>
> I have a networked thread that gets a list of serialized objects
> from the
> server.
> Each object has an ID (integer).
> My "view" must render this objects list... as a List.
>
> So, this is the solution I thought of:
> The 'model' is an in-memory DB (the list never exceeds some dozen
> of items).
> It stores internally the items collection that it gets from the
> network
> thread. I chose the Hashtable as the data structure to store the
> items in
> (key=ID, value=Object)
> The model is kept updated by the thread, as it receives new data
> from the
> server (in a true push way, I'm using a socket connection), so
> that's why I
> thought of the Hashtable (so when I get an update, it's only a
> matter of
> calling myHash.get(object.id) to retrieve the stored item and
> update it)
>
> The view List has the 'model' as its ListModel, so when the model gets
> updated, the changes are (hopefully) instantly reflected.
>
> What do you think about that? Do you see a better solution?
>

Hi Qunhuan,
I'd like to correct some of my assertions from a previous post
regarding container animation registration.
It seems containers do have smooth scrolling its just a bit different
(its odd I don't remember this since I implemented it), the
initComponentImpl() internal method registers the Form animation
which is causing the behavior you are seeing. If I remove it
scrolling for containers will stop working! Not a desired result.

However, you can disable smooth scrolling on your specific container
(before adding or showing it!) which will result in the same effect
e.g.:

Dialog myDlg = ...;
myDlg.setSmoothScrolling(false);

Should solve your problem and have no ill effects as long as you
don't try scrolling in the dialog itself.

1. If I call setSmoothScrolling(false) in constructor, it stops calling
animate() as well as subsequent paint() (so I can't use it this way
otherwise I have no animation)

2. If I call setSmoothScrolling(false) in paint() method, it has no
effect (so I can't use it to control my dialog's behaviour).

3. The animate() always gets called continuously in the dialog even I
did not call registerAnimated(this), or even after it returns false -
could you confirm?

So this setSmoothScrolling(false) appears to be not relevant to my case.

Many thanks,

Qunhuan

-----Original Message-----
From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
Sent: 13 June 2008 06:41
To: users@lwuit.dev.java.net
Subject: Re: Is it a bug - the last component shown does not always have
focus? + Re: Can we change a dialog's size?

Hi Qunhuan,
I'd like to correct some of my assertions from a previous post
regarding container animation registration.
It seems containers do have smooth scrolling its just a bit different
(its odd I don't remember this since I implemented it), the
initComponentImpl() internal method registers the Form animation
which is causing the behavior you are seeing. If I remove it
scrolling for containers will stop working! Not a desired result.

However, you can disable smooth scrolling on your specific container
(before adding or showing it!) which will result in the same effect
e.g.:

Dialog myDlg = ...;
myDlg.setSmoothScrolling(false);

Should solve your problem and have no ill effects as long as you
don't try scrolling in the dialog itself.

Hi Gunhuan,
> Had tried to use setSmoothScrolling(false) in MyAnimatedDialog:
>
> 1. If I call setSmoothScrolling(false) in constructor, it stops
> calling
> animate() as well as subsequent paint() (so I can't use it this way
> otherwise I have no animation)

Thats true, now in order for your animation to work you will need to
register the animatable yourself.
Don't forget that everything I said before about animating a dialog
still applies, if you animate a dialog it will repaint the entire
background (including the background form). So you should still use
an internal component for your animation as I understood you were
doing in the previous email.

>
> 2. If I call setSmoothScrolling(false) in paint() method, it has no
> effect (so I can't use it to control my dialog's behaviour).

This won't work, as I said you MUST invoke setSmoothScrolling(false)
before adding/showing the component since registering it as animated
occurs at that point.
Deregistering of animation never occurs since we have no idea if the
component was registered as animated explicitly or implicitly.

On init, which occurs when a component is added or shown a container
checks its smooth scrolling flag and registers itself as animated
appropriately.

> 3. The animate() always gets called continuously in the dialog even I
> did not call registerAnimated(this), or even after it returns false -
> could you confirm?

Yes, thats the intended behavior.

> So this setSmoothScrolling(false) appears to be not relevant to my
> case.

The reason I informed you of this is that this behavior (calling
animate even though you didn't register an animation) is correct and
won't change in the next version of LWUIT.
Since smooth scrolling is active we implicitly register an animation.

The proper solution to prevent the background form from animating is
to avoid animating the dialog class and instead animate a component
within the dialog. I understand you are already using this approach,
right?

The proper solution to prevent the background form from animating is
to avoid animating the dialog class and instead animate a component
within the dialog. I understand you are already using this approach,
right?

-- I only just truly understand what you mean and it indeed worked and
the background animation is stopped. Perfect!

The problem left now is only the positioning of animated component
inside a dialog.

Hi Qunhuan,
See Display.getInstance().setFramerate(), although it will increase
the speed of all animations...
LWUIT waits between paints to allow application logic to run. Notice
that this will have no effect on transitions etc... where LWUIT tries
to grab every bit of CPU possible...

Thanks,
Shai.

> Hi again,
>
> I have created a component of mine which does some animation. The
> frequency of painting each frame is controlled by the system.
>
> Just wondered if there is any way I could change this frequency. I
> tried
> setScrollAnimationSpeed(...) in constructor but seems to be no effect.
>
> Thanks,
>
> Qunhuan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

It works when the rate is set to low. However the max repaint rate is
"capped" at probably 10 frames a sec (I am not drawing any complicated
stuff), even if I set the rate at 20, 30, 100, ... on my Vista machine
with Quad CPU.

Hi Qunhuan,
See Display.getInstance().setFramerate(), although it will increase
the speed of all animations...
LWUIT waits between paints to allow application logic to run. Notice
that this will have no effect on transitions etc... where LWUIT tries
to grab every bit of CPU possible...

Thanks,
Shai.

> Hi again,
>
> I have created a component of mine which does some animation. The
> frequency of painting each frame is controlled by the system.
>
> Just wondered if there is any way I could change this frequency. I
> tried
> setScrollAnimationSpeed(...) in constructor but seems to be no effect.
>
> Thanks,
>
> Qunhuan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

Hi Qunhuan,
did you try setting it to 1000 and it didn't have an effect?
LWUIT would obviously have some overhead on drawing but it shouldn't
be much.
Every rendering loop has a 1 millisecond sleep which is the highest
framerate defined.

If you are experiencing noticeable performance difference (compared
to plain MIDP canvas) with simple drawing when setting the framerate
lock to 1000 then I will investigate this.

Thanks,
Shai.

> Hi again Shai,
>
> I suspect it is probably due to LWUIT. I had an app of my own which
> fully controls the repaint frequency and runs on WTK as expected.
>
> Thanks,
>
> Qunhuan
>

Hi Qunhuan,
did you try setting it to 1000 and it didn't have an effect?
LWUIT would obviously have some overhead on drawing but it shouldn't
be much.
Every rendering loop has a 1 millisecond sleep which is the highest
framerate defined.

If you are experiencing noticeable performance difference (compared
to plain MIDP canvas) with simple drawing when setting the framerate
lock to 1000 then I will investigate this.

Thanks,
Shai.

> Hi again Shai,
>
> I suspect it is probably due to LWUIT. I had an app of my own which
> fully controls the repaint frequency and runs on WTK as expected.
>
> Thanks,
>
> Qunhuan
>

Hi Qunhuan,
Focus is a rather complex issue so please forgive me if the
explanation seems a bit trivial at times.

Focus in most UI systems is handled by a focus root which can hold
only one focused component at a given time in LWUIT this root is a
Form, unlike a typical windowing system only one form can be shown at
a time.

In a typical Windowing system a window is a focus root, so you may
have two application windows open simultaneously and thus two
components would have focus at a given time.

In LWUIT this is theoretically possible if you call onto a form which
is not visible (which is what you are experiencing).

Technically you have no focus, the dialog is a form and neither one
of these is focused since they are containers and containers don't
grab focus.

If your dialog has a focusable component within it then it will grab
focus.

When a dialog is rendered you see the previous form in the
background, but this form isn't the current form and for all intents
and purposes its focus is irrelevant since it won't get any events.
The background drawing of the form is performed by the dialogs
background painter and is really a "drawing" and not the actual
underlying form appearing in the background...

I'm not exactly clear on the problem you are having with focus, so I
can't think of how to help this further.

I hope its clear why I don't consider the fact that two components
(under different focus roots) have focus in the same time to be a bug.

Thanks,
Shai.

> I would like to change the question since I figure the "focus" is not
> relevant to my requirement since it is a property for a component
> or an
> item. Only focusable one could have focus. It is nothing to do with
> visible or not.
>
> On the other hand, I could see a list form behind a dialog is still
> visible or isVisible() returns true. Not sure if this if is intended
> design.
>
> I do realise there is manual control to setEnabled() to true/false,
> which could be used to satisfy my requirement.
>
> Thanks,
>
> Qunhuan
>
> -----Original Message-----
> From: Qunhuan Mei [mailto:qunhuan.mei@mfuse.com]
> Sent: 11 June 2008 11:31
> To: users@lwuit.dev.java.net
> Subject: Is it a bug - the last component shown does not always have
> focus? + Re: Can we change a dialog's size?
>
> Greetings again!
>
> I first displayed a customised list form which has some specific
> animation. Then a click to a list item triggers a dialog form. I was
> hoping to use hasFocus() to stop the animation on the list form
> since I
> guess the focus has moved from list form to the dialog one.
>
> To my surprise, the dialog's hasFocus() always returns false, and the
> list's hasFocus() always returns true.
>
> Is this a bug since I would assume the last component shown will
> always
> have focus?
>
> Thanks,
>
> Qunhuan
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Shai, I was off work yesterday. Many thanks for your detailed
> explanation. It helped.
>
>
> -----Original Message-----
> From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
> Sent: 09 June 2008 17:03
> To: users@lwuit.dev.java.net
> Subject: Re: Can we change a dialog's size?
>
> Hi Qunhuan,
> thanks for reminding me to update the dialog javadocs...
> Since a dialog is a form the preferred size will have no effect on
> it, both forms and dialogs always take over the entire screen...
> A dialog physically controls the entire screen size, but using a
> special painter draws the previous form in the background (tinted).
>
> To control the positioning of the dialog use the version of show that
> accepts 4 integer values: show(int, int, int, int);
>
> Unlike most API's of this sort it accepts the margins to position the
> dialog (space from edges) e.g.:
> Dialog.show(11, 12, 13, 14);
> Will show a dialog 11 pixels from the top, 12 from the bottom, 13
> from the left and 14 from the right.
>
> The logic here is that usually you would position a dialog based on
> space from every direction rather than absolutely in the screen so
> while this is different from convention it is very similar to our
> design sensibilities.
>
> Notice that to apply elements to the dialog (such as background image
> etc.) you would usually use the dialog content pane rather than the
> dialog itself... Since the dialog occupies the entire screen yet its
> content pane does not.
>
> Thanks,
> Shai.
>
>> I was trying to setPreferredSize for a Dialog. But all efforts
>> (e.g. instantiate one and set its size then show it or extend one
>> and set its size and show it) failed. Is a Dialog's size fixed or
>> how can I change it?
>>
>> Thanks,
>>
>> Qunhuan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

I am amazed to see your patience in understanding us developers and
promptly answer/investigate our queries. You must have tons of work at
hand and delivery deadlines to meet etc. So I am sorry if I happen to
ask some trivial questions ...

My actual use case here is that I have two components, one is a list
form, the other is a dialog. Both has been customised.

The list form has some specific animations. When one item is clicked, it
triggers the dialog to be displayed (the "dialog" also has its own
animation).

Currently after this dialog is displayed, the animation on list still
continues and is visible in tinted area. I am looking for a flag from
List class to be used to automatically stop the list animation. But
seems to me neither isEnabled(), nor isVisible() from the list returns
the value I would expected after the dialog is displayed. Thought once
the list form is covered by a dialog form, list.isVisible() or
list.isEnabled() would return false. So it looks the only way out at the
moment is to use manual control instead of an automatic one.

Many thanks,

Qunhuan

-----Original Message-----
From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
Sent: 11 June 2008 15:04
To: users@lwuit.dev.java.net
Subject: Re: Is it a bug - the last component shown does not always have
focus? + Re: Can we change a dialog's size?

Hi Qunhuan,
Focus is a rather complex issue so please forgive me if the
explanation seems a bit trivial at times.

Focus in most UI systems is handled by a focus root which can hold
only one focused component at a given time in LWUIT this root is a
Form, unlike a typical windowing system only one form can be shown at
a time.

In a typical Windowing system a window is a focus root, so you may
have two application windows open simultaneously and thus two
components would have focus at a given time.

In LWUIT this is theoretically possible if you call onto a form which
is not visible (which is what you are experiencing).

Technically you have no focus, the dialog is a form and neither one
of these is focused since they are containers and containers don't
grab focus.

If your dialog has a focusable component within it then it will grab
focus.

When a dialog is rendered you see the previous form in the
background, but this form isn't the current form and for all intents
and purposes its focus is irrelevant since it won't get any events.
The background drawing of the form is performed by the dialogs
background painter and is really a "drawing" and not the actual
underlying form appearing in the background...

I'm not exactly clear on the problem you are having with focus, so I
can't think of how to help this further.

I hope its clear why I don't consider the fact that two components
(under different focus roots) have focus in the same time to be a bug.

Thanks,
Shai.

> I would like to change the question since I figure the "focus" is not
> relevant to my requirement since it is a property for a component
> or an
> item. Only focusable one could have focus. It is nothing to do with
> visible or not.
>
> On the other hand, I could see a list form behind a dialog is still
> visible or isVisible() returns true. Not sure if this if is intended
> design.
>
> I do realise there is manual control to setEnabled() to true/false,
> which could be used to satisfy my requirement.
>
> Thanks,
>
> Qunhuan
>
> -----Original Message-----
> From: Qunhuan Mei [mailto:qunhuan.mei@mfuse.com]
> Sent: 11 June 2008 11:31
> To: users@lwuit.dev.java.net
> Subject: Is it a bug - the last component shown does not always have
> focus? + Re: Can we change a dialog's size?
>
> Greetings again!
>
> I first displayed a customised list form which has some specific
> animation. Then a click to a list item triggers a dialog form. I was
> hoping to use hasFocus() to stop the animation on the list form
> since I
> guess the focus has moved from list form to the dialog one.
>
> To my surprise, the dialog's hasFocus() always returns false, and the
> list's hasFocus() always returns true.
>
> Is this a bug since I would assume the last component shown will
> always
> have focus?
>
> Thanks,
>
> Qunhuan
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Shai, I was off work yesterday. Many thanks for your detailed
> explanation. It helped.
>
>
> -----Original Message-----
> From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
> Sent: 09 June 2008 17:03
> To: users@lwuit.dev.java.net
> Subject: Re: Can we change a dialog's size?
>
> Hi Qunhuan,
> thanks for reminding me to update the dialog javadocs...
> Since a dialog is a form the preferred size will have no effect on
> it, both forms and dialogs always take over the entire screen...
> A dialog physically controls the entire screen size, but using a
> special painter draws the previous form in the background (tinted).
>
> To control the positioning of the dialog use the version of show that
> accepts 4 integer values: show(int, int, int, int);
>
> Unlike most API's of this sort it accepts the margins to position the
> dialog (space from edges) e.g.:
> Dialog.show(11, 12, 13, 14);
> Will show a dialog 11 pixels from the top, 12 from the bottom, 13
> from the left and 14 from the right.
>
> The logic here is that usually you would position a dialog based on
> space from every direction rather than absolutely in the screen so
> while this is different from convention it is very similar to our
> design sensibilities.
>
> Notice that to apply elements to the dialog (such as background image
> etc.) you would usually use the dialog content pane rather than the
> dialog itself... Since the dialog occupies the entire screen yet its
> content pane does not.
>
> Thanks,
> Shai.
>
>> I was trying to setPreferredSize for a Dialog. But all efforts
>> (e.g. instantiate one and set its size then show it or extend one
>> and set its size and show it) failed. Is a Dialog's size fixed or
>> how can I change it?
>>
>> Thanks,
>>
>> Qunhuan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

> My actual use case here is that I have two components, one is a list
> form, the other is a dialog. Both has been customised.
>
> The list form has some specific animations. When one item is
> clicked, it
> triggers the dialog to be displayed (the "dialog" also has its own
> animation).
>
> Currently after this dialog is displayed, the animation on list still
> continues and is visible in tinted area. I am looking for a flag from
> List class to be used to automatically stop the list animation. But
> seems to me neither isEnabled(), nor isVisible() from the list returns
> the value I would expected after the dialog is displayed. Thought
> once
> the list form is covered by a dialog form, list.isVisible() or
> list.isEnabled() would return false. So it looks the only way out
> at the
> moment is to use manual control instead of an automatic one.

Do you get calls to the animate() method when the dialog is displayed?
animate() should never be called when a different form is displayed
so if animate() is invoked when your form is covered this is a bug.

Did you implement the whole Dialog class as an animation?
E.g.:
Dialog myDialog = new MyDialogClass();
myDialog.registerAnimated(myDialog);

This could be inefficient since it might cause the whole dialog to be
repainted without there being a need (necessarily).

If you only want to effect the dialog content you should probably
extend container register it on the parent dialog. You would then
place all content within that container and it would be the only
portion being repainted. Since repaint in the background won't occur
neither would the background animation.

Assuming you get calls to animate() of the parent form, place a
breakpoint in that method and check the callstack. Check which form
instance calls the animation and verify whether its the dialog...
Assuming it is the dialog that is triggering animation, check whether
you registered animation in the dialog. (you can override
registerAnimation and place a breakpoint into it).

Thanks,
Shai.

>
> Many thanks,
>
> Qunhuan
>
>
> -----Original Message-----
> From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
> Sent: 11 June 2008 15:04
> To: users@lwuit.dev.java.net
> Subject: Re: Is it a bug - the last component shown does not always
> have
> focus? + Re: Can we change a dialog's size?
>
> Hi Qunhuan,
> Focus is a rather complex issue so please forgive me if the
> explanation seems a bit trivial at times.
>
> Focus in most UI systems is handled by a focus root which can hold
> only one focused component at a given time in LWUIT this root is a
> Form, unlike a typical windowing system only one form can be shown at
> a time.
>
> In a typical Windowing system a window is a focus root, so you may
> have two application windows open simultaneously and thus two
> components would have focus at a given time.
>
> In LWUIT this is theoretically possible if you call onto a form which
> is not visible (which is what you are experiencing).
>
> Technically you have no focus, the dialog is a form and neither one
> of these is focused since they are containers and containers don't
> grab focus.
>
> If your dialog has a focusable component within it then it will grab
> focus.
>
> When a dialog is rendered you see the previous form in the
> background, but this form isn't the current form and for all intents
> and purposes its focus is irrelevant since it won't get any events.
> The background drawing of the form is performed by the dialogs
> background painter and is really a "drawing" and not the actual
> underlying form appearing in the background...
>
> I'm not exactly clear on the problem you are having with focus, so I
> can't think of how to help this further.
>
> I hope its clear why I don't consider the fact that two components
> (under different focus roots) have focus in the same time to be a bug.
>
> Thanks,
> Shai.
>
>
>
>> I would like to change the question since I figure the "focus" is not
>> relevant to my requirement since it is a property for a component
>> or an
>> item. Only focusable one could have focus. It is nothing to do with
>> visible or not.
>>
>> On the other hand, I could see a list form behind a dialog is still
>> visible or isVisible() returns true. Not sure if this if is intended
>> design.
>>
>> I do realise there is manual control to setEnabled() to true/false,
>> which could be used to satisfy my requirement.
>>
>> Thanks,
>>
>> Qunhuan
>>
>> -----Original Message-----
>> From: Qunhuan Mei [mailto:qunhuan.mei@mfuse.com]
>> Sent: 11 June 2008 11:31
>> To: users@lwuit.dev.java.net
>> Subject: Is it a bug - the last component shown does not always have
>> focus? + Re: Can we change a dialog's size?
>>
>> Greetings again!
>>
>> I first displayed a customised list form which has some specific
>> animation. Then a click to a list item triggers a dialog form. I was
>> hoping to use hasFocus() to stop the animation on the list form
>> since I
>> guess the focus has moved from list form to the dialog one.
>>
>> To my surprise, the dialog's hasFocus() always returns false, and the
>> list's hasFocus() always returns true.
>>
>> Is this a bug since I would assume the last component shown will
>> always
>> have focus?
>>
>> Thanks,
>>
>> Qunhuan
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Shai, I was off work yesterday. Many thanks for your detailed
>> explanation. It helped.
>>
>>
>> -----Original Message-----
>> From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
>> Sent: 09 June 2008 17:03
>> To: users@lwuit.dev.java.net
>> Subject: Re: Can we change a dialog's size?
>>
>> Hi Qunhuan,
>> thanks for reminding me to update the dialog javadocs...
>> Since a dialog is a form the preferred size will have no effect on
>> it, both forms and dialogs always take over the entire screen...
>> A dialog physically controls the entire screen size, but using a
>> special painter draws the previous form in the background (tinted).
>>
>> To control the positioning of the dialog use the version of show that
>> accepts 4 integer values: show(int, int, int, int);
>>
>> Unlike most API's of this sort it accepts the margins to position the
>> dialog (space from edges) e.g.:
>> Dialog.show(11, 12, 13, 14);
>> Will show a dialog 11 pixels from the top, 12 from the bottom, 13
>> from the left and 14 from the right.
>>
>> The logic here is that usually you would position a dialog based on
>> space from every direction rather than absolutely in the screen so
>> while this is different from convention it is very similar to our
>> design sensibilities.
>>
>> Notice that to apply elements to the dialog (such as background image
>> etc.) you would usually use the dialog content pane rather than the
>> dialog itself... Since the dialog occupies the entire screen yet its
>> content pane does not.
>>
>> Thanks,
>> Shai.
>>
>>> I was trying to setPreferredSize for a Dialog. But all efforts
>>> (e.g. instantiate one and set its size then show it or extend one
>>> and set its size and show it) failed. Is a Dialog's size fixed or
>>> how can I change it?
>>>
>>> Thanks,
>>>
>>> Qunhuan
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

> My actual use case here is that I have two components, one is a list
> form, the other is a dialog. Both has been customised.
>
> The list form has some specific animations. When one item is
> clicked, it
> triggers the dialog to be displayed (the "dialog" also has its own
> animation).
>
> Currently after this dialog is displayed, the animation on list still
> continues and is visible in tinted area. I am looking for a flag from
> List class to be used to automatically stop the list animation. But
> seems to me neither isEnabled(), nor isVisible() from the list returns
> the value I would expected after the dialog is displayed. Thought
> once
> the list form is covered by a dialog form, list.isVisible() or
> list.isEnabled() would return false. So it looks the only way out
> at the
> moment is to use manual control instead of an automatic one.

Do you get calls to the animate() method when the dialog is displayed?
animate() should never be called when a different form is displayed
so if animate() is invoked when your form is covered this is a bug.

##### animate() is only called in myDialogForm if I call
registerAnimationed(...)

Did you implement the whole Dialog class as an animation?
E.g.:
Dialog myDialog = new MyDialogClass();
myDialog.registerAnimated(myDialog);

##### I actually implemented my own dialog class by "extends Dialog".
The main reason to use dialog is I can then use "tinted" background.
Since I need animation so registerAnimated() is called.

This could be inefficient since it might cause the whole dialog to be
repainted without there being a need (necessarily).

##### But I am taking over the paint method so the tinted area should
not be repainted since I am not "touching" them in paint(),
theoretically!?

If you only want to effect the dialog content you should probably
extend container register it on the parent dialog. You would then
place all content within that container and it would be the only
portion being repainted. Since repaint in the background won't occur
neither would the background animation.

##### I would not like to create myDialogForm from scratch, without
extending Dialog I mean, since I want to avoid implementing "tinted"
part myself. From my example, looks both myListForm and myDialogForm
conexist on screen and two "layers" of animations are going on!

Assuming you get calls to animate() of the parent form, place a
breakpoint in that method and check the callstack. Check which form
instance calls the animation and verify whether its the dialog...
Assuming it is the dialog that is triggering animation, check whether
you registered animation in the dialog. (you can override
registerAnimation and place a breakpoint into it).

##### no animate() is called without calling registerAnimated() first -
tested!

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

Many thanks,

Qunhuan

>
> Many thanks,
>
> Qunhuan
>
>
> -----Original Message-----
> From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
> Sent: 11 June 2008 15:04
> To: users@lwuit.dev.java.net
> Subject: Re: Is it a bug - the last component shown does not always
> have
> focus? + Re: Can we change a dialog's size?
>
> Hi Qunhuan,
> Focus is a rather complex issue so please forgive me if the
> explanation seems a bit trivial at times.
>
> Focus in most UI systems is handled by a focus root which can hold
> only one focused component at a given time in LWUIT this root is a
> Form, unlike a typical windowing system only one form can be shown at
> a time.
>
> In a typical Windowing system a window is a focus root, so you may
> have two application windows open simultaneously and thus two
> components would have focus at a given time.
>
> In LWUIT this is theoretically possible if you call onto a form which
> is not visible (which is what you are experiencing).
>
> Technically you have no focus, the dialog is a form and neither one
> of these is focused since they are containers and containers don't
> grab focus.
>
> If your dialog has a focusable component within it then it will grab
> focus.
>
> When a dialog is rendered you see the previous form in the
> background, but this form isn't the current form and for all intents
> and purposes its focus is irrelevant since it won't get any events.
> The background drawing of the form is performed by the dialogs
> background painter and is really a "drawing" and not the actual
> underlying form appearing in the background...
>
> I'm not exactly clear on the problem you are having with focus, so I
> can't think of how to help this further.
>
> I hope its clear why I don't consider the fact that two components
> (under different focus roots) have focus in the same time to be a bug.
>
> Thanks,
> Shai.
>
>
>
>> I would like to change the question since I figure the "focus" is not
>> relevant to my requirement since it is a property for a component
>> or an
>> item. Only focusable one could have focus. It is nothing to do with
>> visible or not.
>>
>> On the other hand, I could see a list form behind a dialog is still
>> visible or isVisible() returns true. Not sure if this if is intended
>> design.
>>
>> I do realise there is manual control to setEnabled() to true/false,
>> which could be used to satisfy my requirement.
>>
>> Thanks,
>>
>> Qunhuan
>>
>> -----Original Message-----
>> From: Qunhuan Mei [mailto:qunhuan.mei@mfuse.com]
>> Sent: 11 June 2008 11:31
>> To: users@lwuit.dev.java.net
>> Subject: Is it a bug - the last component shown does not always have
>> focus? + Re: Can we change a dialog's size?
>>
>> Greetings again!
>>
>> I first displayed a customised list form which has some specific
>> animation. Then a click to a list item triggers a dialog form. I was
>> hoping to use hasFocus() to stop the animation on the list form
>> since I
>> guess the focus has moved from list form to the dialog one.
>>
>> To my surprise, the dialog's hasFocus() always returns false, and the
>> list's hasFocus() always returns true.
>>
>> Is this a bug since I would assume the last component shown will
>> always
>> have focus?
>>
>> Thanks,
>>
>> Qunhuan
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Shai, I was off work yesterday. Many thanks for your detailed
>> explanation. It helped.
>>
>>
>> -----Original Message-----
>> From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
>> Sent: 09 June 2008 17:03
>> To: users@lwuit.dev.java.net
>> Subject: Re: Can we change a dialog's size?
>>
>> Hi Qunhuan,
>> thanks for reminding me to update the dialog javadocs...
>> Since a dialog is a form the preferred size will have no effect on
>> it, both forms and dialogs always take over the entire screen...
>> A dialog physically controls the entire screen size, but using a
>> special painter draws the previous form in the background (tinted).
>>
>> To control the positioning of the dialog use the version of show that
>> accepts 4 integer values: show(int, int, int, int);
>>
>> Unlike most API's of this sort it accepts the margins to position the
>> dialog (space from edges) e.g.:
>> Dialog.show(11, 12, 13, 14);
>> Will show a dialog 11 pixels from the top, 12 from the bottom, 13
>> from the left and 14 from the right.
>>
>> The logic here is that usually you would position a dialog based on
>> space from every direction rather than absolutely in the screen so
>> while this is different from convention it is very similar to our
>> design sensibilities.
>>
>> Notice that to apply elements to the dialog (such as background image
>> etc.) you would usually use the dialog content pane rather than the
>> dialog itself... Since the dialog occupies the entire screen yet its
>> content pane does not.
>>
>> Thanks,
>> Shai.
>>
>>> I was trying to setPreferredSize for a Dialog. But all efforts
>>> (e.g. instantiate one and set its size then show it or extend one
>>> and set its size and show it) failed. Is a Dialog's size fixed or
>>> how can I change it?
>>>
>>> Thanks,
>>>
>>> Qunhuan
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

Hi Qunhuan,
>
> ##### animate() is only called in myDialogForm if I call
> registerAnimationed(...)

Thats correct, but that would also mean that the parent Form's
animate method isn't called which is what I meant e.g. :

class MyAnimatedForm extends Form {
//...
}

class MyAnimatedDialog extends Dialog {
//...
}

When MyAnimatedDialog is showing on top of MyAnimatedForm the animate
() method of MyAnimatedDialog will be the only one called. The
animate method of MyAnimatedForm shouldn't be called UNLESS
MyAnimatedForm was registered with MyAnimatedDialog...

> ##### But I am taking over the paint method so the tinted area should
> not be repainted since I am not "touching" them in paint(),
> theoretically!?

Not quite...

What determines the areas painted is calls to repaint(), essentially
someone somewhere is repainting your form.
The tinted background is drawn internally before paint gets called so
your overriding of paint() won't change much there.

This will only trigger a repaint of the internal portion of the dialog.

> ##### no animate() is called without calling registerAnimated()
> first -
> tested!

Please confirm that this is the animate of the parent form that is
invoked rather than the animate of the child, if so please check in
the stack to see where it came from.
You can see a member within the Form which indicates the registered
animators and their affect, its possible that something registered
itself into the dialog instead of into the form and is causing a
refresh in the form. Look at the Form calling animate in debugging
and at the "animatableComponents" vector to identify who called
animate().

Thanks,
Shai.

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Many thanks,
>
> Qunhuan
>
>>
>> Many thanks,
>>
>> Qunhuan
>>
>>
>> -----Original Message-----
>> From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
>> Sent: 11 June 2008 15:04
>> To: users@lwuit.dev.java.net
>> Subject: Re: Is it a bug - the last component shown does not always
>> have
>> focus? + Re: Can we change a dialog's size?
>>
>> Hi Qunhuan,
>> Focus is a rather complex issue so please forgive me if the
>> explanation seems a bit trivial at times.
>>
>> Focus in most UI systems is handled by a focus root which can hold
>> only one focused component at a given time in LWUIT this root is a
>> Form, unlike a typical windowing system only one form can be shown at
>> a time.
>>
>> In a typical Windowing system a window is a focus root, so you may
>> have two application windows open simultaneously and thus two
>> components would have focus at a given time.
>>
>> In LWUIT this is theoretically possible if you call onto a form which
>> is not visible (which is what you are experiencing).
>>
>> Technically you have no focus, the dialog is a form and neither one
>> of these is focused since they are containers and containers don't
>> grab focus.
>>
>> If your dialog has a focusable component within it then it will grab
>> focus.
>>
>> When a dialog is rendered you see the previous form in the
>> background, but this form isn't the current form and for all intents
>> and purposes its focus is irrelevant since it won't get any events.
>> The background drawing of the form is performed by the dialogs
>> background painter and is really a "drawing" and not the actual
>> underlying form appearing in the background...
>>
>> I'm not exactly clear on the problem you are having with focus, so I
>> can't think of how to help this further.
>>
>> I hope its clear why I don't consider the fact that two components
>> (under different focus roots) have focus in the same time to be a
>> bug.
>>
>> Thanks,
>> Shai.
>>
>>
>>
>>> I would like to change the question since I figure the "focus" is
>>> not
>>> relevant to my requirement since it is a property for a component
>>> or an
>>> item. Only focusable one could have focus. It is nothing to do with
>>> visible or not.
>>>
>>> On the other hand, I could see a list form behind a dialog is still
>>> visible or isVisible() returns true. Not sure if this if is intended
>>> design.
>>>
>>> I do realise there is manual control to setEnabled() to true/false,
>>> which could be used to satisfy my requirement.
>>>
>>> Thanks,
>>>
>>> Qunhuan
>>>
>>> -----Original Message-----
>>> From: Qunhuan Mei [mailto:qunhuan.mei@mfuse.com]
>>> Sent: 11 June 2008 11:31
>>> To: users@lwuit.dev.java.net
>>> Subject: Is it a bug - the last component shown does not always have
>>> focus? + Re: Can we change a dialog's size?
>>>
>>> Greetings again!
>>>
>>> I first displayed a customised list form which has some specific
>>> animation. Then a click to a list item triggers a dialog form. I was
>>> hoping to use hasFocus() to stop the animation on the list form
>>> since I
>>> guess the focus has moved from list form to the dialog one.
>>>
>>> To my surprise, the dialog's hasFocus() always returns false, and
>>> the
>>> list's hasFocus() always returns true.
>>>
>>> Is this a bug since I would assume the last component shown will
>>> always
>>> have focus?
>>>
>>> Thanks,
>>>
>>> Qunhuan
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Shai, I was off work yesterday. Many thanks for your detailed
>>> explanation. It helped.
>>>
>>>
>>> -----Original Message-----
>>> From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
>>> Sent: 09 June 2008 17:03
>>> To: users@lwuit.dev.java.net
>>> Subject: Re: Can we change a dialog's size?
>>>
>>> Hi Qunhuan,
>>> thanks for reminding me to update the dialog javadocs...
>>> Since a dialog is a form the preferred size will have no effect on
>>> it, both forms and dialogs always take over the entire screen...
>>> A dialog physically controls the entire screen size, but using a
>>> special painter draws the previous form in the background (tinted).
>>>
>>> To control the positioning of the dialog use the version of show
>>> that
>>> accepts 4 integer values: show(int, int, int, int);
>>>
>>> Unlike most API's of this sort it accepts the margins to position
>>> the
>>> dialog (space from edges) e.g.:
>>> Dialog.show(11, 12, 13, 14);
>>> Will show a dialog 11 pixels from the top, 12 from the bottom, 13
>>> from the left and 14 from the right.
>>>
>>> The logic here is that usually you would position a dialog based on
>>> space from every direction rather than absolutely in the screen so
>>> while this is different from convention it is very similar to our
>>> design sensibilities.
>>>
>>> Notice that to apply elements to the dialog (such as background
>>> image
>>> etc.) you would usually use the dialog content pane rather than the
>>> dialog itself... Since the dialog occupies the entire screen yet its
>>> content pane does not.
>>>
>>> Thanks,
>>> Shai.
>>>
>>>> I was trying to setPreferredSize for a Dialog. But all efforts
>>>> (e.g. instantiate one and set its size then show it or extend one
>>>> and set its size and show it) failed. Is a Dialog's size fixed or
>>>> how can I change it?
>>>>
>>>> Thanks,
>>>>
>>>> Qunhuan
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

1. Animate() should not be called without calling
registerAnimated(this) here
2. Even when current dialog form's animate() returns true, the
background form's paint() should not be called

Am I right?

Many thanks,

Qunhuan

-----Original Message-----
From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
Sent: 11 June 2008 17:26
To: users@lwuit.dev.java.net
Subject: Re: Is it a bug - the last component shown does not always have
focus? + Re: Can we change a dialog's size?

Hi Qunhuan,
>
> ##### animate() is only called in myDialogForm if I call
> registerAnimationed(...)

Thats correct, but that would also mean that the parent Form's
animate method isn't called which is what I meant e.g. :

class MyAnimatedForm extends Form {
//...
}

class MyAnimatedDialog extends Dialog {
//...
}

When MyAnimatedDialog is showing on top of MyAnimatedForm the animate
() method of MyAnimatedDialog will be the only one called. The
animate method of MyAnimatedForm shouldn't be called UNLESS
MyAnimatedForm was registered with MyAnimatedDialog...

> ##### But I am taking over the paint method so the tinted area should
> not be repainted since I am not "touching" them in paint(),
> theoretically!?

Not quite...

What determines the areas painted is calls to repaint(), essentially
someone somewhere is repainting your form.
The tinted background is drawn internally before paint gets called so
your overriding of paint() won't change much there.

This will only trigger a repaint of the internal portion of the dialog.

> ##### no animate() is called without calling registerAnimated()
> first -
> tested!

Please confirm that this is the animate of the parent form that is
invoked rather than the animate of the child, if so please check in
the stack to see where it came from.
You can see a member within the Form which indicates the registered
animators and their affect, its possible that something registered
itself into the dialog instead of into the form and is causing a
refresh in the form. Look at the Form calling animate in debugging
and at the "animatableComponents" vector to identify who called
animate().

Thanks,
Shai.

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Many thanks,
>
> Qunhuan
>
>>
>> Many thanks,
>>
>> Qunhuan
>>
>>
>> -----Original Message-----
>> From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
>> Sent: 11 June 2008 15:04
>> To: users@lwuit.dev.java.net
>> Subject: Re: Is it a bug - the last component shown does not always
>> have
>> focus? + Re: Can we change a dialog's size?
>>
>> Hi Qunhuan,
>> Focus is a rather complex issue so please forgive me if the
>> explanation seems a bit trivial at times.
>>
>> Focus in most UI systems is handled by a focus root which can hold
>> only one focused component at a given time in LWUIT this root is a
>> Form, unlike a typical windowing system only one form can be shown at
>> a time.
>>
>> In a typical Windowing system a window is a focus root, so you may
>> have two application windows open simultaneously and thus two
>> components would have focus at a given time.
>>
>> In LWUIT this is theoretically possible if you call onto a form which
>> is not visible (which is what you are experiencing).
>>
>> Technically you have no focus, the dialog is a form and neither one
>> of these is focused since they are containers and containers don't
>> grab focus.
>>
>> If your dialog has a focusable component within it then it will grab
>> focus.
>>
>> When a dialog is rendered you see the previous form in the
>> background, but this form isn't the current form and for all intents
>> and purposes its focus is irrelevant since it won't get any events.
>> The background drawing of the form is performed by the dialogs
>> background painter and is really a "drawing" and not the actual
>> underlying form appearing in the background...
>>
>> I'm not exactly clear on the problem you are having with focus, so I
>> can't think of how to help this further.
>>
>> I hope its clear why I don't consider the fact that two components
>> (under different focus roots) have focus in the same time to be a
>> bug.
>>
>> Thanks,
>> Shai.
>>
>>
>>
>>> I would like to change the question since I figure the "focus" is
>>> not
>>> relevant to my requirement since it is a property for a component
>>> or an
>>> item. Only focusable one could have focus. It is nothing to do with
>>> visible or not.
>>>
>>> On the other hand, I could see a list form behind a dialog is still
>>> visible or isVisible() returns true. Not sure if this if is intended
>>> design.
>>>
>>> I do realise there is manual control to setEnabled() to true/false,
>>> which could be used to satisfy my requirement.
>>>
>>> Thanks,
>>>
>>> Qunhuan
>>>
>>> -----Original Message-----
>>> From: Qunhuan Mei [mailto:qunhuan.mei@mfuse.com]
>>> Sent: 11 June 2008 11:31
>>> To: users@lwuit.dev.java.net
>>> Subject: Is it a bug - the last component shown does not always have
>>> focus? + Re: Can we change a dialog's size?
>>>
>>> Greetings again!
>>>
>>> I first displayed a customised list form which has some specific
>>> animation. Then a click to a list item triggers a dialog form. I was
>>> hoping to use hasFocus() to stop the animation on the list form
>>> since I
>>> guess the focus has moved from list form to the dialog one.
>>>
>>> To my surprise, the dialog's hasFocus() always returns false, and
>>> the
>>> list's hasFocus() always returns true.
>>>
>>> Is this a bug since I would assume the last component shown will
>>> always
>>> have focus?
>>>
>>> Thanks,
>>>
>>> Qunhuan
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Shai, I was off work yesterday. Many thanks for your detailed
>>> explanation. It helped.
>>>
>>>
>>> -----Original Message-----
>>> From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
>>> Sent: 09 June 2008 17:03
>>> To: users@lwuit.dev.java.net
>>> Subject: Re: Can we change a dialog's size?
>>>
>>> Hi Qunhuan,
>>> thanks for reminding me to update the dialog javadocs...
>>> Since a dialog is a form the preferred size will have no effect on
>>> it, both forms and dialogs always take over the entire screen...
>>> A dialog physically controls the entire screen size, but using a
>>> special painter draws the previous form in the background (tinted).
>>>
>>> To control the positioning of the dialog use the version of show
>>> that
>>> accepts 4 integer values: show(int, int, int, int);
>>>
>>> Unlike most API's of this sort it accepts the margins to position
>>> the
>>> dialog (space from edges) e.g.:
>>> Dialog.show(11, 12, 13, 14);
>>> Will show a dialog 11 pixels from the top, 12 from the bottom, 13
>>> from the left and 14 from the right.
>>>
>>> The logic here is that usually you would position a dialog based on
>>> space from every direction rather than absolutely in the screen so
>>> while this is different from convention it is very similar to our
>>> design sensibilities.
>>>
>>> Notice that to apply elements to the dialog (such as background
>>> image
>>> etc.) you would usually use the dialog content pane rather than the
>>> dialog itself... Since the dialog occupies the entire screen yet its
>>> content pane does not.
>>>
>>> Thanks,
>>> Shai.
>>>
>>>> I was trying to setPreferredSize for a Dialog. But all efforts
>>>> (e.g. instantiate one and set its size then show it or extend one
>>>> and set its size and show it) failed. Is a Dialog's size fixed or
>>>> how can I change it?
>>>>
>>>> Thanks,
>>>>
>>>> Qunhuan
>>>
>>>
>>> --------------------------------------------------------------------

Hi Qunhuan,
there seems to be an issue in LWUIT where smooth scrolling in the
container (which is on by default) registers an animation.
I don't think this is necessary and if Chen concurs we can remove
this but the change is not so simple since it exposes a different
regression.

> 1. Animate() should not be called without calling
> registerAnimated(this) here

Agreed.
animate will be called "implicitly" in some cases:
1. If you placed an animation in the bgImage (which you didn't).
2. If you used a dialog timeout (which you didn't).

Other than that it shouldn't be called, we will try to fix this issue
for the next release.
I tried to prepare a workaround but it seems to fail, this might be a
bit difficult to fix...

> 2. Even when current dialog form's animate() returns true, the
> background form's paint() should not be called

No, thats not the case.
Since a dialog controls the entire screen (overriding the dialogs
paint method will allow you to draw over the tinted area too)
returning true from a dialogs animate() method will repaint the
background form as well. The reasoning is simple: We allow changing
tint etc. we also allow layering dialogs (in different positions). To
do that we would need a rather elaborate (and costly) memory
screenshot or simply to repaint the background form (which is the
other choice).
If you want to animate only the content of the dialog then just stick
an animated component into the content pane.

I would like to change the question since I figure the "focus" is not
relevant to my requirement since it is a property for a component or an
item. Only focusable one could have focus. It is nothing to do with
visible or not.

On the other hand, I could see a list form behind a dialog is still
visible or isVisible() returns true. Not sure if this if is intended
design.

I do realise there is manual control to setEnabled() to true/false,
which could be used to satisfy my requirement.

Thanks,

Qunhuan

-----Original Message-----
From: Qunhuan Mei [mailto:qunhuan.mei@mfuse.com]
Sent: 11 June 2008 11:31
To: users@lwuit.dev.java.net
Subject: Is it a bug - the last component shown does not always have
focus? + Re: Can we change a dialog's size?

Greetings again!

I first displayed a customised list form which has some specific
animation. Then a click to a list item triggers a dialog form. I was
hoping to use hasFocus() to stop the animation on the list form since I
guess the focus has moved from list form to the dialog one.

Hi Qunhuan,
thanks for reminding me to update the dialog javadocs...
Since a dialog is a form the preferred size will have no effect on
it, both forms and dialogs always take over the entire screen...
A dialog physically controls the entire screen size, but using a
special painter draws the previous form in the background (tinted).

To control the positioning of the dialog use the version of show that
accepts 4 integer values: show(int, int, int, int);

Unlike most API's of this sort it accepts the margins to position the
dialog (space from edges) e.g.:
Dialog.show(11, 12, 13, 14);
Will show a dialog 11 pixels from the top, 12 from the bottom, 13
from the left and 14 from the right.

The logic here is that usually you would position a dialog based on
space from every direction rather than absolutely in the screen so
while this is different from convention it is very similar to our
design sensibilities.

Notice that to apply elements to the dialog (such as background image
etc.) you would usually use the dialog content pane rather than the
dialog itself... Since the dialog occupies the entire screen yet its
content pane does not.

Thanks,
Shai.

> I was trying to setPreferredSize for a Dialog. But all efforts
> (e.g. instantiate one and set its size then show it or extend one
> and set its size and show it) failed. Is a Dialog's size fixed or
> how can I change it?
>
> Thanks,
>
> Qunhuan

At creation time I set the List model to modelA, then after some event is
fired and changeModel is called, I change it to modelB
(list.setModel(modelB).
What happens to the old modelA ? Is it discarded automatically? Should it be
a concern as for memory usage?

Hi Matteo,
Once you replace a list model we keep no reference in the List to the
data.
In fact we never cache data in the list so your model should be
pretty efficient!

Theoretically what you gave as an example should be OK in terms of
the list, but the models won't get GC'd because you keep pointers to
them in MyList ;-)

A list model might be a memory hog depending on what you stick into
it, we found that typical business data doesn't occupy much memory in
Java (as long as you stay in the low hundreds) the main problem for
us was always in the image data. Since a list model can contain
arbitrary data (such as images) it can become very expensive.

You can technically map a model to the RMS, this is a demo we had in
an old version of the LWUIT demo (when its code name was even worse,
don't ask...). We removed this code because no one understood the
purpose of that demo, but Chen or myself will probably blog about
this in the near future since this is a difficult concept for many
developers.

Thanks,
Shai.

On Jun 11, 2008, at 4:10 PM, Matteo Mazzotti wrote:

> Hi again,
> This time I have a question concerning memory usage/optimization.
>
> Say I have a List like the ff:
>
> public MyList extends List{
> private final ListModel modelA = new DefaultListModel();
> private final ListModel modelB = new DefaultListModel();
>
> public MyList(){
> [modelA initialization here]
> this.setModel(modelA);
> }
>
> public changeModel(){
> [modelB init here]
> this.setModel(modelB);
> }
> }
>
> At creation time I set the List model to modelA, then after some
> event is
> fired and changeModel is called, I change it to modelB
> (list.setModel(modelB).
> What happens to the old modelA ? Is it discarded automatically?
> Should it be
> a concern as for memory usage?
>
> Thanks
> Matteo
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

I was trying to setPreferredSize for a Dialog. But all efforts (e.g. instantiate one and set its size then show it or extend one and set its size and show it) failed. Is a Dialogâ€™s size fixed or how can I change it?

Hi Qunhuan,
thanks for reminding me to update the dialog javadocs...
Since a dialog is a form the preferred size will have no effect on
it, both forms and dialogs always take over the entire screen...
A dialog physically controls the entire screen size, but using a
special painter draws the previous form in the background (tinted).

To control the positioning of the dialog use the version of show that
accepts 4 integer values: show(int, int, int, int);

Unlike most API's of this sort it accepts the margins to position the
dialog (space from edges) e.g.:
Dialog.show(11, 12, 13, 14);
Will show a dialog 11 pixels from the top, 12 from the bottom, 13
from the left and 14 from the right.

The logic here is that usually you would position a dialog based on
space from every direction rather than absolutely in the screen so
while this is different from convention it is very similar to our
design sensibilities.

Notice that to apply elements to the dialog (such as background image
etc.) you would usually use the dialog content pane rather than the
dialog itself... Since the dialog occupies the entire screen yet its
content pane does not.

Thanks,
Shai.

> I was trying to setPreferredSize for a Dialog. But all efforts
> (e.g. instantiate one and set its size then show it or extend one
> and set its size and show it) failed. Is a Dialogâ€™s size fixed or
> how can I change it?
>
> Thanks,
>
> Qunhuan

I first displayed a customised list form which has some specific
animation. Then a click to a list item triggers a dialog form. I was
hoping to use hasFocus() to stop the animation on the list form since I
guess the focus has moved from list form to the dialog one.

Hi Qunhuan,
thanks for reminding me to update the dialog javadocs...
Since a dialog is a form the preferred size will have no effect on
it, both forms and dialogs always take over the entire screen...
A dialog physically controls the entire screen size, but using a
special painter draws the previous form in the background (tinted).

To control the positioning of the dialog use the version of show that
accepts 4 integer values: show(int, int, int, int);

Unlike most API's of this sort it accepts the margins to position the
dialog (space from edges) e.g.:
Dialog.show(11, 12, 13, 14);
Will show a dialog 11 pixels from the top, 12 from the bottom, 13
from the left and 14 from the right.

The logic here is that usually you would position a dialog based on
space from every direction rather than absolutely in the screen so
while this is different from convention it is very similar to our
design sensibilities.

Notice that to apply elements to the dialog (such as background image
etc.) you would usually use the dialog content pane rather than the
dialog itself... Since the dialog occupies the entire screen yet its
content pane does not.

Thanks,
Shai.

> I was trying to setPreferredSize for a Dialog. But all efforts
> (e.g. instantiate one and set its size then show it or extend one
> and set its size and show it) failed. Is a Dialog's size fixed or
> how can I change it?
>
> Thanks,
>
> Qunhuan

Hi Qunhuan,
A Dialog is basically a Form(it extends Form), so when you show a dialog
the current Form is being disposed and the Dialog is being shown with
just a tinted background of the previous Form.
If you want to discover when a Dialog is shown or disposed you can
override the methods *protected void onShow() or public void dispose(){
super.dispose();
//your code...
}*

Regards,
Chen

Qunhuan Mei wrote:
> Greetings again!
>
> I first displayed a customised list form which has some specific
> animation. Then a click to a list item triggers a dialog form. I was
> hoping to use hasFocus() to stop the animation on the list form since I
> guess the focus has moved from list form to the dialog one.
>
> To my surprise, the dialog's hasFocus() always returns false, and the
> list's hasFocus() always returns true.
>
> Is this a bug since I would assume the last component shown will always
> have focus?
>
> Thanks,
>
> Qunhuan
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Shai, I was off work yesterday. Many thanks for your detailed
> explanation. It helped.
>
>
> -----Original Message-----
> From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
> Sent: 09 June 2008 17:03
> To: users@lwuit.dev.java.net
> Subject: Re: Can we change a dialog's size?
>
> Hi Qunhuan,
> thanks for reminding me to update the dialog javadocs...
> Since a dialog is a form the preferred size will have no effect on
> it, both forms and dialogs always take over the entire screen...
> A dialog physically controls the entire screen size, but using a
> special painter draws the previous form in the background (tinted).
>
> To control the positioning of the dialog use the version of show that
> accepts 4 integer values: show(int, int, int, int);
>
> Unlike most API's of this sort it accepts the margins to position the
> dialog (space from edges) e.g.:
> Dialog.show(11, 12, 13, 14);
> Will show a dialog 11 pixels from the top, 12 from the bottom, 13
> from the left and 14 from the right.
>
> The logic here is that usually you would position a dialog based on
> space from every direction rather than absolutely in the screen so
> while this is different from convention it is very similar to our
> design sensibilities.
>
> Notice that to apply elements to the dialog (such as background image
> etc.) you would usually use the dialog content pane rather than the
> dialog itself... Since the dialog occupies the entire screen yet its
> content pane does not.
>
> Thanks,
> Shai.
>
>
>> I was trying to setPreferredSize for a Dialog. But all efforts
>> (e.g. instantiate one and set its size then show it or extend one
>> and set its size and show it) failed. Is a Dialog's size fixed or
>> how can I change it?
>>
>> Thanks,
>>
>> Qunhuan
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>

Hi,
The best approach would be not to hold all objects in memory that might
occupy heap(such as lwuit Forms), therefore all you need to do is simply
remove any class members that points to the Forms you are not using.

Hi,
You can have as many forms as you wish, what we usually do to keep the
heap from exceeding is we keep a reference to the application's "main
screens"(usually ~1-3).
Then if you need to switch from one of the "main screens" to another
form, you create the form only when you need to switch to that form and
when you are finished with it you drop the reference to that form.