nmarples

Nintex Workflow - Build String Action Inserting Non-Breaking Spaces

Discussion created by nmarples on Feb 26, 2018

This doesn't really deserve an entire blog post about, but I figured I would make something here as a small reminder to check the tiny things when something isn't working or has broken for no obvious reason. 

 

It would seem that the Build String action in Nintex Workflow has what I would consider to be a bug. If you use the Insert Reference button to open the reference dialog, any time some of the times you hit the space-bar, the character inserted is not a standard Space character (aka: 0x20 or in UTF-8: %20), instead you actually get what is called a Non-Breaking Space (0xA0 or in UTF-8: %C2%A0)! 

Despite them being different entities, they are visually the same, making it very difficult to tell them apart. 

You can test this by simply opening the Build String Action, clicking on the Insert Reference button, inserting a few spaces, and then copy / pasting that output into a hidden character checker such as (View non-printable unicode characters). 

In the following example I have three lines of text. The first part of each line (That is the 'Line 1:', 'Line 2:', and 'Line 3:') are all done in the native Build String text editor, however, while the rest of the first line of text is also done using the Build String editor, the rest of the second and third lines are done entirely in the Insert Reference editor. 

 

Though visually there is nothing that stands about them (my special image markup-non included), copying an pasting that text in the hidden character finder page linked above reveals several bad characters. 

 

 

 

While our first line comes out with all of the regular space characters you'd expect, it seems as if every other space that was placed inside of the Insert Reference dialog is actually a Non-Breaking Space. 

I'm not sure why this is the case, but it certainly has bitten me a couple of times when checking something like variable equality, or URLs paths, as Non Breaking Spaces don't seem to be encoded in a way that makes SharePoint happy if you are using the returned FileRefs that contain them. 

It may not help you at all, but sometimes knowing the dumb little thing can save you a lot of time down the road. 

Can anyone at Nintex provide a reason as to why these characters are being inserted instead of regular spaces? 

My current environment is SharePoint 2016 with Nintex Workflow / Forms: 4.3.0.11

 

Thank you! 

Outcomes