[LWUIT-491] Compilation error in 'desktop' project of resource editor generated code Created: 30/Nov/11  Updated: 01/Dec/11  Resolved: 01/Dec/11

Status: Resolved
Project: lwuit
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: vimald Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

operating system: all


Attachments: PNG File error.png    
Tags: lwuit, resource_editor

 Description   

I am using the Resource Editor version 1.5, build 1587.

For any project netbeans generated using Resource Editor, there is a minor compilation error in the 'Desktop' version of the code. The bug is in class 'Main' within the method '_public static void main(String[] args)

{...}_', the "bq _java.awt.EventQueue.invokeLater(){...}

" anonymous class declaration is NOT ended with ');' at _line number 45 in the class.

I have attached the screenshot of the error with this issue.



 Comments   
Comment by vprise [ 01/Dec/11 ]

Thanks. This is fixed in the resource editor source files but not in the binary yet





[LWUIT-481] Problem with virtual keyboard scrolling in BB LWUIT Created: 04/Oct/11  Updated: 20/Dec/11

Status: Open
Project: lwuit
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: varun Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

LWUIT Blackberry Port


Tags: lwuit

 Description   

I have done a j2me application when I port it to Blackberry using LWUIT framework I have a problem in virtual keyboard as it does not automatically scrolls because of which the user is unable to view what he is typing in the text field .

Can help me solve the issue.

Thanks



 Comments   
Comment by ajochems [ 20/Dec/11 ]

I am having big problems with this issue as well on the blackberry platform. Native BlackBerry functionality is that the field scrolls to a position just above the virtual keyboard. However if a solution based on a Dialog with a TextField is an easier to implement solution it would be viable for me as well.





[LWUIT-480] exitForm() method is not getting called when user selects the back cmd Created: 01/Oct/11  Updated: 01/Oct/11

Status: Open
Project: lwuit
Component/s: None
Affects Version/s: milestone 1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: nj123 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All platforms


Tags: lwuit

 Description   

The exitForm(f) methods are not getting called when a form is exited as part of the back command.

For example, I have a form called Sample and I have overloaded the method exitSample(Form f).

However after displaying the Sample form, when I press the back command, the above exitSample method is not called before showing the previous form.



 Comments   
Comment by nj123 [ 01/Oct/11 ]

Further debugging with debugger shows that, in the back(Component) function in UIBuilder.java (svn rev: 1597) line no. 1740 checks for the key "FORM_STATE_KEY_CONTAINER" and if only it finds it true, then it calls the exitForm() method.

below that in the same function at line 1747, the code checks for the non-existence of the above key.

Please review this function and see if line no. 1740 should be changed to check for non-existence instead of existence?





[LWUIT-474] Table horizontal spanning rendered wrong while using setWidthPercentage Created: 23/Aug/11  Updated: 23/Aug/11

Status: Open
Project: lwuit
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: hajhet Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: lwuit, table

 Description   

I've been trying to render table with some horizontal spanning. This is how it should look like:

http://i.stack.imgur.com/CJ0lg.jpg

In LWUIT 1.4 everything worked correctly. Since 1.5 the table looks like:

http://i.stack.imgur.com/EBHBG.jpg

My implementation:

DefaultTableModel model = new DefaultTableModel(new String[]

{"", "", "", ""}

, new String[][]{

{"Header", null, null, null}

,

{"1", "2", "3", "4"},
{"1", "2", "3", "4"}

,
{"String", null, "String", null}});

Table tab = new Table(model, false) {

protected Component createCell(Object value, final int row, final int column, boolean editable)

{ Component c = super.createCell(value, row, column, editable); c.setFocusable(false); return c; }

protected TableLayout.Constraint createCellConstraint(java.lang.Object value, int row, int column) {
TableLayout.Constraint tlay = super.createCellConstraint(value, row, column);
if (row == 0 && column == 0)

{ tlay.setHorizontalSpan(4); tlay.setHorizontalAlign(Table.CENTER); }

else if (row == 3)) {
if (column == 0)

{ tlay.setHorizontalSpan(2); tlay.setWidthPercentage(50); } else if (column == 2) { tlay.setHorizontalSpan(2); tlay.setWidthPercentage(50); }

} else if (row != 0)

{ tlay.setWidthPercentage(25); }

return tlay;
}

};



 Comments   
