Skip to main content

I’m no regex expert but I’ve managed to fudge together what I thought would be a functional check for whether a form filler is trying to use new line characters in text fields. My regex is:

(?<=l^\r\n])\R(?=R^\r\n])

It looks like it should work:

 

But when I implemented the regex in my web form entering anything in the field results in the input failing the validation check:

 

What am I missing? Do web forms use new line characters as part of the field? Why would a single word with no spaces or anything match my pattern?

@gulf5724 

If your goal is to simply detect the presence of newline characters in any text input, a simpler approach might be more effective: g\r\n]

This pattern will match any occurrence of \r (carriage return) or \n (newline) in the input. This is generally sufficient for detecting newline characters in text fields.

@gulf5724

If your goal is to simply detect the presence of newline characters in any text input, a simpler approach might be more effective: >\r\n]

This pattern will match any occurrence of \r (carriage return) or \n (newline) in the input. This is generally sufficient for detecting newline characters in text fields.

It still fails the validation check:

 

 

Anybody else have any ideas? It seems like it should be working….

Hi @gulf5724,

 

Thank you for sharing your experience.

Are you selecting “Long Text”, as part of your text box settings?

Best regards,   

 

Alejandro R. | Docusign Community Moderator   

"Select as Best" below if you find the answer a valid solution to your issue!   

​

 

 

@gulf5724 

Can you explain the use case and why you want to filter out the new line breaks?

I came across the issue with new line breaks working with SharePoint, when the text field is defined as multiple lines of text. This can result in issues when you pass the values via API to Docusign. 

Another use case I saw before is when people copy and paste data from an Excel file, where the data fields included line breaks, which caused some trouble with document generation and workflow processes in CLM.

Hi @gulf5724,

 

Thank you for sharing your experience.

Are you selecting “Long Text”, as part of your text box settings?

Best regards,   

 

Alejandro R. | Docusign Community Moderator   

"Select as Best" below if you find the answer a valid solution to your issue!   

​

 

 

Yes.

@gulf5724

Can you explain the use case and why you want to filter out the new line breaks?

I came across the issue with new line breaks working with SharePoint, when the text field is defined as multiple lines of text. This can result in issues when you pass the values via API to Docusign. 

Another use case I saw before is when people copy and paste data from an Excel file, where the data fields included line breaks, which caused some trouble with document generation and workflow processes in CLM.

Its because employees entering line breaks into the web form fields allowed text to escape the desired bounds of the defined area on the completed PDF agreement.

 

I did not figure out why my regex didn’t work, but I was able to accomplish the same end goal by simply changing the problematic fields to short text. This prevents users from entering new lines.

It sounds like you initially tried to use a regex pattern to prevent new line characters in a form field, but it didn’t work as expected. The issue might be that web forms often handle text differently, and your regex could be matching unintended cases.

If changing the field to "short text" worked for your use case by preventing new lines altogether, that's a practical solution. Sometimes, simpler fixes like adjusting the field type can be more effective than complex regex patterns, especially when dealing with web forms.

If you still need to use regex in the future, you might want to double-check how the text is being processed and whether there are any hidden characters or formatting that could affect the regex behavior.

It sounds like you initially tried to use a regex pattern to prevent new line characters in a form field, but it didn’t work as expected. The issue might be that web forms often handle text differently, and your regex could be matching unintended cases.

If changing the field to "short text" worked for your use case by preventing new lines altogether, that's a practical solution. Sometimes, simpler fixes like adjusting the field type can be more effective than complex regex patterns, especially when dealing with web forms.

If you still need to use regex in the future, you might want to double-check how the text is being processed and whether there are any hidden characters or formatting that could affect the regex behavior.

How would I double check how web forms process text? It would be helpful to know this for the future.

Reply


Code of Conduct