trying to show something if the number selected is in an array. It works other than when i clear the form, the menu option for this visibility component is “clear” or “undefined”. The clear or undefined value is being counted as an option in my array, so my element shows when really it shouldn’t.
You’re not actually checking an “array”. You’re really checking if that selected number is included in the text string of [1,2,3] (including the commas and brackets). So what that means is that if your choice component also included a comma or a bracket as a valid choice, those would also make for a true condition. It’s just comparing text to text. There is no actual array involved.
With that said, I would try changing your condition from [1,2,3] to simply 123. The extra commas, brackets, and possibly any spaces may be what’s causing the issue and a cleared column is actually finding a match somehow. My first guess would be that you have a space in your compare, but it’s hard to tell for sure. Regardless, you don’t need to structure the compare in a special way. ‘is included in’ just looks for a match within the text string.
2 Likes
If you want to check if it is 1 or 2 or 3, can you just try to check if it’s not 0 and it’s not empty?
1 Like
Adding to @ThinhDinh Based on your last few comments in the video I think you want the form to be empty (not-visible) if the first choice [Temp Rider Number] is empty or if it is 0. Upon entry, the first choice should be empty and the user can select (0,1,2,3) to get the desired visibility of options.
What is in the DATA for Temp Rider Number when you enter (when it should be cleared). If it is empty I think you can do what @ThinhDinh suggested. If it contains a value (0-3) then your logic should work. Some other value and that could be a problem.
PS. Just setting first Choice to 0 seems intuitive also.
3 Likes
@Jeff_Hager thanks for the clarification. Good to know for future use. Changed it to 123 but unfortunately still acts the same way.
@ThinhDinh The reason i can’t do that is because some of the items that i have to hide already have a visibility condition attached to them. So for example the one i showed in the video shows only if “sign only” is selected. Because of that, any condition i stack ontop of it has to be an AND condition. So it works if i only had one condition. But because i have to put “not empty” and “not 0”, the system takes it as i needs to be “sign only” AND “not empty” AND “not 0”. What i need it do do is “sign only” AND [“not empty” OR “not 0”]. Thats what i thought i did when i mistakenly got it to somewhat work with the “is included in”.
@MattLB When people navigate to it for the first time, it will be “empy” or “clear”. If people click on any of the numbers, they won’t be able to get back to the “clear”. It will re-clear when people either hit the reset form button i created at the top of the form, or they submit a successful order. I initially did @ThinhDinh’s version but note what i said about elements already having a visibility condition attached them.
So it has to work with the empty version as well as 1, 2, 3? You can just put “not 0” in there.
Here is a little expert tip for you. Any time you find yourself with two or more visibility conditions on a component, have a serious think about moving the logic to the Glide Data Editor. This is where you can mange all your and/or/but logic much easier. You might not think it’s possible, but in 99% of cases it is. It just requires a little creative thinking.
So instead of a visibility condition that goes like:
column X is true
and column Y is not greater than 10
and column Z includes "moo cows"
and email is not signed-in user
and blah blah blah.....
…you move all that complicated logic to the GDE and set it up so that it resolves to a single true or false.
And then your component visibility condition becomes something like:
show-component-group-XYZ is checked
Where this approach starts to pay huge dividends is when you have many related components that use the same set of visibility conditions.
3 Likes
Curious on other people’s thoughts, but I wonder if there is in fact a bug with ‘is included in’. Seems that a null or blank value shouldn’t be picked up and result in a true condition in this case. To me it seems like it should work as intended.
@apaschea I think an easy workaround fix for this would be to create an IF column that returns 0 if the column is empty, else return whatever value is in the column. Then use the IF column value in your condition. That way it will always have a numeric non-empty value, to compare to. But also seriously consider what @Darren_Murphy said, because that will make your life much easier.
1 Like
I believe it’s a yes for me. I have to include “is not empty” a bunch of times to deal with it.
Like if null is included in “A/B” (my work around for not using an OR), it will return true.
2 Likes
Depends how you look at it, eh?
Technically, the null value is “included in” every string, right?
So to return true in that case is probably correct behaviour.
Of course, as Jeff pointed out, the easy “fix” if that’s not desired behaviour is to first check for null/empty and short circuit if that returns true.
2 Likes
@Darren_Murphy Thanks for the tip. Looks like i will be doing a lot of that shorlty. I think i just ran into another problem where the answer will be exactly what you described. Look out for my new post shortly!
@MattLB I just caved and ended up setting the first choice to 0.
Thanks to everyone who chimed in. Have a new problem so i’m sure you will see me posting very shortly in a new thread.
1 Like
A true revelation moment. Using “/” was something I played with in the past but couldn’t get it to work. Obviously I did something wrong back then as now it works like a charm.
That’s exactly what I did as I couldn’t get the “/” operator to work. Now, many of these ITE columns aren’t needed 
1 Like
I just did this technique for inline lists with a twist and it works smooth. I had your exact example - multiple components visible only when a complex “visibility “ was met but in this case it was an inline list. I set values to 0 or 1 depending if that row would be visible and then did a roll up/sum and if any item in the inline list was visible then the inline list would be visible.
Otherwise it would not be visible so I hid other components.
Alternatively, you can use true/false instead of 0/1 and for the rollup, use “Some True”.
1 Like
What are your thoughts on using a Query column for this? It seems like half the time I put in a Query column, everything slows to a crawl. I’m aware of the recommendation to use a relation before a Query, but what are some other pitfalls of Query columns?
Not sure that a Query column is the correct tool for creating complex visibility conditions. Although it could be part of the solution, depending on the use case.
I guess thats the thing. Every situation is slightly different, so there really is no one size fits all. It’s just a matter of understanding what each of the Glide computed columns can do, and how they can be used together. And then using that understanding to craft a solution for whichever particular situation you happen to be facing.
That post of mine that you replied to is just one of my personal mantras, a personal rule of thumb if you like. Early on in my Glide journey I found that managing multiple visibility conditions across several components would very quickly become quite cumbersome to manage, and error prone. I discovered that it was much easier to manage in the Data Editor (configure once, apply many times), and so that’s what I do 
I’m curious about that. I use it quite a bit, and I’ve not noticed any performance issues at all. Can you give a real world example where it’s caused a slow down?
Yes, with regular tables (ie. not Big Tables) it can sometimes be better to use a relation. Especially if it’s just a simple match with no conditions. The only reason to use a Query column with regular tables is if you want to match on multiple conditions, or order/limit the results. This is where it really shines, and can save so much work. I create a lot of HTML tables using templates, relations and joined lists. Normally I want to order the results. The only way I could do that in the past was with JavaScript. But now with the Query column it’s a breeze.
When it comes to Big Tables, there is no performance difference at all between relations and queries, so using either is okay.
1 Like
Thanks for the quick response Darren. I’m realizing I was conflating visibility and filtering when looking at this topic and filtering is where I’ve been trying to substitute a query for multiple conditions on a component.
I’ll see if I can replicate the performance issues with Query and do a screen capture if so. After getting “this app has become unresponsive” I backed away from trying to reduce the total number of columns by using Query.
I don’t have any need for Big Tables, but I always have a mix of Google Sheets and Glide Tables due to relying on Zapier.
My most common scenario for Query is in a work table with one row that is used for filtering a Jobs table on multiple conditions entered by the user.