[sn0wshrew]

I'm creating an application where I attempt to duplicate the UI layout of the built-in MemoPad app: a listfield and, in the status, a search bar. Both of them must appear to have the focus, and both of them must behave as though they have the focus, but the search bar handless keypress events while the listfield handles scroll and click events.

Unfortunately, I seem to have run into a paradox where if either one doesn't actually have focus, it cannot be made to behave correctly:

• If the search bar (an AutoTextEditField) does not have focus, it does not composite text correctly on the BlackBerry Pearl. I tried forwarding keyChar events to it, but at this point the text is already composited (incorrectly) by the focused field.
• If the ListField does not have focus, I can make it behave 99% correctly by sending moveFocus events from the AutoTextEditField there; but scroll arrows are never painted by its manager. The manager only draws scroll arrows if its contents have focus, it seems. I could override this behavior with a custom manager, but I don't really control it because I'm using a MainScreen. And no, I don't want to switch to a FullScreen, because the Mainscreen provides a HUGE amount of useful functionality that I'm already using - I would basically have to rewrite the MainScreen class from scratch.

Snippets of code follow, to give you an idea of what I'm doing. Any ideas for how to force the MainScreen's manager to show scroll arrows, or for how to force a non-focused AutoTextEditField to composite text correctly on the Pearl?

	// This is the constructor for the Screen that descends from MainScreen.
	public ListScreen() 
	{ 
		super();

		// Create the big list control.
		customList = new CustomListField();
		
		// Add the big list control and its search bar to the screen.
		add(customList);
		setStatus(customList.getSearchBar());
	}

	// This is the constructor for the custom list that descends from ObjectListField.
	CustomListField()
	{
		super(Field.NON_FOCUSABLE);
		final CustomListField list = this;

		// Search bar must be FOCUSABLE to do input autocompletion for the Pearl.
		this.searchBar = new AutoTextEditField("Search: ", "", 20, Field.EDITABLE | TextField.NO_NEWLINE)
		{
			// Send all scroll events to the list.
			protected int moveFocus(int amount, int status, int time)
			{
				list.moveFocus(amount, status, time);
				return 0;
			}
		};
	}

[bemshaswing]

Try this:

public ListScreen()
{
super(Manager.VERTICAL_SCROLLBAR);

[sn0wshrew]

Thanks for the suggestion, bemshaswing! However, I'm afraid it doesn't work. The manager already is willing to show scroll bars, but only if the list has focus; and adding this style doesn't make it show scroll arrows when focus is in the search bar.

[jfisher]

hmmm - interesting problem, i looked at the memopad app and it's a bit of a challenge to figure it out - the input field always seem to be in focus even when scrolling the list.

it looks to me like one solution would be to have the search/find inputfield always have focus and trackwheel roll being overridden to change the selected index on the list field (and of course returning true to keep focus on the inputfield)

[sn0wshrew]

Hi jfisher, that's exactly what I'm trying to do! Like I said, that works for 99% of the scroll functionality. The only thing that's missing is getting the MainScreen's manager to show its scroll arrows when it doesn't have focus. This is clearly working in the MemoPad app, I just don't know how - any ideas?

[jfisher]

gotcha, haha, absolutely none then! sneaky rim developers are doing something strange:- and probably simple if you know how.

another guess would be the input field never has focus and they're creating their own custom inputfield - the listfield loses focus the moment you hit a key anyway - the caret might be a redherring and is drawn using methods overridden in an extended inputfield class. (i did something similar here but never implemented the caret: Wikipedia Application for BlackBerry - but there's more info in the javadoc about creating your own fields)

or can you live without having the arrows on screen?

[bemshaswing]

Here's another idea, though I have to admit, I can't get it to work.

According to the api, if within your screen you ovveride the isDownArrowShown method, it *should* implement as you want. I however have yet to see this work properly, I won't necessarily call it a bug, but I know that this method is called by the framework but the screen doesn't respond to it. Maybe I'm doing something wrong

example:

protected boolean isDownArrowShown() {

return true;

}

[sn0wshrew]

I do think that MemoPad isn't using a custom text field that somehow composits input even without having focus - its behavior seems perfectly normal for a focused text field. I do think that they are simulating the list having focus even though it doesn't.

bemshaswing, overriding the screen's isUpArrowShown() method is a great idea - but I too could not get it to work. I think because it's the manager that would make this decision, rather than the screen. I even tried creating a custom manager and putting it inside the MainScreen's getMainManager(), and putting the list inside the custom manager, but I was not able to find any configuration of this which would actually show scroll arrows and still have the correct drawing and scroll behaviors.

can you live without having the arrows on screen?

Until a few minutes ago the answer was "no", because it's a pretty bad user experience not to know whether they are at the top of the list.

However... I just had an idea for a workaround that may be adequate. If I scroll up/down a little farther than necessary, giving a "peek" of the next row above/below, that should be enough to indicate to the user whether they're at the top of the list yet. I'll let you guys know how that goes - thanks again for the suggestions!!