How to reset the options of a Select widget

[PlasmaHH]

I tried to naively just use set_options to set them as that seemed to be the right thing:

import textual.widgets

sel = textual.widgets.Select( [ ( "", "" ) ], classes = "select", id = "select" )
sel.set_options( [ ("A", "B") ] )

but that resulted in

> ./selecte.py 
Traceback (most recent call last):
  File "/home/plasmahh/src/python/./selecte.py", line 7, in <module>
    sel.set_options( [ ("A", "B") ] )
  File "/home/plasmahh/.venv/dev/lib64/python3.11/site-packages/textual/widgets/_select.py", line 452, in set_options
    self._setup_options_renderables()
  File "/home/plasmahh/.venv/dev/lib64/python3.11/site-packages/textual/widgets/_select.py", line 426, in _setup_options_renderables
    option_list = self.query_one(SelectOverlay)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/plasmahh/.venv/dev/lib64/python3.11/site-packages/textual/dom.py", line 1472, in query_one
    raise NoMatches(f"No nodes match {selector!r} on {self!r}")
textual.css.query.NoMatches: No nodes match <class 'textual.widgets._select.SelectOverlay'> on Select(id='select')

How can I update the options (without having to always create a new Select object)?

Bonus points: how to set the selected value right away without triggering an event?

[darrenburns]

You can't interact with widgets like this outside of a Textual app.

You'll need to move this code into a compose method in an App.

[PlasmaHH]

Minimal example from my pov is the smallest that exhibits the behaviour.

Your example doesn't exhibit any behaviour because it doesn't run.

Well exactly that was the point, my original code didn't run and exhibited the same behaviour, so I stripped it down until the shown code was the minimum necessary to exhibit the same error. If questions here are meant to me only about code that is running fine I will try to take that into account for the next time.

So doing it in some code that is run via call_next/call_later is fine then?

It's not directly related to call_next/call_later, it's more dependent on where you're running it from. Without context it's hard to say e.g. - Are you loading the options from and API on startup (if so, just set_options in on_mount)? Are you clicking a button somewhere and that's changing the options (set_options goes in your event handler)?

Well the context where I want to set the options can be at a lot of places. I am updating one of my objects and this can cause the select options to change. And setting it can happen from a button, from a function called in via call_next or call_later (I have some functionality that uses this to "schedule" itself again as soon as it is done), or, and that was the most problematic part, somewhere in the applications setup where I prepare the widgets, which was initially in init (and now for that widget I leave it empty and let it be populated in the first run from a call_next or call_later path )

[darrenburns]

(and now for that widget I leave it empty and let it be populated in the first run from a call_next or call_later path )

You probably want to move this stuff into on_mount and remove the call_next and call_later. Doing that would be more idiomatic and also means that widgets are ready to work with (so set_mount will work).

[PlasmaHH]

You probably want to move this stuff into on_mount and remove the call_next and call_later. Doing that would be more idiomatic and also means that widgets are ready to work with (so set_mount will work).

You mean for the initial setup ? Or not use call_next/later at all? If so, what would be a way to update some display not based on events but as fast as possible?

[darrenburns]

I mean you should do initial setup in on_mount without calling call_next/call_later.

call_next and call_later have their uses but I can't see why they'd be required based on what you've described.

what would be a way to update some display not based on events but as fast as possible?

on_mount is the earliest point in time you can reliably update widgets.

[PlasmaHH]

on_mount is the earliest point in time you can reliably update widgets.

Ok, that sounds like a good rule to work by

regarding the call_next/later thing, this seemed to be the easiest way I could find in the API to update all the data I display on the screen in the fastest way possible: get called, retrieve data, update widgets, schedule me to get called again.