Android Question What is the best practice to set the state of a view without triggering it's "_changed" event?

[JohnC]

Often I need to setup the states of various views that have a "view_changed" event sub associated to them.

For example, when I initially display a "Settings" screen, I need to pre-set the user-selected state of the various option views, but I don't want to trigger their respective change event so it will not run code that I do not want to run at that time.

What is the best practice to do this?

I've been using a "Loading" boolean variable that I set true in the activity_create sub and then add code in each event sub to check this var and immediately exit the sub if it's true (so the sub's event code won't run). And then clear this flag at the end of the activity_create sub.

But is this 100% reliable in a world of async operations?

 

[kimstudio]

I have same question and use exact the same solution like you by a global variable.
For the combobox if I set the selectedindex it will fire change event. I think the change event should only fire when user operate it by user interface, not by internally setting.

 

[drgottjr]

i find that changing settings programatically still triggers the onchange event. i also looked at a few android view classes. there doesn't appear to be a "reliable" method to check a view's "state", whatever that might mean. i say RELIABLE because, there is a method to do just that, but the documentation says the method can return null. that is exactly what i got when i tried to check the "state" of a view. so, no go...

i think you end up doing what you already are doing, or, possibly, removing the view and replacing it with the new view when the user changes some setting. that, too, could be monitored with a flag. user sees view, goes to settings panel (thus hiding view), makes changes, hides settings panel and sees new view like nothing happened. as soon as settings panel is visible, flag is set disallowing any change events. when panel is hidden, flag is reset and changes are good to go. it's irrelevant at that point whether has made changes or not. if he made changes, new view is already in place

 

[Ilya G.]

For CheckBox it may be useful to use _Click event instead of _Changed