Is it possible to configure the date picker to only allow selecting dates in the past? I want to restrict users from choosing a date that doesn’t indicate they are at least 16 years old. So, when someone attempts to select a date, it should show a date that is 16 years or more in the past. For example, if someone is using the app today (09/11/2023), the date picker should display 09/11/2007 or earlier, and no dates beyond that should be available for selection
No, you can’t do that natively.
But if you’re willing to use a Custom Form, you can create your own validation rule to prevent the user submitting if they enter a date that’s outside an acceptable range.
Is this not still an option???
Or are you looking for a more custom range?
They want a date that is at least 16 years in the past.
Hi @Darren_Murphy, Thank you for your prompt response. I appreciate your insights. I find myself facing a bit of a challenge here. It seems that what I’m working on doesn’t align with using a Custom Form, at least based on my attempts.
If I’m understanding correctly, a Custom Form typically relies on the User Profile, which, in turn, is linked to the User Table, correct?
Now, the application I’m developing won’t involve user logins, rendering the User Profile irrelevant in this context.
Unless I’m missing something or have misunderstood this, I would greatly appreciate your expert input.
I will add that I am using a form screen instead.
Yes a date 16 years in the pass is correct.
I saw that but it is not what I am looking for. Thanks.
Custom forms do not require the user to be signed in and they don’t have to use the user profile table. Any table can be used for a custom form. In fact they work better when users aren’t signed in because it doesn’t count as many updates as a custom form would when you are signed in.
@Jeff_Hager, I seem to be encountering an issue, and I suspect I might be overlooking something. I have a button block, and I’ve configured it to show the detail screen. However, when I navigate to the detail screen, I see a list of tables including the User Profile table and another table called ‘Customer,’ but the table I want the file to update is not visible.
I’ve attached some screenshots for your reference. Could you please take a look and let me know if you spot what I might be doing wrong? Your insights would be greatly appreciated. Thanks for your help.
If you want a custom form to use a specific table, you need to set that table as the source of that screen. Seems that your screen is using the Customer table as it’s source instead. You need to change your button action to show the detail screen for your custom form table.
That’s my dilemma, I do not see an option to change the source anywhere. Can you send me a quick screenshot on how you accomplish this?
Ok. I had to open up the builder to double check and you are correct.
When you use ‘Show Detail Screen’, your only options are the user profile or the current table.
This leaves you with two options:
The easy option is to instead use ‘Show New Screen’, which will give you access to all tables.
This will work perfectly fine if you only plan to open that custom form from one place.
The more complicated (but better longterm) solution is to first create a single relation → whole row in the customer table that retrieves the first row from your custom form table. This is essentially the same as a single row relation.
Then you can go back to using ‘Show Detail Screen’ and the single value row will show up as an option.
The only reason I would recommend the second method is if you want to reuse that same custom form elsewhere in your app without making multiple copies. Also, there is less of a risk of losing it. Detail screens are always linked to their source table forever, whereas New screens are independent and only linked to their specific instance instead of being linked to the table. If you lose a New screen it’s gone. If you want to reuse a New screen somewhere else, you can’t. Detail screens are safer for the long term, especially for custom forms. The design is forever linked to the table, so it’s a lot easier to reuse elsewhere in the same app.
Hope that all makes sense. Get’s a little into the fundamental underworking of Glide.
@Jeff_Hager, This makes perfect sense and helps very well. Thank you for being very detailed.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.