Event or no Event?

It is easier to call than preventing to be called

During a code review today, I brought up a little insight that we had a while ago.

We have a cross-platform UI library with widgets. UI widgets by nature serve two masters: The code using them wants to style them and prepopulate their content. The user using them wants to interact with them and modify their content.

Therefore, widgets typically offer functions to modify their properties, including the content, and also events that notify about content changes. For example, an edit box may offer a SetText function and a OnTextChange event.

Here is the question: If SetText modifies the text, should the OnTextChange event fire? Surely, the code using the widget has to do similar things, irrespective of who does the change.

But then, it is easy for the code to call the callback itself. Changing what the callback does is much harder: the code needs to transport the context into the callback. To make matters worse, the behavior dealing with the SetText scenario is now implemented in the callback, potentially far away from the call to SetText itself, with no obvious connection for the reader of the code.

So in our UI library, we follow the rule that only user interactions trigger events.