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.
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.
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.
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.
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.
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.