Checkbox state is not clearing out

Hello friends,

Need some urgent help.

I am using checkbox components to display image and file pickers. Checkbox components themselves have visibility constraints. The constraints on those checkboxes are the value of the checkboxes. When I submit the form, the value of checkboxes should clear out. But unfortunately they are not clearing out. This behaviour is seen both on desktop browsers and mobile browsers. When I am inside the Glide editor, this behaviour is not seen there.

Below is the video talking about the issue. Please help.

That’s a strange one. You may be better off using a choice component and then users can switch between photo and video on the fly with the same sort of UI. This would ensure that even if the issue existed, it wouldn’t matter because you’d still see the choice component.

1 Like

Thank you! Choice component worked well.

I think I’m having a similar issue, whereas it seems that the initial state of the unchecked box is not being recognized as ā€œfalseā€, which then affects visibility of components relying on the state being false when navigating to the tab with the checkboxes. The issue shows up intermittently in the GDE, but always in the browser. I can toggle the state from false to true, and then back to false and it solves the visibility issue in that browser instance.

The app is public, the checkbox components are user specific, RowID is used, and the first row already exists. I’m going to work on this more and make a video if I can’t solve it. I’ve already tried set columns to flip the state true then false, and I can see it working in the GDE, but not in the browser.

1 Like

Your best bet is to use a visibility setting like "is not – ā€˜true’ " — this will capture ā€œFalseā€ as well as empty values.

2 Likes

I just got back from a long dog walk and tried it out, it worked! Thanks so much for this.

The way that you mention, is this a best practice in software development? I’m not a dev and I wouldn’t have immediately chosen this condition as ā€œis - falseā€ seemed to be sufficient.

1 Like

In my professional life as a developer, I would say that yes, this is a common and recommended practice. I work with databases that are primarily alpha and numeric only, so it is very common for me to see code that stores and uses flags, such as Y/N or T/F, or 1/0. When a column has the potential to be empty from the from the moment it’s created, there is no guarantee that a programmer will deliberately set a default value to begin with. Most likely, they will set it to T, true, Y, 1, etc. when something desirable actually happens. It’s not likely that someone is going to set a value when nothing happens.

In the case of glide, a new row will only have values in the columns if you fill that value. If you didn’t set a default value when the row was created, then you can only assume that the column is empty/null. That means that a boolean column can potentially have three states (empty, false, and true). You are much safer to check for ā€˜true’ or ā€˜not true’ because you will always be setting a column value to ā€˜true’ through a user action, however, there is no guarantee what that initial default value will be.

Just to add to that, in some of the web development that I work with, there are a lot of times where I will have to check for Null, Nothing, or Blank for values that haven’t been set initially, so there can be many forms of an empty value. Not that it’s related here, but just to show that development can have a lot of gotcha’s if you only assume that it works one way on the surface.

4 Likes

Thanks, this is a very good description. Checkbox initial state is definitely going in the gotcha bin. The visual reference that the Checkbox is not ticked led me to the wrong conclusion. It’s not intuitive that there are really three possible states.

Still, the fact that the GDE behaves differently than the browser in this regards seems like a bug. It will bite more new no-coders than just me I think.

1 Like

User specific columns is probably going to be the reason right there. In the data editor, you are technically logged in as yourself by default, so whatever the last value you set for that user specific checkbox, will be the value that’s there whenever you come back to the editor. Meaning that whenever you check and uncheck a new checkbox in the editor, it will never be blank again unless you change to preview as a brand new user.

On a public app, user specific column values are never saved and are cleared out when the app instance is reloaded. Because of that, it will always default to blank until you interact with the checkbox.

The app is public, and I’m using user specific columns to change states, visibility, navigate tabs, and temporarily store info. At the end of a custom form I give the user the option to submit their name / email / comments, which I save in a separate Glide table that is not accessible in the app interface. I had been doing ā€œviewing as anyoneā€ to try to reduce the app maker influence on the function, and even logging out/in of Glide. My concern now that I have to figure out is if this saved user information is only visible to me.

I just completed the workflow and fixed most of the bugs, so you can check it out now: Do I Qualify?

I can finally focus on the content and UX, after a few weeks of just learning how to get to this point in Glide.

1 Like

Closing due to inactivity. This topic will be deleted in a few weeks if there are no more comments.