Probably not needed now but here you go. I am trying to set the default choice in forms most of the time. PS: Same issue when adding a new component.
Probably not needed now but here you go. I am trying to set the default choice in forms most of the time. PS: Same issue when adding a new component.
Oh, THANKS! I had to use a rich text when some column was empty or to give an extra informationā¦ this will help a lot!
The change comes in the little details
Hello,
Obviously the default values āāare not available when an Entry Fields component is directly in a tab.
Only available in a form.
is it impossible to do or is it coming soon?
Same here. The default value is trying to pull from where the data is being entered into, and not the source sheet. But this is only on one of my apps, the other app, is actually being pulled from the source sheet. I canāt figure out what the difference is.
This is exactly what I was trying to explain, but done much better. Thanks Deena!
I can definitely see some scenarios where you may want the pull the choice default from the sheet that contains the form button. This would allow for different defaults based on the item you are viewing and especially for items like clothing, for example, where you might have a form with a choice component that has different sizes in the choice and built dynamically from a relation (based on the clothing item). So if you wanted the default to be āLargeā for some items and āSmallā for different items that may not have a āLargeā option, you could control that by having a template column or a default size column in the items sheet. So I think it has a place as it is now and can still be used by creating a template column in the item sheet, but I do agree that there should also be a simpler option to simply just select one of the choices, or at least let us type in the value, just like the default for text entry works.
Any chance we will see the actual Choice options in the default choice field soon?
My initial thoughts are that, functionally, a default value of a choice component would set a value that is from the choice dataset. The current behavior allows a user to set a default value that is not an option from the choice menu. It seems that this behavior is internally inconsistent to the purpose of the choice menu.
edit: I <3 glide
Yep, thatās why I (and Iām sure many others) are waiting for this to be fixed! It rolled out wrongā¦unless weāre all confused as to what the intention wasā¦
I am in the same mindset as you. I have a list of choices and I want to make one of those from the list the default.
Just want to state again that you can set a default on a choice component in a form. Just create a template column with the default value in the sheet that contains the form button. Then use that template value when setting the default on the choice.
But why should you have to do that, if you have a list of options already available?
I donāt want to do a workaround for something that rolled out wrong. But, Jeff, I love that you are all about getting it done right now!
Nothing rolled out wrong. We just havenāt gotten around to implementing picking a value from the options list yet.
I, as well as others thought it was supposed to work as we are explaining. If it didnāt roll out wrong then it was not explained effectively - either way we would love to have access to actual choice values to use in that default field! We are a very needy community!
@Deena @Ed_Pietrzak I donāt disagree at all, but itās a very minor setback if itās holding you up. I just want to make sure people are aware of their options. Again, I work as a developer (not for Glide). Iām not going to tell a user that I canāt do something that I know I can do because Microsoft Visual Studio doesnāt have the feature I preferā¦Iām going to do whatever it takes to get a feature or change out there as fast as I can. Many of my posts are workarounds. I canāt in good faith say ānope you canāt do thatā when I know there is a way to do it. Glide didnāt have a fraction of the features that it does now when I started using it. A large majority of things had to be done in the sheet via workarounds. Itās up to you to use them, but for the hundreds of others that read this post, it might be exactly what they need at this moment, so they at least have the option.
I wholeheartedly appreciate all of your posts Jeff and understand why you always offer workaround choices. This is not a minor setback for me. I already have ~50 choice components in my app and I donāt want to do and undo all that work. I agree that development never stops but I want to invest my time in building not doing and undoing. I donāt think any of us are disagreeing with each other - we are all humans with different approaches and principles in how we work! Your contributions in this community have helped me immensely. Thank you.
Completely agree. Itās not a huge deal for me, just would be nice. 90% of what I do at my paying job is workarounds, so I get that.
Honestly most of you, Bob or my replies are workarounds
Completely understandable. Nothing wrong with working towards getting it right the first time. And Iāll admit that workarounds have bitten me. (Ex. when I went through several screens, including some that are buried quite deep, to add progress bars as a horizontal line separatorsā¦then glide changing the style of the progress bar, which looked horrible in my appā¦then applying CSS to revert it backā¦then the CSS breaking.) Those are the types of things I can understand trying to avoid.
Itās not uncommon for me to see code at my job thatās been been there 10, 15, 20+ years. Nobody has time to go update it all and keep it current with the latest and greatest, so I get it. But if it works and doesnāt present a security or functionality problem, and is future proof for the foreseeable future, then we leave it alone so we donāt introduce unintended bugs. It still serves itās purpose and works as intendedā¦even if not the best method.