Using Special Characters in Your Dropdown Boxes

Have you ever wanted to pull out your hair when trying to map a dropdown box with non-alphanumeric characters in it?  It happens all the time: someone builds an order with a prompt that has a greater-than (>) or less-than (<) sign, a comma (,), a plus (+), an equal sign (=), an "at sign" (@), a colon (:), or other "sacred" characters.

Let's look at some examples:

Colon Use:

    Dr. Smith
    Dr. Jones
    OTHER: SEE COMMENTS

Consult To: Dr. Smith Dr. Jones OTHER: SEE COMMENTS

Plus Sign Use:

    0 to 17
    17 to 25
    25 to 65
    65+

Age: 0 to 17 17 to 25 25 to 65 65+

Avoiding the Issue in the First Place

I've heard that some sites go through the process of updating their prompts and allowed / recommended value lists in the toolkit to change "OTHER: SEE COMMENTS" to "OTHER - SEE COMMENTS" or "65+" to "65 or older" and that is a viable option, but can be time consuming.

(NOTE: if your facility is still in the early stages of setting up HEO, do yourselves a favor and avoid these characters as a rule. The best practice is to avoid these issues in the first place)

What the Issue is and Why This Happens

When the iForm gets submitted, the values in your form elements go through a process known as URI Encoding. Your alphanumeric characters won't be affected, but "special" characters will often be encoded using this process.

When data that has been entered into HTML forms is submitted, the form field names and values are encoded and sent to the server in an HTTP request message using method GET or POST, or, historically, via email. The encoding used by default is based on a very early version of the general URI percent-encoding rules, with a number of modifications such as newline normalization and replacing spaces with "+" instead of "%20". The Internet media type of data encoded this way is application/x-www-form-urlencoded, and it is currently defined (still in a very outdated manner) in the HTML and XForms specifications. (Wikipedia)

How to Work Around the Issue

Since VGR can deal with these special characters within itself, we just need to pass a value from the HTML to the VGR that does not get impacted by the URI encoding.  Then, in our VGR, we check for those specific value(s) and set it "back" to what it was originally.  Going back to our examples above:

Colon Use:

HTML

    Dr. Smith
    Dr. Jones
    OTHER: SEE COMMENTS

VGR

EDIT,IF,,cboExample1,EQ,"OTHER",THEN
EDIT,SET,,cboExample1,TO,"OTHER: SEE COMMENTS"

EDIT,IF,,chkExample1,EQ,"true",THEN
EDIT,SET,,orderstring,CAT,"@LOAD_ORDER=OIS=11111^^^OOS=0^^^111=`cboExample1"

Plus Sign Use:

HTML

    0 to 17
    17 to 25
    25 to 65
    65+

VGR

EDIT,IF,,cboExample2,EQ,"65 plus",THEN
EDIT,SET,,cboExample2,TO,"65+"

EDIT,IF,,chkExample2,EQ,"true",THEN
EDIT,SET,,orderstring,CAT,"@LOAD_ORDER=OIS=22222^^^OOS=0^^^222=`cboExample2"

This code here just changes the value in the dropdown box variable to be just as if it had originally contained the characters, but since we're adding back the special characters from within the VGR it does not go through the URI encoding process and can be used just like any other variable.

Further Reading

• http://en.wikipedia.org/wiki/Url_encoding
• http://www.w3schools.com/tags/ref_urlencode.asp

Scott Morris is available for training, mentoring, troubleshooting, and iForms consulting. Find out more at www.thinkiforms.com