Comment by hajhet [ 23/Aug/11 ]

It works better without setWidthPercentage(50). Table structure is well rendered, but width percentages are inexact.
http://stackoverflow.com/questions/7071417/lwuit-1-5-table-horizontal-spanning-problem





[LWUIT-429] Listen to soft keys on dialog/form Created: 13/Apr/11  Updated: 27/Apr/11  Resolved: 17/Apr/11

Status: Resolved
Project: lwuit
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: tempusername Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: Form, LWUIT, keys, soft

 Description   

Hi,

it is impossible to use the addKeyListener to detect soft key presses on dialogs/forms
since the keyReleased method in form calls the menubar if they detect soft key codes and does a return (even if there are no commands on the menubar.
In general i think the keyPressed/KeyReleased etc methods should return a boolean to know if the event was consumed or not thus allowing to continue propagate or not onwards.
We have our own UI lib that we build and we also did at first the mistake of not using a boolean on the return value, however this change might be too big atm for lwuit so perhaps the call the keylisteners at the start of the function or perhaps not doing a return.
i would also like to explain the underline cause to which we want to listen to soft keys.
we use dialogs to show the user ok/cancel questions etc and when the ok/cancel are used as soft keys they look a bit ugly and not connected to the actual dialog itself and its also not so friendly to touch devices. we saw there is a theme constant that allow the commands to be shown as buttons on the dialog but they dont respond to their relative soft keys to allow for both touch and non-touch devices to use it in intuitive manner so we tried adding our own buttons and using the keylistener to connect the soft keys to the buttons.

(sorry for the looooooooooooooong explanation)



 Comments   
Comment by vprise [ 17/Apr/11 ]

I'm marking this as fixed since I changed the behavior of commandsAsButtons to check the softbuttons internally and perform the command when a physical softbutton is pressed.

We have event.consume() the approach of returning false from a method is only practical for simpler API's that don't rely on the observer pattern. Even in this case its a problem since people need to be familiar with the call chain of event dispatch.

We don't expose softbuttons since we don't want people to "hack" them, they are a problematic none-portable concept. If you really want to get access to them you should replace the menu bar (which we now allow).

Comment by tempusername [ 27/Apr/11 ]

Hi,

Was this change committed? i updated my src two days ago and i dont think its working.

Comment by vprise [ 27/Apr/11 ]

Yes: Dialog.java lines 919-935





[LWUIT-428] screen size change listener Created: 13/Apr/11  Updated: 27/Apr/11  Resolved: 16/Apr/11

Status: Resolved
Project: lwuit
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: tempusername Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: Form, LWUIT, display, size

 Description   

Hi,

we have some forms that we place component center of the screen (by setting the margin of the container to be X percent from the screen width or height, as the margin values are absolute and not relative when the screen size gets change (like screen rotate) the values we used to do an absolute center (both vertical and horizontal) are no longer correct (and also other stuff like size of fonts maybe and size of components) but we dont know when the size changed as there is option in lwuit for us to listen to that event.
i think a size changed listener should be added and it should be called before the form sizeChangedInternal is called to allow us to do some re-calculations.



 Comments   
Comment by vprise [ 16/Apr/11 ]

The main problem is that size change is "flaky" at best, we handle it properly internally and allow a callback in Form for those who really know what they are doing. But it breaks often, mostly because of the very delicate order of reflows (adding more layout reflows will slow the UI and cause problems with things like growing text areas).
We need to allow margins/paddings in different units (its in my extensive TODO list).
However, for your particular use case you can use border layout and activate the absolute center flag to get that same effect.

Comment by tempusername [ 27/Apr/11 ]

i still think that notifying size has changed via a listener should be done because often you preload resources based on the screen resolution (fonts/icons etc) and in handsets like N95 which can switch from 240x320 to 320x240 you might want to switch full screen images from one to another (sure you can use lwuit resize image option but it would look as good as pre-loading a "good" image)

Comment by vprise [ 27/Apr/11 ]

We don't think that this use case is a good idea and don't want to encourage it. You can always derive Form and override the size changed callback, so this use case is supported just discouraged. If you are doing things like that manually, subclassing the Form is probably something you should do anyway.





Generated at Tue Dec 06 09:54:22 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.