Umb Is there a way to load the variable with just distinct values derived from a table? I've tried all combinations of the aggregate functions, with all variations of the distinct and group by options and nothing I try seems to work! What am I missing?
I assume that the road name is not a reference to another record (ie a road relation) but a text attribute. Usually, when you want to treat multiple things as the same (ie. if the same road name exists twice, I want 1 thing to be selectable as filter), you want to make that its own entity. Then you can use that as lookup as well.
You are limited, because our inputs (incl. variable inputs) for multi selection are only used for relationships. Road names are not relationship targets (assuming they are just text).
What you would currently have to do, is to generate a relation of unique road names. Then you can use that relation as filter, where you filter the road name in your list row with the name of the road name relation you populated with unique names.
Umb I've looked at the Search Bars (nice addition btw 😉) which sort of does what I want
If the global search mostly does what you need, there is no need for anything else. The search only uses a text input to compare one or many attributes with. This would work identically on any form with a variable input of the type text. This however does not give you a multi-selection input, as it´s just text.
Umb maybe including a few options like 'search for any term', 'ignore case', and 'whole word only'
Stuff like "any term" is available via fulltext-search (FTS) options, explained here:
Executing "whole word" searches are however not compatible with fulltext-search, but can be executed via regular comparisson operators - though these are very slow in larger datasets. We could not easily add this option to the global search, because it would break the search logic if FTS is involved. If you do not use FTS, you get character or full word search for free. It would be possible, if we separated the search bars between FTS enabled and not, but that would be very inefficient - It´s a complicated topic 🙃
Umb Also the restriction of their placement to only on the app bar is problematic for me, they would be far more useful as a form component ... maybe we could have an option on the search bar properties to be available either as a global search or as a form component?
The nice thing is that the global search does nothing different to any regular list field. There is no need for a form component, because you can replicate the exact same behaviour with a single variable text input and how many lists you want to search through - all being filtered via the text input from the variable. This also supports fulltext-search as well.
