I want to put either a dash or the word ‘to’ between StartDate and EndDate
But some events will not have an EndDate. In those cases, both the dash and the EndDate should not display.
Because the EndDate field is a time field, the only options are “If EndDate is after, or before, or between”. There is no option for “if EndDate is empty”.
How do I make the dash not visible when there is no EndDate?
What I’ve done is add a dummy field to the collection, (text type) that will serve as a double for your “end date”. I have been using the prefix “txt” to define these fields so I won’t confuse them with their “real” counterpart.
Then, whenever in your app you’d write or modify a date in your collection from an input (like date/time picker), make sure to ALSO write/modify its accompanying text field. Thus, you can use the text field to control visibility rules for the functionality you describe.
It’s an awful workaround, and clutters up your collections, but it’s the only way I’ve found to get both sides of the cookie when it comes to dealing with time/date in adalo. It can be frustrating to hit these little conundrums and weird lapses in functionality, but I have great faith that they’re working every day at Adalo to make the platform better, so for now Im usually just grateful to find these workarounds as I need them to squeeze the functionality I need out of a fantastic but nascent platform/technology.
Boy, I hate that idea, but it’s a great solution! I never considered the idea of linking the date field to another field to control visibility. Thank you!
That led me to another idea. You don’t actually need to write the date in the text field. You just have to have “something” in that field. And THAT made me think of a true/false toggle.
I’m going to add a “EndDateExists” toggle to my collection. If that toggle is TRUE, the dash will be visible. If it’s FALSE, the dash will not be visible.
Thanks so much! Your suggestion solves my problem!
For sure! If you ONLY need to know Boolean true/false, it’s a great idea to use the true/false field. However, that field type can sometimes have it’s own limitations within the intricacies of building out logic and functionality within your app (it should work super for your specific use though!). I know for my use cases, it has been handy to have the date replicated as text for certain operations, and sometimes even stored in a number field to allow for more reliable math operations when adding/subtracting/modifying time data (Adalo will store it in “Unix” numeric format).