starred/tview

Fork 0

mirror of https://github.com/rivo/tview.git synced 2026-04-26 21:35:54 +03:00

[GH-ISSUE #718] Form: AddDropDown immediately calls SelectedFunc #523

New issue

Closed

opened 2026-03-04 01:05:44 +03:00 by kerem · 7 comments

kerem commented

2026-03-04 01:05:44 +03:00

Owner

Originally created by @moson-mo on GitHub (Apr 3, 2022).
Original GitHub issue: https://github.com/rivo/tview/issues/718

Hi,

When you add a new DropDown item to a form, the "selected" func is immediately executed. (because the handler is registered prior to the SetCurrentOption call)

This does not seem to happen for any of the other form items.

regards,
MO

Very nice lib btw. I love it 😉

Originally created by @moson-mo on GitHub (Apr 3, 2022). Original GitHub issue: https://github.com/rivo/tview/issues/718 Hi, When you add a new DropDown item to a form, the "selected" func is immediately executed. (because the handler is registered prior to the SetCurrentOption call) This does not seem to happen for any of the other form items. regards, MO --- Very nice lib btw. I love it :wink:

kerem closed this issue

2026-03-04 01:05:44 +03:00

kerem commented

2026-03-04 01:05:45 +03:00

Author

Owner

@rivo commented on GitHub (Apr 15, 2022):

This is on purpose because other parts of the application may depend on the current selection of this drop-down. I didn't want to force users to query the initial state of the drop-down themselves (which would various function calls including a cast to DropDown). You could set the initial drop-down item to -1 but even then, the selected function would be called (see the documentation).

@rivo commented on GitHub (Apr 15, 2022): This is on purpose because other parts of the application may depend on the current selection of this drop-down. I didn't want to force users to query the initial state of the drop-down themselves (which would various function calls including a cast to `DropDown`). You could set the initial drop-down item to `-1` but even then, the `selected` function would be called (see the [documentation](https://pkg.go.dev/github.com/rivo/tview#DropDown.SetSelectedFunc)).

kerem commented

2026-03-04 01:05:45 +03:00

Author

Owner

@moson-mo commented on GitHub (Apr 15, 2022):

because other parts of the application may depend on the current selection of this drop-down

Hmm. That would also be valid for other fields like checkbox. That one, however, does not trigger change func because the value is set before the change func is registered. So it's somewhat inconsistent. 😉

@moson-mo commented on GitHub (Apr 15, 2022): > because other parts of the application may depend on the current selection of this drop-down Hmm. That would also be valid for other fields like checkbox. That one, however, does not trigger change func because the value is set before the change func is registered. So it's somewhat inconsistent. 😉

kerem commented

2026-03-04 01:05:45 +03:00

Author

Owner

@rivo commented on GitHub (Apr 15, 2022):

You're right. It would also affect Checkbox and InputField. There is a difference between these two and DropDown, however. It might just be a semantic difference, but the DropDown event handler is called selected whereas the handlers of the other two are called changed. I guess one could argue that going from "uninitialized" to "initial selection" is a selection but not a change.

Ok, but we should be looking at this in a more pragmatic way. Does the current behaviour cause problems in your application?

@rivo commented on GitHub (Apr 15, 2022): You're right. It would also affect `Checkbox` and `InputField`. There is a difference between these two and `DropDown`, however. It might just be a semantic difference, but the `DropDown` event handler is called `selected` whereas the handlers of the other two are called `changed`. I guess one could argue that going from "uninitialized" to "initial selection" is a selection but not a change. Ok, but we should be looking at this in a more pragmatic way. Does the current behaviour cause problems in your application?

kerem commented

2026-03-04 01:05:45 +03:00

Author

Owner

@moson-mo commented on GitHub (Apr 15, 2022):

Does the current behaviour cause problems in your application?

No, not really, I'm just working around this by registering the handler later on for those dropdown fields.

ps.settings.AddDropDown("Search by: ", []string{"Name", "Name & Description"}, by, nil)
	if dd, ok := ps.settings.GetFormItemByLabel("Search by: ").(*tview.DropDown); ok {
		dd.SetSelectedFunc(func(text string, index int) {
			if text != ps.conf.SearchBy {
				ps.settingsChanged = true
			}
		})
	}

That being said, I should probably change my approach entirely.

Right now I don't really care about the value itself when a setting / form item is changed. I just register that something has changed. And when the user hit's "Save", I'm collecting the values from all form items and write them back into my "config struct".

Instead of that, I should probably use a second temporary struct instead where any changes are written directly when the change/select func is called. And then compare the values of the fields in both structs to check if something has changed and needs to be saved...

@moson-mo commented on GitHub (Apr 15, 2022): > Does the current behaviour cause problems in your application? No, not really, I'm just working around this by registering the handler later on for those dropdown fields. ``` ps.settings.AddDropDown("Search by: ", []string{"Name", "Name & Description"}, by, nil) if dd, ok := ps.settings.GetFormItemByLabel("Search by: ").(*tview.DropDown); ok { dd.SetSelectedFunc(func(text string, index int) { if text != ps.conf.SearchBy { ps.settingsChanged = true } }) } ``` That being said, I should probably change my approach entirely. Right now I don't really care about the value itself when a setting / form item is changed. I just register that something has changed. And when the user hit's "Save", I'm collecting the values from all form items and write them back into my "config struct". Instead of that, I should probably use a second temporary struct instead where any changes are written directly when the change/select func is called. And then compare the values of the fields in both structs to check if something has changed and needs to be saved...

kerem commented

2026-03-04 01:05:45 +03:00

Author

Owner

@moson-mo commented on GitHub (Apr 15, 2022):

I see your point, change vs. select and also don't want to break things for other applications relying on the current behaviour hence I closed the pull request.

Would be cool if you can reference "pacseek" in the list of apps though (https://github.com/rivo/tview/pull/719/commits/53cae823c28d294a7efb5617985bc099abd6ca93)

Note that I did not intend to sneak that thing in with the pull. I'm just bad dealing with git 😉😂

@moson-mo commented on GitHub (Apr 15, 2022): I see your point, change vs. select and also don't want to break things for other applications relying on the current behaviour hence I closed the pull request. Would be cool if you can reference "pacseek" in the list of apps though (https://github.com/rivo/tview/pull/719/commits/53cae823c28d294a7efb5617985bc099abd6ca93) Note that I did not intend to sneak that thing in with the pull. I'm just bad dealing with git 😉😂

kerem commented

2026-03-04 01:05:45 +03:00

Author

Owner

@rivo commented on GitHub (Apr 15, 2022):

No problem. Can you submit a pull request for this commit?

@rivo commented on GitHub (Apr 15, 2022): No problem. Can you submit a pull request for this commit?

kerem commented

2026-03-04 01:05:45 +03:00

Author

Owner

@moson-mo commented on GitHub (Apr 15, 2022):