mirror of
https://github.com/rivo/tview.git
synced 2026-04-26 21:35:54 +03:00
[GH-ISSUE #723] Idea: Add additional "Add..." methods to Form, returning pointer to the field instead of Form #528
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tview#528
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @moson-mo on GitHub (Apr 15, 2022).
Original GitHub issue: https://github.com/rivo/tview/issues/723
Currently there are methods to add form fields (like AddInputField, AddDropDown, etc...) that return a pointer to the form.
This is nice if you want to chain several of those method calls.
Now there might be situations where would rather like to have a pointer to the field that has just been added instead of the form because you need to customize it further.
We could do
func (f *Form) AddButton(label string, selected func()) (*Form, *Button) {...and return both, but that would break all apps currently using that method.
So, the only viable way seems to be to add another method like:
func (f *Form) AddButtonXXX(label string, selected func()) (*Button) {...Does that make sense?
(I'm probably missing something but atm, it seems, the only way to get back to your fields is to call GetFormItem... and then do type assertion?)
What should they be named?
proposals (for the example AddInputField):
AddInputFieldCustomizeAddInputFieldCustomAddInputFieldExtendAddInputFieldReturnShould be simple to implement, hence I'd volunteer to do this 😉
@moson-mo commented on GitHub (Jun 20, 2022):
Not really. I'm just stupid and missed that there is
AddFormItem🤦So one can do: