Please correct me if I’ve got this wrong.
Based on my experiments, selected_value
- begins as
None
- can be set only by the end-user (they must click the down-arrow button). Attempts to change it via code have no effect.
- is set only when the user’s activity actually changes the displayed text.
Thus, at the start, when the first value in the picklist is automatically displayed, it appears to the user as if that is, in fact, their selected value. They can even pick that first value voluntarily and explicitly, and selected_value remains None! That isn’t how it looks to them, but that is how it looks to your code.
Now, if the first value in the picklist is “please select a value from this list”, this makes perfect sense. It’s not a real value, and this mechanism lets our code easily tell when a real value is picked – and when it has not been picked.
But if the first picklist entry is an actual, selectable value, then the behavior of selected_value will be utterly confusing to the programmer. In this case, they should be looking at property text instead. It reflects what the user sees as his current selection.
There’s probably a simpler way to have it both ways. Still, it’s quite nice to be able to do them both.
Erm…if setting selected_value from code doesn’t work, that’s a bug! Can you produce a test app that shows it not working?
I just built an app that initialises two DropDowns, and also sets them before opening the form. It appears to work:
https://anvil.works/ide#clone:FKDOSYHIZEVCNQ6T=3NVCPX63DEJ4ZAB3GO3QK4Q7
It could certainly have been my bug. I’ll work on a minimal example. I’ll pull the necessary parts from the framework I’m working on. It’s where I experienced the bug.
Try this one:
https://EA5GFJTUXEIDM5M7.anvilapp.net/NXFC4AZBEK2R5VVF4ZZCCDTN
This is part of a framework intended for dynamically-built pages, for a questionnaire. The questionnaire is defined in a database table as a series of individual questions, of various data types. (Multiple-choice, integer, currency, date, …)
Each data type is represented by a corresponding type of form (I call it a Frame, as does Embarcadero’s Visual Component Library). That form is created on demand, and added to the page.
Much of the Frame’s code is commented out. Try it that way, and you’ll see that the DropDown works just as I described it. Uncomment the code, and you get a Frame that works more simply (from the outside).
I tried simpler code, with one less level of indirection (creating the DropDown directly in MainForm’s code), but that code behaved as you expected. It did not exhibit the behavior I experienced.
Two different behaviors from the same DropDown class. Something subtle is going on here. Maybe I have something going on out-of-sequence, here, but if so, it’s not obvious to me.
Can you post (or PM me) the Clone link, please? That lets me copy your app and data. I can’t tell much by just opening the app in my browser 
(I’ve also moved this to the “Bug Reports” forum. selected_value is supposed to work the obvious way, and if it doesn’t we will fix it until it does!)
Sorry about that. I don’t ‘clone’ very often, and I had to hunt for it.
https://anvil.works/ide#clone:EA5GFJTUXEIDM5M7=APA3FXXQ76Q6ZKQ2UR4SBF7T
That’s definitely a bug! Thanks for catching it, and I’ll let you know when we’ve shipped the fix.
Thank you!
Since I clearly have a workaround, it’s not pressing – for me. But consistent behavior is best for all (when feasible!).
Workaround update: selected_value works as intended, if you set it from code first. So if, in your init method, you do:
self.drop_down_1.selected_value="foo"
…then it all works (assuming "foo" is one of that component’s items). And from then on, selected_value will reflect the value selected in the DropDown.
(Obviously, this is just a workaround, and we’ll get the actual bug fixed soon! But I thought I’d tell you how to work around it in the meantime…)
If memory serves 
, that’s the first thing I tried. But in my test at the time, only clicking the button, and using it to actually change the displayed text, had any effect on selected_value. (Hence my bullet point to that effect.) But there have been several (important!) software updates since then…
We know you folks work hard. Thank you for all your efforts! 
Just so you know, we have finally nailed down and fixed this bug. We’ll be releasing the fix in the next few days.
1 Like
I can start to imagine the effort that went into that. I nest forms, a lot. Looking forward to simplifying my code. Just say when, and I’ll get to it.
Much appreciated! 