1. The Command Layout Model
-
a MIDlet may explicitly control how a Displayable’s Commands are presented to the user when that Displayable is visible on a Display.
-
a MIDlet may choose to present a Displayable’s Commands individually or grouped into Menus.
-
a placement is a Display specific position which identifies a key, soft-key, or other interaction mechanism
with which a Command or Menu may be associated. -
a Display may have zero or more associated placements
-
the layout of a Displayable’s Commands requires the mapping of those Commands to a Display’s available placements, either directly or grouped into a Menu or Menus.
-
the explicit layout of a Displayable’s Commands is performed by an object which implements the
CommandLayoutPolicyinterface -
any Displayable, except for instances of FileSelector, may have an associated CommandLayoutPolicy object
-
any Display may have an associated CommandLayoutPolicy object
-
the layout of a Displayable’s Commands is only performed when a Displayable is associated with a Display
-
the layout of a Displayable’s Commands is only required when the current Command layout is invalid. This can occur, for example
-
if the Displayable has not previously been visible on a given Display
-
if the orientation of a Display changes while the Displayable is visible
-
if one or more placements associated with a Display become invalid while the Displayable is visible
-
if the Command layout has been explicitly invalidated
-
-
when layout of a Displayable’s Commands is required then
-
if the Displayable has an associated CommandLayoutPolicy object it will be used. If not then
-
if the Display has an associated CommandLayoutPolicy object it will be used. If not then
-
an implementation specific layout mechanism will be used.
-
-
if an Exception occurs during the use of a Displayable’s CommandLayoutPolicy object then
-
if the Display has an associated CommandLayoutPolicy object it will be used. If not then
-
an implementation specific layout mechanism will be used.
-
-
if an Exception occurs during the use of a Display’s CommandLayoutPolicy object then an
implementation specific layout mechanism will be used. -
a CommandLayoutPolicy object is responsible for the layout of all a Displayable’s Commands.
-
a Command will not be available to the user unless it is mapped to a placement or is a member of a Menu which itself is available to the user.
-
a Menu will not be available to the user unless it is mapped to a placement or is a sub-menu of a Menu which is itself available to the user.
-
-
if the Displayable is a Form then the Commands to be laid out can include those associated with Items in the Form.
-
if the Displayable is a TabbedPane then the Commands to be laid out can include those of the List or Form of the current Tab.
2. CommandLayoutPolicy
The CommandLayoutPolicy defines a single method.
public void onCommandLayout(Displayable displayable)
A CommandLayoutPolicy object’s onCommandLayout(Displayable) method will be called with the Displayable whose Commands are to be laid out.
Notes
-
The specification does not contain an explicit list of the circumstances under which this method will be called for a given Displayable, nor when it will be called relative to other events. For example, if an
onLayout(Displayable)method is called as the result of an orienatation change, when it is called relative to the Display orientation change event. -
The specification does not contain an explicit definition of the state of a Display’s placements when the
onLayout(Displayable)method is called, that is, whether Commands and/or Menus previously placed on the current Display by the Displayable are still present or whether all Commands and/or Menus must be explicitly placed each time the method is called. This makes implementing the method perhaps more interesting than it ought to be.The specification does say
Any Command or Menu not explicitly set at a placement (via
Displayable.setCommand(Command, int),Displayable.setMenu(Menu, int), orItem.setCommand(Command, int))
in the CommandLayoutPolicy implementation will be ignored and not displayed.but omits to say when they have to have been
explicitly set
.On the other hand, the example code in the
CommandLayoutPolicyclass documentation, although somewhat broken, see below, explictly clears unused placements... for (int i = cmd.length; i < positions.length; ++i) { //clear all non-used placements displayable.removeCommandOrMenu(border + positions[i]); } ... -
Currently the example code in the
CommandLayoutPolicyclass is broken and should not be used as an example of how to implement anonLayoutmethod. See here.
3. Placements
For all Displays
-
a placement may be located on any one of the four borders
- top,
- bottom,
- left,
- right
of the Display, or offscreen
- each placement has an associated index
- indices run from 1 to the maximum number of Commands possible at any location which is fifteen
- for the horizontal borders, top and bottom, indices run from to left to right
- for the vertical borders, left and right, indices run from top to bottom
- the borders and directions are relative to the current orientation of the Display
For a given Display
- there may be a set of preferred placements for a given Command type.
- only a sub-set of the possible placements may support Menus.
- there may be a set of preferred placements for Menus.
The set of possible placements is Display specific.
3.1 Runtime Constants
The possible locations are represented by the following constants defined in the Display class.
- SOFTKEY_TOP
- SOFTKEY_BOTTOM
- SOFTKEY_LEFT
- SOFTKEY_RIGHT
- SOFTKEY_OFFSCREEN
3.2 Runtime Representation
At runtime a placement is represented by the integer which is the sum of the constant specifying its location and its index.
4. Layout Only Methods
The following Displayable methods can only be called during the layout of a Displayable’s Commands
In each case the method must only be called directly, or indirectly, from the onLayout(Displayable) method of a CommandLayoutPolicy object.
The Displayable the method is invoked on must either be
- the Displayable that was passed to the
onLayout(Displayable)method - or the Form or List of the current Tab, if the Displayable passed to the
onLayout(Displayable)method is a TabbedPane
It is an error if these constraints are not met and an IllegalStateException will be thrown.
Item has a single method which can only be called during the layout of a Displayable’s Commands
The method must only be called directly, or indirectly, from the onLayout(Displayable) method of a CommandLayoutPolicy object.
The item that the method is invoked on must be contained within a Form which is either
- the Displayable that was passed to the
onLayout(Displayable)method, or - the current Tab of a TabbedPane that was passed to the
onLayout(Displayable)method
It is an error if these constraints are not met and an IllegalStateException will be thrown.
5. Display CommandLayout Support
5.1 Getting The Current ComandLayoutPolicy
The current CommandLayoutPolicy object of a Display can be obtained by calling it’s
public CommandLayoutPolicy getCommandLayoutPolicy()
method.
5.2 Setting The Current ComandLayoutPolicy
The current CommandLayoutPolicy object of a Display can be set by calling it’s
public void setCommandLayoutPolicy(CommandLayoutPolicy policy)
method.
The specified CommandLayoutPolicy object will be used to perform the layout of the Commands of any Displayable which becomes current on this Display and which does not have an associated CommandLayoutPolicy object. If null was specified then a platform specific mechanism will be used.
5.3 Getting The Available Placements
The placements available on a given border of a Display, or offscreen, can be accessed using the Display’s
public int[] getExactPlacementPositions(int border)
method.
The border argument must one of the runtime constants listed above.
The method returns the placements at the specified location, or null if there are no placements at that location.
Note
- Despite being location specific the returned values are placements not indices.
5.4 Getting The Preferred Placements For A Command Type
The preferred placements for a given Command type can be obtained by using the Display’s
public int[] getCommandPreferredPlacements(int commandType)
method.
It is an error if the commandType argument is not one of the runtime constants defined in the Command class which represent Command types.
The method returns null if there are no preferred placements for the given Command type.
5.5 Getting The Placements That Support Menus
The placements that support Menus can be obtained by using the Display’s
public int[] getMenuSupportedPlacements()
method.
The method returns null if there are no placements that support Menus.
5.6 Getting The Preferred Placements For Menus
The preferred placements for Menus can be obtained by using the Display’s
public int[] getMenuPreferredPlacements()
method.
The method returns null if there are no preferred placements for Menus.
6. Displayable Command Layout Support
6.1 Getting The Current Display
The Display, if any, with which the Displayable is currently associated can be obtained by calling the Displayable’s
public Display getCurrentDisplay()
method.
The method will return null if the Displayable is not currently associated with a Display.
6.2 Getting The Current CommandLayoutPolicy
The current CommandLayoutPolicy object of a Displayable can be obtained by calling its
public CommandLayoutPolicy getCommandLayoutPolicy()
method.
6.3 Setting The Current CommandLayoutPolicy
The CommandLayoutPolicy object responsible for laying out a Displayable’s Commands can be specified using it’s
public void setCommandLayoutPolicy(CommandLayoutPolicy policy))
method.
6.4 Invalidating The Current Command Layout
The current Command layout of a Displayable can be invalidated by calling the Displayable’s
public void invalidateCommandLayout()
method.
Note
-
The specification is not very forthcoming on what this method actually does.
The full method documentation reads
Request an update of the layout policy. If this displayable is not current on its display, or doesn’t have focus the request will be ignored.
Presumably if the Displayable is current on its Display and the Display is in the Foreground state and the Displayable or the Display has an associated CommandLayoutPolicy object then, at some point the
onLayout(Displayable)method of that object will be called.
6.5 Getting The Displayable’s Commands
The set of Commands that have been added to a Displayable can be obtained by calling it’s
public Command[] getCommands()
method.
Note
- See here for a discussion on what the return value of this method might actually contain.
6.6 Getting The Command At A Specific Placement
The Command associated with a specific placement of the Displayble’s current Display can be obtained by calling the Displayable’s
public Command getCommand(int placement)
method.
It is an error if the placement argument is not valid and an IllegalArgumentException will be thrown.
Note
-
It is not clear when a placement is valid in this context, nor what will happen if this method is called when the Displayable is not associated with a Display. An answer to the first issue may resolve the second.
There are two possible ways in which a placement may not be valid.
-
It may not be well-formed, that is the location is not one of the runtime constants listed above, or the index is not between one and fifteen inclusive.
-
It may be well-formed but not correspond to an actual placement on a given Display at a given time.
If being valid means being well-formed then the method could simply return
nullwhen the Displayable has no current Display.If being valid means being well-formed and corresponding to an actual placement on a given Display then the method should throw an IllegalArgumentException if the Displayable does not have a current Display.
-
6.7 Placing A Command
During Command layout a Command can be associated with a specific placement using the Displayable’s
public void setCommand(Command cmd, int placement)
This is a layout only method.
It is an error if the current Display of the Displayable does not support Commands and a DisplayCapabilityException will be thrown.
It is an error if the specified placement is not valid and an IllegalArgumentException will be thrown.
If the specified Command is currently associated with another placement of the Display it will be removed from that placement.
If there is a Command or Menu associated with the specified placement will be removed from the Displayable or Item which owns it.
Notes
-
See here for a discussion of the issues surrounding some aspects of the semantics of this method.
-
It is difficult to see under what circumstances a DisplayCapabilityException could be thrown by this method.
If the current Display does not support Commands then
-
if the Displayable had Commands when it was passed to the Display’s
setCurrent(Displayable)method a DisplayCapabilityException would heve been thrown. - if an attempt was made to add a Command to the Displayable once it was current on Display that did not support Commands then a DisplayCapabilityException would heve been thrown.
To get to the point where it could happen the implementation would have had to deliberately call the
onLayout(Displayable)method of the CommandLayoutPolicy object responsible for the Displayable knowing that-
the Display did not support Commands
-
the Displayable did not have any associated Commands
but this may actually be an implicit requirement
-
-
The specification states that an IllegalArgumentException will be thrown if the
placementargumentis associated with a placement that does not support commands
This and the documentation for
Item.setCommand(Command, int)are the only places in the specification where it is suggested that a placement may not support Commands. -
The specification does not explicitly forbid the use of a Command which is also in a Menu.
6.8 Getting The Menu At A Specific Placement
The Menu associated with a specific placement can be obtained by calling a Displayable’s
public Menu getMenu(int placement)
method.
It is an error if the specified placement is not valid and an IllegalArgumentException will be thrown.
If there is no Menu associated with the placement null will be returned.
Note
See the Note for the
getCommand(int)method above
6.9 Placing A Menu
During the layout of a Displayable’s Commands a Menu can be associated with a specific placement using the Displayable’s
public void setMenu(Menu menu, int placement)
method.
This is a layout only method.
It is an error if the current Display of the Displayable does not support Menus and a DisplayCapabilityException will be thrown.
It is an error if the specified placement is not valid or it does not support Menus and an IllegalArgumentException will be thrown.
The Command or Menu, if any, currently associated with the specified placement will be removed.
If the specified Menu is currently associated with another placement it will be removed from that placement.
Notes
-
See here for a discussion of the issues surrounding some aspects of the semantics of this method.
-
Presumably in the case of a Display which does not support Menus the DisplayCapabilityException will be thrown in preference to the IllegalArgumentException.
-
The specification does not explictly preclude the use of a Menu which is a sub-Menu.
6.10 Removing A Command Or Menu From A Placement
During the layout of a Displayable’s Commands, a Command or Menu can be removed from a specific placement by calling the Displayable’s
public void removeCommandOrMenu(int placement)
method.
This is a layout only method.
It is an error if the specified placement is not valid and an IllegalArgumentException will be thrown.
Note
-
It is not clear from the specification what it means for a placement to be valid in this context. I would assume that it means that it must be an actual placement associated with the Displayable’s current Display.
-
The behaviour if there is neither a Command or a Menu associated with the placement is not specified, but presumably it is a no-op, and this is certainly what the CommandLayoutPolicy example assumes.
7. Item Command Layout Support
7.1 Getting An Item’s Commands
The Commands currently associated with a Item can be obtained by calling the Item’s
public Command[] getCommands()
method.
Note
-
The method documentation states that this method returns
An array containing all commands added to the item via
addCommand()If this is literally true then this method is going to return all the Commands ever added to the Item which is novel but pointless.
Item also has a
removeCommand(Command)method so we might hope that the effects of that might be taken into account as well.However, Item also has a
setCommand(Command, int)method (see below) whichAdds or sets a
Commandto theItemat the givenplacement.[emphasis added].
In addition the documentation for both this method and the equivalent Displayable method
statesany
MenuorCommandalready occupying the given placement will be removed from the associatedItemorDisplayable.If the set of Commands returned from the
getCommands()method really is just the Commands added viaaddCommand(Command)and not subsequently removed viaremoveCommand(Command), then it still does not actually reflect the current state of the Item’s commands and it is effectively useless.This is especially true if we assume that one possible client of this method is a CommandLayoutPolicy object which wishes to obtain a list of the Item’s Commands that is is responsible for laying out. If it cannot obtain an accurate list using this method then it is going to have keep track of each Item’s Commands itself.
In short, the
getCommands()method is either not very useful or seriously underspecified.
7.2 Placing A Command
During the layout of a Displayable’s Commands an Item’s Command can be associated with a specific placement using the
Item’s
public void setCommand(Command cmd, int placement)
method.
This is a layout only method.
A DisplayCapabilityException is throw in the current Display does not support Commands.
It is an error if the placement is not valid or it does not support Commands and an IllegalArgumentException will be thrown.
If the specified Command is currently associated with another placement it will be removed from that placement.
The Command or Menu, if any, currently associated with the specified placement will be removed from the Displayable or Item that owns it.
Notes
-
As noted in the
setCommand(Command,int)case these are the only two places in the specification where it is suggested that a placement might not support Commands -
As also noted in the
setCommand(Command,int)case the possibility of a
DisplayableCapabilityException is difficult to explain. In this case how does the Form containing the item can end up on a Displayable that does not support Commands if it contains Items that have Commands ?
8. Command Layout Issues
8.1 Lack Of An Explicit Model
Arguably the basic issue and the one from which the others follow is that there is no explict model of Command Layout and how it should work. Instead information is scattered through class and method documentation. This constitutes an implicit model of Command Layout but it is not an adequate substitute for a systematic definition of the concepts and functionality involved.
8.2 Adding And Removing Commands From A Displayable, Or What Exactly Does Displayable.getCommands() Return And Why ?
The single largest issue with the implicit model is the lack of a clear definition of what now constitutes the addition of a Command to, or the removal of a Command from, a Displayable.
Originally, pre MIDP 3, it was reasonably simple.
The Displayable.addCommand(Command) method documentation begins
Adds a command to the Displayable.
The Displayable.removeCommand(Command) method documentation begins
Removes a command from the Displayable.
That was it, ignoring the idiosyncracies of Alert. That was all it was possible to do. It wasn’t event possible to query the Displayable for it’s Commands.
In MIDP 3 there are new Displayable methods which also seem to add and remove Commands.
The Displayable.setCommand(Command, int) method
Adds or sets a
Commandto the Displayable at the givenplacement.
[Emphasis added]
and in doing so
any
MenuorCommandalready occupying the given placement will be removed from the associatedItemorDisplayable.
[Emphasis added]
Then there is the Displayable.setMenu(Menu, int) method which
Adds or sets a menu to the Displayable at the given placement.
[Emphasis added].
and, just like the setCommand(Command, int) method
any
MenuorCommandalready occupying the given placement will be removed from the associatedItemorDisplayable.
[Emphasis added].
There is also a new Item method setCommand(Command, int) which does not add a Command to a Displayable but like, Dispayable.setCommand(Command, int), and
Displayable.setMenu(Menu, int) it seems that it gets to remove them
any
MenuorCommandalready occupying the given placement will be removed from the associatedItemorDisplayable.
[Emphasis added]
On that basis of the method documentation cited it is possible to construct reasonably plausible models of Displayables and Commands, and Displayables and Menus.
7.2.1 Displayables And Commands: A Model
-
a Displayable has a set of Commands, which may be empty
-
membership of a Displayable’s set of Commands is object identity based
-
a Command will be added to a Displayable’s set of Commands if it is not already a member, and it is either
-
passed as an argument to the Displayable’s
addCommand(Command)method, or -
passed as an argument to a valid call to the Displayable’s
setCommand(Command, int)method with a valid placement
-
-
a Command will be removed from a Displayable’s set of Commands if it is currently a member, and it is either
-
passed as as an argument to the Displayable’s
removeCommand(Command)method, or -
currently associated with a placement, and that placement passed as an argument to a valid call to either
- the Displayable’s
setCommand(Command, int)method with a different Command - the Displayable’s
setMenu(Menu, int)method
or,
-
-
if the Displayable is a Form, and the Command is currently associated with a placement, and that placement is passed as
an argument to a valid call to thesetCommand(Command, int)method of an Item contained in the Form, or -
if the Displayable is a TabbedPane, and the Command is currently associated with a placement, and that placement is either
- passed to the current Tab’s
setCommand(Command, int)method with a different Command, or - passed to the current Tab’s
setMenu(Menu, int)method, or - passed to
setCommand(Command, int)of an Item contained in the Form which is the current Tab, with a different Command
a Command cannot be added to a Displayable’s set of Commands if the Displayable’s current Display does not support Commands
a Displayable with a non-empty set of Commands cannot become current on a Display that does not support Commands
the Displayable.getCommands() method will return the Dispayable’s set of Commands
Note
-
the model does not include the special case behaviour for Alerts and FileSelectors
7.2.2 A Displayable Menus Model
-
a Displayable has a set of Menus, which may be empty
-
membership of a Displayable’s set of Menus is object identity based
-
a Menu will be added to a Displayable’s set of Menus if it is not already a member, and it passed as an argument to the
Displayable’ssetMenu(Menu, int)method with a valid placement -
a Menu will be removed from a Displayable’s set of Menus is it is a member, and it is currently associated with a placement,
and that placement is either -
currently associated with a placement, and that placement passed as an argument to a valid call to either
- the Displayable’s
setCommand(Command, int)method with a different Command - the Displayable’s
setMenu(Menu, int)method -
if the Displayable is a Form, and the Menu is currently associated with a placement, and that placement is passed as
an argument to a valid call to thesetCommand(Command, int)method of an Item contained in the Form, or -
if the Displayable is a TabbedPane, and the Menu is currently associated with a placement, and that placement is either
- passed to the current Tab’s
setCommand(Command, int)method with a different Command, or - passed to the current Tab’s
setMenu(Menu, int)method, or - passed to
setCommand(Command, int)of an Item contained in the Form which is the current Tab, with a different Command -
a Menu cannot be added to a Displayable’s set of Menus if the Displayable’s current Display does not support Menus
-
a Displayable with a non-empty set of Menus cannot become current on a Display that does not support Menus
-
there is no way to programatically obtain the Dispayable’s set of Menus
or,
Note
-
the model does not include the special case behaviour for FileSelectors
7.3 Other Issues
-
under what circumstances can a CommandLayoutPolicy object’s
onLayout(Displayable)method get called for a given Displayable ? -
when does Command layout occur relative to other Displayable and Display events ?
-
what state are a Display’s placements in when an
onLayout(Displayable)method is called ?</p -
are there any circumstances when an implememntation does not have to layout the Command’s of a Displayable that is current or about to become current on a Display
-
can a placement only support Menus ?
Appendix: Issues With The CommandLayoutPolicy Example
The following example (line numbers added) appears in the CommandLayoutPolicy class documentation.
1 class MyCanvas extends Canvas implements CommandLayoutPolicy {
2 MyCanvas() {
3 setCommandLayoutPolicy(this);
4 }
5
6 void sort(Command[] commands, int[] positions) {
7 // sort the commands in the correct order depending on the positions available.
8 // Implementation can use Display's getCommandPlacements to get the recommended
9 // placement for each Command.
10 }
11
12 public boolean onCommandLayout(Displayable displayable) {
13 Display display = displayable.getCurrentDisplay();
14
15 final int border = Display.SOFTKEY_BOTTOM;
16
17 int[] positions = display.getExactPlacementPositions(border);
18
19 Command[] cmd = displayable.getCommands();
20
21 sort(cmd, positions);
22
23 if (cmd.length <= positions.length) {
24
25 for (int i = 0; i < cmd.length; ++i) {
26 displayable.setCommand(cmd[i], border + positions[i]);
27 }
28 for (int i = cmd.length; i < positions.length; ++i) {
29 //clear all non-used placements
30 displayable.removeCommandOrMenu(border + positions[i]);
31 }
32 } else {
33
34 for (int i = 0; i < positions.length - 1; ++i) {
35 displayable.setCommand(cmd[i], border + positions[i]);
36 }
37
38 Menu options = new Menu("More", null, null);
39 for (int i = positions.length; i < cmd.length; ++i) {
40 options.append(cmd[i]);
41 }
42 displayable.setMenu(options, positions[positions.length-1]);
43 }
44 }
45 }
At line 17 the return value of a call to the method Display.getExactPlacementPositions() is assigned to the variable positions. The method may return null. This is not tested for. If non-null then the return value is an array of placements, not indices. At lines 26, 30, and 35, the value of an element in positions is added to the value of border which is actually the constant Display.SOFTKEY_BOTTOM, and the result is then passed as a placement. In each case the placement will be invalid but only the first use at line 26 will be reached as an exception will then be thrown.
At line 42 an element of positions is passed directly as a placement to the method Display.setMenu(Menu,int) which is correct. However, calling the method without first checking whether the placement supports Menus is not.
And pedantically, at line 8 the comment mentions Display’s getCommandPlacements [method]
. This should be Display’s getCommandPreferredPlacements method
. And even more pedantically if the method is going to call a method on the current Display it will need to be passed either the Display or the Displayable.
Appendix: Working With Placements At Runtime
Obtaining the location or index of a placement requires the use of bit-wise AND and the constant SOFTKEY_INDEX_MASK
which is defined in the Display class.
Example
import javax.microedition.lcdui.Display;
...
int placement = ...;
int location = placement & ~Display.SOFTKEY_INDEX_MASK;
int index = placement & Display.SOFTKEY_INDEX_MASK;
...
Appendix: Placements And Display Orientation
Placements are relative to the current orientation of the Display which means that Command layout following an orientation change could be quite an interesting challenge.
Example
Assume a Display, initially in Portrait orientation, with two placements A and B on the left border and two placements, C and D, on the bottom border.
Example Placements: Portrait Orientation

