@Darren_Murphy thank you so much for this. I’m totally inspired by your ideas and I’m trying to implement them on my app. I am bumping into one big problem…the “edit” button I added, won’t click! I duplicated everything you did on your app, so not sure what the problem is.
Being able to avoid duplicate entries (before they are created) is a nice side effect of using custom forms.
If you’re using the standard Open Form method, then I’m not aware of any way you can stop duplicates from being created. So I guess it depends on whether or not that is important for your use case.
I haven’t tried but if you prefer the modal form @ThinhDinh suggests you could conditionally hide the submit button using CSS.
I’m actually in the process of redoing one of my larger forms in a details view. Copy paste all!! Thanks @Darren_Murphy for the custom forms write up. I like your use of the ITE column to decide if we could save or not.
My question was not accurate, sorry: my issue is that I need to create a Custom Form (cannot use the standard Open Form component), but I was wondering if I could do it without using the User Specific columns in addition to the ones which records the values?
(the reason being that I have 50 questions, so using User Specific would mean x2 in terms of columns).
Incidentally, I have another issue: when I create my custom form with a “link to screen” button, I always have the value of the current row (which is not the case in your application).
Do you have any clue on this?
If I understand it correctly…or at least how I do it…is that I have a custom action that clears the USC columns prior to the Link To Screen action, and/or I clear the USC columns in a custom action after first Adding the Row. You shouldn’t be adding a row prior to the Link to Screen action. Really, in most cases, you will be editing the same (most likely the first) row every time you use and submit the form.
One suggestion I have is to create your 50 USC columns, but in a separate table with only one row. It will just be a work table to temporarily hold data while filling out the form. That way you can keep it separate from your form response table. Display your tab or screen using that new work table, fill out the form, and have it submit to you existing form response table.
Yep, this is what I usually do. Although sometimes I’ll leave the user specific columns intact, and use them to build a CSS table to present the row that’s just been created, and give the user an opportunity to review and/or edit it. So I’ll show the user the table, plus a button bar with “Edit” and “Go Back” options. If they choose Edit, then they get an edit form pre-populated with the User Specific values, and if they choose “Go Back”, only then I’ll clear the User Specific columns.