Skip to main content

Few Suggestions

1 reply [Last post]
Joined: 2009-01-09


I have few suggestions that I would like to propose to be updated in LWUIT’s source code, since I’m finding it difficult to do it externally (extending classes and overriding methods…).

I believe they are general and everyone would benefit from them.

When softbutton’s transparency is less than 255, every time a menu or a Dialog is shown, the commands will be overlaid with the Form’s command. Two workarounds can be done to mitigate this.
i. Set the sofbutton’s transparency of all Dialogs and Menu to 255
ii. Temporary hide the Form’s commands while a Dialog or a Menu is shown

Give the option to show or not to show the error Dialog in the mainEDTLoop method. If u have an application in production, u wouldn’t want a pop screen to notify the user of internal errors.

Although TextAreas are only editable in the native Screen, it is intuitive to show a blinking cursor similar to a TextField, and whenever the user presses any key while focus is on the TextArea, it should automatically take him to the native screen for input.
It would be useful to set the variables MONTHS, DAYS, & LABELS to public.


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-11-07

Thanks for the suggestions.

1. Agreed we always suggest softbutton background should be opaque, this is theme related.
The second suggestion you had is interesting but rather complex to implement with nested dialogs etc.

2. This option exists although its well hidden, override the implementation and return true from handleEDTException.

3. This is pretty easy to accomplish by deriving text area. Its not as simple as it might sound to do it in a generic way e.g. we will need to have logic for cursor placement etc. which is not an easy task for multiline text area.
Also TextArea supports scrolling where a blinking cursor will pose a problem since people would expect it to move.

4. Why would making the calendar variables public be useful? For general application logic or interaction with the calendar?
These need to be internationalized anyway so they shouldn't be very useful for general application behavior.