05-13-2009 12:56 PM
This clearly is my day to ask folks about user interface issues.
After reading enough in this forum and being told to go learn Swing 'cause the blackberry ui is similar, which it is, it leads to THIS question:
has anyone got a blackberry version of jcombobox?
'cause I am -very- used to having one, and it's annoying that I don't.
Ok, ok, I could use an editfield and capture a click and popup a popupscreen with a choicefield in it, and get the result and settext the edit box. If that's what I have to do, I will, but it seems lame.
05-13-2009 02:07 PM
I sort of thought that was what you were going to say. :-(
Thank you for not replying with "Write your own" and a pointer to the "how to make a custom field" entry in the knowledgebase.
I agree that the other thread, which I read last night, was not particularly productive.
I suspect that extending Field and just biting the bullet is the way to go. I'm finding this sort of thing _very_ frustrating.
No FormattedTextField, and no one has ever posted one despite many requests for such, and I certainly understand why, it's a non-trivial bit of writing. We're doing those on an ad-hoc basis now field by field. (ick) we ought to take the time to write a formattedTextField but we need to move on....
No combobox, -- this one we may HAVE to bite the bullet on. How do other developers get around it? ChoiceFields are not keyboard searchable are they? If they were, we could just deal with that, but when you have possibly a a hundred (or more) choices in the list, having the ability to enter from the keyboard, or JUMP to an item in the list from a keyboard entry is "handy"
I keep getting the sense that most people aren't really doing much text-centered input on the BB, which is odd, since it's a keyboard oriented device.
Oh well, thanks for answering Peter.
05-13-2009 05:24 PM
To be honest, I've not missed the uneditable combo box. On the BlackBerry, you can initiate the 'drop down' with the ALT key (or tapping it on the Storm), so the 'button' is not really needed. And yes, the list can be selected uisng the first character - it scrolls round from the current position looking for a match. At least the ones I've just tested did, and I don't remember putting in any code myself to do that. Not tested that on a Storm mind you.
The tricky one and the one I do get asked for is the editable combo, where the user has the option of entering a value. The way I usually get round that is a kludge - I add an 'other' selection in the drop down, and when that is selected I add an edit Field immediately after the drop down. This is not as trivial as it sounds - you have to remember the 'other' value but not use it unless Other is selected - but not too bad. Will it do the job for you?
I saw you request for formatted text and was going to add something there, will do so shortly.
05-13-2009 06:19 PM
the UNEDITABLE combo box is, as far as I care, a listbox. No problem there, Blackberry has lots of Choice fields to choose from.
The EDITABLE combo box we use all the time. The "other" trick doesn't do it. If you have 250 job codes,and a worker could do any of the 250, you want to be able to just TYPE IN the code if you know it. But if it's an "unusual" code (jury duty, something else weird) you need to look it up, and the list part of the combo box comes into play.
How many items can go into a context menu? I could populate the context menu of the "combobox" for the picker... but those are _not_ searchable.
So, idea 2.... popupscreen with one field on it, a choice field or a list field... so, enter what you want, or click, and if you click, we pop a screen with a list....
Not as nice, but if I position the popup screen carefully, it will be almost indistinguishable from a "real" combobox.
05-13-2009 07:31 PM
I believe RIM were going to or have come out with a Filtered Field so that you could type in an edit Field and have a list that would be searched based on the text entered, but I'm really not sure of the status of this and besides, it will only be in one of the later OS Levels.
What I have done is add a restricted height ListField (say only 5 rows) after an Edit Field, and I restrict the ListField based on whatever is in the EditField (using FieldChangedListener because this works on reduced KeyBoard devices!). This works OK. The ListField will shrink if there is only a few that match the input test too. This has not reached a production app yet, so hasn't been tested, but seems to work fine. In this particular case, the first characters in the Edit Field are used as a 'startWith type Filter. At any time the user can stop typing in the Edit Field and move focus to the ListField and then scroll and enter to select. I use this is small app I've not finished - it searches all the railway stations in the UK, I think there are 2,500 of them so 250 work codes would not be a problem.
The ListField disappears when focus is removed.
Of course if the user has just entered 'A', then scrolls of the EditField into the list of stations beginning with A, it will take them a long time to scroll down all of these to get onto the next Field. Unless they are on a Storm of course.
I thought about the popup screen and I do use this in another selection mechanism, but to be honest, I don't like it, I'd rather work on the integrated ListField. of course the ListField doe not overlay the screen nicely, it pushes everything down.
Ok not necessarily a very good idea, just a suggestion.
05-13-2009 08:38 PM
the problem with the expanding/contracting list field is that the job descriptions are oh, up to 60 characters long.
I think a controlled list field in a popup screen is about as good as I can do.
thanks tho for the discussion it helps me have some thoughts about directions to head in.