In this orientation the available placements are
| ID | Border | Index | Placement |
|---|---|---|---|
| A | Left | 1 | 821 |
| B | Left | 2 | 822 |
| C | Bottom | 1 | 801 |
| D | Bottom | 2 | 802 |
and Display.getExactPlacementPositions(int) returns
| Border | Return Value |
|---|---|
SOFTKEY_TOP |
null |
SOFTKEY_BOTTOM |
int[] { 801, 802 } |
SOFTKEY_LEFT |
int[] { 821, 822 } |
SOFTKEY_RIGHT |
null |
Example Placements: Landscape Orientation

In this orientation the available placements are
| ID | Border | Index | Placement |
|---|---|---|---|
| A | Top | 2 | 842 |
| B | Top | 1 | 841 |
| C | Left | 1 | 821 |
| D | Left | 2 | 822 |
and Display.getExactPlacementPositions(int) returns
| Border | Return Value |
|---|---|
SOFTKEY_TOP |
int[] { 841, 842 } |
SOFTKEY_BOTTOM |
null |
SOFTKEY_LEFT |
int[] { 821, 822 } |
SOFTKEY_RIGHT |
null |
Example Placements: Portrait 180 Orientation

In this orientation the available placements are
| ID | Border | Index | Placement |
|---|---|---|---|
| A | Right | 2 | 862 |
| B | Right | 1 | 861 |
| C | Top | 2 | 842 |
| D | Top | 1 | 841 |
and Display.getExactPlacementPositions(int) returns
| Border | Return Value |
|---|---|
SOFTKEY_TOP |
int[] { 841, 842 } |
SOFTKEY_BOTTOM |
null |
SOFTKEY_LEFT |
null |
SOFTKEY_RIGHT |
int[] { 861, 862 } |
Example Placements: Landscape 180 Orientation

