When a user program edits data, it must change the document content, and change the view correspondingly.

The text model requires the following sequence of operations for any kind of edit:

  • the application identifies which command is to be performed, by interpreting user input (pointer and key events etc)

    Pointer-driven input may first use the view to set a cursor selection, and then invoke a function. Regardless of the method of input, the text view's cursor selection will often define the region of the text object affected by the command.

  • the application invokes the relevant text content function to execute the command — a change to content, format or both

    By this means, the document is changed, and the text view is now out of date.

  • the application notifies the text view what type of change occurred and, if appropriate, specifies the range of the document that was affected

    This allows the text view to interrogate the document (through its laydoc interface) about its changed content, and to perform the minimal changes to its layout and view, and then to redraw the view.

It is the application's responsibility to identify the command, change the content, and specify the kind of updating needed in the view.

The application should choose the function used to notify the view about the type of content update. After a major change (such as loading the document), the application should ask the view to reformat and redraw the entire format band. But this is overkill for most purposes: after a single character has been inserted, for instance, only a limited amount of reformatting may be necessary, usually confined to the remainder of the line in which the character was inserted. The general rule is that the application should choose the lightest-weight function that is guaranteed to do the necessary reformatting. This is what makes text views efficient.

See How to handle changes to the text view.