I am experiencing a strange problem: I have a Screen that is using the default VerticalFieldManager …. super( USE_ALL_WIDTH | USE_ALL_HEIGHT ); ….. whereby we add 24 additional fields. These additional fields are of Types RichTextField, NullField, TextField, and ObjectChoiceField. This screen is effecitvely just a CRUD form … for entering data to be sent to a backend server.
What’s interesting is the fact that I cannot use the little TrackPad (the real device and simulator are 9850 Torch 2’s) to navigate down to the fields that are at the bottom of the screen. As it is a Touch based device, I can “drag” the screen upwards to expose those fields which are at the bottom but only after the virtual keyboard has been displayed.
According to the MainManager.getVirtualHeight() method my virtual height is 970 pixels and my visible height is 800 (Torch 2). The fields that are below the initial “viewable content area”, and require scrolling to get to, I am unable to use the trackpad to place focus into one of those TextFields that are below the lower edge of the screen ….. point in fact, I might be able to place focus there but the screen still is not scrolling those lower fields upwards so that the user can see them.
It’s a very simple implementation:
public class GetDataScreen extends MainScreen .....
public GetDataScreen()
{
super( MainScreen.USE_ALL_WIDTH | MainScreen.USE_ALL_HEIGHT );
add( field1 );
add( field2 );
....
...
..
.
}
Any thoughts on what’s causing this or how to fix it? For the record I have also tried calling:
super( MainScreen.VERTICAL_SCROLL | MainScreen.VERTICAL_SCROLLBAR | MainScreen.USE_ALL_WIDTH | MainScreen.USE_ALL_HEIGHT );
….. hoping that would fix it but it didn’t make any difference.
Thanks
Okay .. after allot of trial and error I did something (complete desperation) and it worked! This is too dumb, and if it weren’t for the fact that some other person might have the same issue I’d keep this to myself …..
I simply created a VerticalFieldManager that I added all the fields to, then added that VFM to the Screen. Point in fact this should NOT make any difference – at all – as the default Manager on a Screen is a VFM. Nothing else. No other properties set, methods called, events …. nada.
Go figure.