In this orientation the available placements are
| ID | Border | Index | Placement |
|---|---|---|---|
| A | Bottom | 1 | 801 |
| B | Bottom | 2 | 802 |
| C | Right | 2 | 862 |
| D | Right | 1 | 861 |
and Display.getExactPlacementPositions(int) returns
| Border | Return Value |
|---|---|
SOFTKEY_TOP |
null |
SOFTKEY_BOTTOM |
int[] { 801, 802 } |
SOFTKEY_LEFT |
null |
SOFTKEY_RIGHT |
int[] { 861, 862 } |
Copyright (c) 2009 By Simon Lewis. All Rights Reserved.
[...] do not support Command layout and the following methods are all explicitly over-ridden and defined to throw an [...]
Pingback by What’s New In MIDP 3.0 ? Part 23; LCDUI – FileSelector « Just An Application — July 7, 2009 @ 10:49 am
[...] support Command layout. When a TabbedPane is displayed both Commands belonging to it, and to the Form or List in the [...]
Pingback by What’s New In MIDP 3.0 ? Part 24: LCDUI – TabbedPane « Just An Application — July 9, 2009 @ 11:04 am
[...] What’s New In MIDP 3.0: Redux – LCDUI – Command Layout Filed under: JME, Java, LCDUI, MIDP, MIDP3, MIDP3Issues, MIDP3LCDUI — Tags: Java, JME, JSR271, MIDP, MIDP3, MIDP3LCDUI, MIDP3SpecIssues — Simon Lewis @ 10:49 am Original Post [...]
Pingback by What’s New In MIDP 3.0: Redux – LCDUI – Command Layout « Just An Application — December 16, 2009 @ 10:49 am