InputField should verify all input changes with func accept()

[ardnew]

Currently, InputField will conditionally permit any input changes using the user-provided callback accept(), but only if the input is a regular character (i.e. event.Key() == tcell.KeyRune). This means the callback cannot be used to conditionally permit control characters like backspace.

A simple example is the callback function that renders an InputField read-only:

rejectInput := func(string, rune) bool { return false }

form := tview.NewForm()
form.AddInputField("foo", "bar", 0, rejectInput, nil)

This will prevent new characters from being inserted, but it won't prevent characters from being deleted. In fact, I don't think there exists a way to prevent the user from deleting text in an InputField (I could be wrong on this point).

The same loophole exists for the key-combos Ctrl+U and Ctrl+W.

[ardnew]

I also considered bringing the accept() handler outside (immediately before) the switch key := event.Key(); key { ... } block - so that it can be used to evaluate all input changes and not just the few I updated; but I wasn't sure if that kept with the spirit of your intent with that callback (since you wouldn't be able to pass in the changed text to evaluate).

Perhaps a different callback should be created, or even subclassing the InputField might be preferred if you need that much control?

[rivo]

The accept() function is not meant to be a filter on the user's keyboard actions but rather on the final text of the InputField.

If you would like to intercept certain keys, you'll want to use SetInputCapture() on the InputField.

Note that I will add more key combinations in the future and a backspace will then not only affect the last character. See #103.

Let me know if this helps.

[ardnew]

Ah, I've been misusing that callback. Thanks

Somewhat related -- can you clarify the difference or describe how I should choose between using SetInputCapture() versus overriding InputHandler() for the case that I have a type with an embedded primitive (e.g. type MyTable struct { *tview.Table })?

The docs say that defining InputHandler() a certain way allows the use of SetInputCapture(), but I don't understand why I would want or need to use one over the other. They appear to function the same and serve the same purpose.

[rivo]

Unless you are writing your own Primitive, you can ignore InputHandler(). Most applications will be fine using an existing primitive (e.g. InputField) and calling SetInputCapture() to change its input behaviour.

It's only when you end up writing your own Primitive that you'll need to implement InputHandler() and the Wiki page you refer to gives you hints as to how to structure your code in that case.

But I would think that writing one's own Primitive is usually not needed.

I'm closing this issue. If there's still an open item, I can reopen it.