Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Update Screen from listener

The code that I see is not clear to me.


You do not need to invalidate the Screen to change a Fields status from editable to not.  However you may wish to invalidate it if the Field changes its appearance to indicate this situation.   


I understood from the above that the issue was the look of the screen.  Now I'm confused as to what the question really is.  Can you clarify this for us?


I'm also confused by the code here.  Why are you adding and removing Change Listeners. I would have thought you could add these at the beginning and leave them.  If a Field is not editable, then it is not going to change so the Change listener will never be driven.


And in my experience, adding a ChangeListener can throw an exception if there is already a change listener in place.   In fact this typically throws an exception unless you remove


Finally I think the check


is redundant.  if the user had not changed the Field you wouldn't be in the routine would you.


One more things.  When I have a set of related Fields, I create one Listener and have it listen to the changes in all the related Fields.  You can check the field using statements like


if ( field == calendarCheckbox ) {

} else

if ( field == ...


Having one Listener centralizes all the related code and I find it easier to manage.  but that is just me.

Posts: 77
Registered: ‎06-03-2009
My Device: Not Specified

Re: Update Screen from listener

Thanks peter_strange for your great tips. I will try to explain everything more clearly and simplify my case a little.

I have a checkbbox on the screen that when checked, a button field and an objectchoisefield get enable, and when unchecked they become disabled.

This works OK , However the appearance of them doesn't become grayed / un grayed immediately, so the user doesn't know they became disabled/enabled. only if he clicks one of them , he can know.


I found out the appearance changes from inside the listener when using the other method published here, but i found it doesn't work on the storm, it worked on 4.6 9000 emulator, so i guess it work on 4.5 devices or above which are not storm. the controls become grayed only after the screen pops out and in again.

On 4.2 emulators the controls don't get grayed at all, so i assume this appearance is not supported there at all.


The code snippet I published above is not my complete code and was intended to show how the listener look like, i removed lines to make it more clear and short, in the full code there are condition statements which prevent the listeners from being added more than once. I edited the code above to be more correct.

The reason why I'm adding and removing listener was because I thought i t will be redundant to leave a listener registered to a control which is disabled.


About the isDirty thing , thanks, it was unnecessary, I didn't notice that.


About using one listener, sounds like a good way, I thought I must use a separate listener for each control.



Bottom line, this case should be quite common, a checkbox which grays an objectChoice. Still I encounter difficulties.


By the way an objectChoiseField which grays a button does work well, without even having to invalidate():


final FieldChangeListener listenerObjectNumbers = new FieldChangeListener()	//numbers button
        	public void fieldChanged(Field field, int context)
           		if (objectChoiceFieldNumbers.getSelectedIndex() == 0 && buttonNumbers.getChangeListener() != null)	// all is selected
           			buttonNumbers.setEditable(false);	// disable button
        		else if (objectChoiceFieldNumbers.getSelectedIndex() == 1 && buttonNumbers.getChangeListener() == null)
        			buttonNumbers.setEditable(true);	// enable button




Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Update Screen from listener

Here is my theory....


Firstly I am sure you are right that in 4.2, the Fields did not attempt to indicate that they were not editable.  Nothing your can do there.


The ButtonField is relatively simple,  The ObjectCHoiceField on the other hand is not.  So it does not surprise me that you don't see the correct action in this Field.  It especially doesn't surprise me that this breaks in 4.7, because as I'm sure you will have seen, the way ObjectChoiceField looks changes significantly in 4.7. 


OK, so I don't have time to try this atm, but here is what i would try.


I would create an ObjectChoiceField that extended the standard one, but converted invalidate to be pubic.


Then in your change listener, cal invalidate() on the ObjectChoiceField, rather than the screen,


Sorry I have not got a better idea atm.