Question

Formatting Issue When Form is Saved to Repository

Forms Laserfiche Cloud Business Processes

Updated March 15, 2021

asked on March 15, 2021

Hello, I'm having an issue with the formatting on a form when it gets saved to the repository. When reviewing the Form as a task, it looks great but when it gets saved to the repository one of my fields on a row with two other fields gets placed on a separate row.

What's weird is that I have two rows with three fields each and the first row stays fine. It's just the second row, third field on that row that gets placed on a separate row.

They all belong to the same class (.ThreePerLine) so they aren't formatted separately. I'm using CSS to increase the size of the labels and inputs for these fields so I'm guessing that's part of the issue along with the Save to Repository process resizing the form (even though the size is default 800px).

--------------------------------------------------------

A similar issue I'm having with the formatting is with an X-large multi-line field. I have a Collection on the Form that has a multi-line field in it. The field has it's own row in the collection and is set to X-Large so it takes up almost the whole row.

For some reason when the Form is saved, the field width is shrunk down to Large or Medium size and leaves like 40% of white space to the right of field.

--------------------------------------------------------

Anyone have any tips or recommendations how to keep the Save to Repo task from messing up the formatting?

Screenshots below:

How the form should look

How the form is being saved

0 0

Replies

replied on March 15, 2021

Something else worth noting is that any CSS set for input, textarea, or select elements directly is not going to work on the saved form. Saved forms behave like a read-only user task meaning all of the inputs are replaced by div elements containing the field values.

A good way to test your layout is to set up a user task assigned to yourself with the "make form read-only" box checked, temporarily divert your submissions through that user task and you can get a better idea of what it will look like in the saved copy and you can use the browser to inspect the page and test various changes to the styling in real-time.

3 0

replied on March 15, 2021

So if input doesn't work on the repository forms, is there something that will work to make the text in the fields larger?

Sorry I'm still very green with CSS

0 0

replied on March 15, 2021 • Show version history

You can probably replace input with .cf-field in the CSS to get the same behavior. There is a DIV element with that class that exists in regardless of whether it is readonly or editable - it's one level up from either the editable input element or the readonly DIV element.

1 0

replied on March 15, 2021

I usually just target the parent like Matthew suggested, and then for the "fine tuning" where I actually do want to target the child element, I just use wildcard and child selectors instead of specifying input, textarea, etc.

Here's a sample of some of the CSS from one of my more complex form layouts. Eventually, this won't be necessary once we are all able to update to version 11 and use the new layout designer, but until this this is my approach.

.inlineField,
.inlineDate {
  display:inline-block;
  vertical-align:top;
}

.inlineField .cf-field > :first-child {
  width:95% !important;
}

.inlineSmall {
  width:15%;
}

.inlineMedium {
  width:21%;
}

.inlineLarge {
  width:35%;
}

.inlineXLarge {
  width:42%;
}

.inlineXLarge .cf-field > :first-child {
  width:98% !important;
}

.inlineDate .cf-field > :first-child {
  width: 60% !important;
}

1 0

replied on March 15, 2021

Can you share the CSS (and any Javascript) code that you have that is impacting these fields?

0 0

View 4 previous replies

replied on March 15, 2021

Yea for sure!

.cf-formwrap input[readonly] {background-color:white !important;}

.ThreePerLine {display: inline-block; width: 30%;}
.ThreePerLine .cf-label {font-size: 16px; font-weight: bold; text-decoration: underline;}
.ThreePerLine input {font-size:20px; color: black; !important;}
#q1 .cf-xlarge {border: 0px; !important;}
#q16 .cf-xlarge {border: 0px; !important;}
#q17 .cf-xlarge {border: 0px; !important;}
#q18 .cf-xlarge {border: 0px; !important;}
#q19 .cf-xlarge {border: 0px; !important;}
#q21 .cf-xlarge {border: 0px; !important;}

/*Slip Table*/
.FourPerLine {display: inline-block; width: 23%;}
.FourPerLine .cf-field {text-align: center;}
.FourPerLine .cf-label {text-align: center;}
.FourPerLine input {text-align: center; font-size: 16px; color: black; !important;}
.NoLabel label {display: none;}
#q15 .cf-xlarge {border: 0px; !important;}/*Slip Date*/
#q11 .cf-xlarge {border: 0px; !important;}/*Slip Client*/
#q12 .cf-xlarge {border: 0px; !important;}/*Slip Activity*/
#q13 .cf-xlarge {border: 0px; !important;}/*Slip Hours*/
/*Slip Description*/
#q14 .cf-xlarge {border: 0px; !important;}
#q14 {border-bottom: solid 5px;}

I had to use the individual selectors to remove the border around the fields....I had them set to their respective classes but when I set the fields to Read Only it then ignored the border: 0px I had on the FourPerLine class, even when I had !important next to it.

But for whatever reason using the #q selector along with !important seem to resolve it

0 0

replied on March 15, 2021 • Show version history

Is the field you are having trouble with a currency field? If so, I think that could be the issue (the currency symbol). It's not exactly the same, but I have similar issues with the date fields and the date picker.

For a normal single-line field that I want sized to 25%, I do this:

.quarterWidth {display : inline-block; width : 25%;}

But with a date field, I need to add an extra line to adjust how the actual input field is sized within the larger Forms field layout:

.dateField {display : inline-block; width : 25%;}
.dateField .cf-xlarge {width : 80%;}

It may be the same kind of idea here where the forms field layout is being resized (lines 3 and 14 of your CSS), but the input field within it is wide enough that there isn't enough room to fit both the currency symbol and the input field.

0 0

replied on March 15, 2021

I don't think it would cause what you are seeing, but note that lines 1, 5, and 17 of the code you posted won't impact the archive/read-only version of the form, only the live version of the form. That's because the input elements don't exist on the archive/read-only version of the form. You can try doing .cf-field instead of input, that often impacts both versions of the form as that class exists in both cases.

0 0

replied on March 15, 2021

One way to test things out if looking at the submitted version of the form from inside Forms (either from a history view that lets you see the forms you previously completed, or from the Monitor page). The view here will be very similar to what is archived to the repository but has the benefit of allowing you to view the form in the browser with the capability to use the "Inspect Element" function of the browser, that not only allows you to see what parts of the form are doing what, but you can test little tweaks right there to see how changes impact the appearance without having to edit the form and submit it again.

0 0

replied on March 15, 2021

Also, I could be wrong on this, but I think having the semi-colon before !important will prevent !important from working.

/*   instead of this:   */
#q1 .cf-xlarge {border: 0px; !important;}

/*   maybe try this:   */
#q1 .cf-xlarge {border: 0px!important;}

0 0

replied on March 15, 2021

Yea I think you may be right about the currency field....I should have just used a text field and added a "$" to the token input but now all the variables are set I think I'll just try to change the width and see if that helps.

Any idea what's going on with the multi-line field? It doesn't have much CSS applied to it but is still getting resized when saved.

0 0

replied on March 15, 2021

I'm assuming that is the q14 field...

It does look like the field is being resized, but nothing is immediately obvious with the description field and the code you posted. I recommend trying to Inspect Element trick on both a live and a completed version of the form to see if you can identify the difference between the two.

If you are using Chrome, you can highlight different elements in the Inspect Element view and it'll highlight on the window, so it's easy to see what part of the field is shrunk down - such as the full field ul element for the field, the div that includes the cf-field class, the textarea element, etc.

0 0

You are not allowed to follow up in this post.

Question

Question

Formatting Issue When Form is Saved to Repository

Replies

Sign in to reply to this post.