percent sign wiping out remainder of field input

[SK]

I am having an issue with the percent sign keyed into a text field on my iForms causing the remainder of the field to disappear from the prompt in the HEO order.  Has anyone else encountered this?  What is the workaround?  Thanks.

[Michael Hudson]

There is no work around that I know of, just spell out percent. It seems to be the command to ignore everything after it in the string.

On Tue, Mar 10, 2015 at 4:19 PM, SK <sue.ka...@atlantichealth.org> wrote:

I am having an issue with the percent sign keyed into a text field on my iForms causing the remainder of the field to disappear from the prompt in the HEO order.  Has anyone else encountered this?  What is the workaround?  Thanks.

--
You received this message because you are subscribed to the Google Groups "HEO iForms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to heo-iforms+...@googlegroups.com.
To post to this group, send email to heo-i...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/heo-iforms/111b2fee-1cd2-41d2-b230-36dfcf40338a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Scott Morris]

If you know your way around javascript, you can prevent the users from using the "forbidden characters."  I've made much of my jQuery code freely available here https://github.com/scott-morris/jquery-iforms (the raw file can be found at https://raw.githubusercontent.com/scott-morris/jquery-iforms/master/src/jquery.iforms.js ).

If you take a look at the "maskInput" function starting around line 63, you'll see that the function checks for user keypresses and prevents certain key combinations from working (namely those that make the percent sign among other things) as well as pulling them out of pasted values.  To implement it, you'd need to add this code to your page and, where you do your other "on page load" functionality, add a line to $("input:text").maskInput();

Hope that helps!

[SK]

Thanks very much for sharing your code.  I appreciate the help.     

[TWessel]

And here is a way to do the same thing without jQuery if you prefer:

function stopRKey(evt) {

var evt  = (evt) ? evt : ((event) ? event : null)

var node = (evt.target) ? evt.target : ((evt.srcElement) ? evt.srcElement : null)

if ((evt.keyCode == 13) && (node.type=="text" || node.type=="checkbox" || node.type=="select" || node.type=="radio"))

return false

else

return true

}

document.onkeypress = stopRKey;

function ckspecchar(thisobjvalue) {

var myform = document.forms[0]

var reservedChars = "%+@\\`~&"

var i

myform.errmsg.value = ""

for (i=0; i<thisobjvalue.length; i++) {

if (reservedChars.indexOf(thisobjvalue.charAt(i)) != -1) {

myform.errmsg.value = "You have typed a reserved character ( %  +  @  \  `  ~  or  & )  Please replace it with other text."

document.getElementById('errmsg').focus()

return false

}

}

return true

}

Comment: The ckspecchar() function is coded to be activated by an onBlur() event in a text box control.

____________________________________

Tom Wessel, MD

CMIO

SRHS

Spartanburg, SC

On Tuesday, March 10, 2015 at 4:19:03 PM UTC-4, SK wrote:

[SK]

What's scary about this is that prompts after the prompt with the reserved character are also impacted.  Thanks for the help!    

[Scott Morris]

Yeah, there was some discussion about these special characters a couple years back and saw that the different characters would do different (and sometimes weird) things. https://groups.google.com/d/msg/heo-iforms/fEWhvDFGRc8/4GTMxDH4wtAJ

[ckittred]

I think that these characters don't work because they are not being correctly serialized during the form POST. To get them working all you need to do is convert them to URL encoded format - javascript can do this for you with the encodeURIComponent method. I call this method on form submission for all user-facing text fields, works great

On Tuesday, March 10, 2015 at 10:21:40 PM UTC-4, Scott Morris wrote:

[Kaenrath, Sue Ann]

This sounds like a great solution.  Could there be any issues with downstream applications not displaying the URL encoded special characters properly?   Thanks for the help!

--

You received this message because you are subscribed to the Google Groups "HEO iForms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to heo-iforms+...@googlegroups.com.
To post to this group, send email to heo-i...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/heo-iforms/8fb3296e-f421-4b3b-b01d-627c746a3851%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

The information contained in this email is intended only for the use of the person(s) identified above. This communication may contain work product which is privileged and confidential, and may contain content which is regulated by Federal law. If you are not an intended recipient or the employee or agent responsible to deliver this to the intended recipient, you have received this message in error and any review, distribution or copying of it by you is prohibited. If you have received this message in error, please notify the sender immediately, and delete the message. E-mail and communication system messages generated by members of the Atlantic Health System workforce may not necessarily reflect the views of Atlantic Health System, its officers, directors or management.

[ckittred]

I've been doing this for ~2 years with no complaints. I can't say for sure, but I believe this is how the VGR iForm passes values back to Clinicals anyway so it is perfectly safe. HTML form data is always URI encoded in key->value pairs, and things like & and % have a special meaning. So I believe it's just a shortcoming of the VGR/iForm engine that these values are not being encoded like the rest, so it must be done manually.

You have to be careful how you implement the encodeURIComponent method though to make sure it happens ONLY ONCE or else you can get garbled results (encoding already encoded values). This can happen if you're doing any JS that can cancel the form submission event, such as form validation. I use a jQuery deferred object to help keep track of the form state and fire these kinds of functions at the right time. Let me know if you need more information about that

On Thursday, April 2, 2015 at 11:15:29 AM UTC-4, SK wrote:

This sounds like a great solution.  Could there be any issues with downstream applications not displaying the URL encoded special characters properly?   Thanks for the help!

 

From: heo-i...@googlegroups.com [mailto:heo-i...@googlegroups.com] On Behalf Of ckittred
Sent: Wednesday, March 25, 2015 10:10 AM
To: heo-i...@googlegroups.com
Subject: Re: percent sign wiping out remainder of field input

 

I think that these characters don't work because they are not being correctly serialized during the form POST. To get them working all you need to do is convert them to URL encoded format - javascript can do this for you with the encodeURIComponent method. I call this method on form submission for all user-facing text fields, works great

On Tuesday, March 10, 2015 at 10:21:40 PM UTC-4, Scott Morris wrote:

If you know your way around javascript, you can prevent the users from using the "forbidden characters."  I've made much of my jQuery code freely available here https://github.com/scott-morris/jquery-iforms (the raw file can be found at https://raw.githubusercontent.com/scott-morris/jquery-iforms/master/src/jquery.iforms.js ).

 

If you take a look at the "maskInput" function starting around line 63, you'll see that the function checks for user keypresses and prevents certain key combinations from working (namely those that make the percent sign among other things) as well as pulling them out of pasted values.  To implement it, you'd need to add this code to your page and, where you do your other "on page load" functionality, add a line to $("input:text").maskInput();

 

Hope that helps!

On Tuesday, March 10, 2015 at 4:19:03 PM UTC-4, SK wrote:

I am having an issue with the percent sign keyed into a text field on my iForms causing the remainder of the field to disappear from the prompt in the HEO order.  Has anyone else encountered this?  What is the workaround?  Thanks.

--
You received this message because you are subscribed to the Google Groups "HEO iForms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to heo-iforms+...@googlegroups.com.

To post to this group, send email to heo-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/heo-iforms/8fb3296e-f421-4b3b-b01d-627c746a3851%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kaenrath, Sue Ann]

Yes I would like to know more about using the jQuery deferred object.  Thanks!

To post to this group, send email to heo-i...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/heo-iforms/0357da5f-663f-4f57-bda6-71400bd07dc7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[ckittred]

Sure. First, of course, you need to include the jquery library in your iform via a <script> tag

I then declare various deferred objects in the global scope at the top of my script:

var formPassesValidation = $.Deferred(); //this promise object resolves when the form has been submitted and there are no validation errors

We then have a customValidation() function that fires form the form onsubmit event. Its basic structure is this:

function customValidation() {
  var errorFlag = false;
  var errorMessage='There are issues that need resolved:\n\n';

  if ([javascript]) {
    errorMessage += 'Blah blah\n';
    errorFlag = true;
  }
       
  if (errorFlag==false) {
    formPassesValidation.resolve();
  } else {
    window.event.returnValue=false;
    alert(errorMessage);
  }
}

Next, the character encoding function:

function fixSpecialChars() {
  $.when(formPassesValidation).done( function() { //resolves when the form has been submitted and there are no validation errors
    $('input:text').each( function(i,e) {
      e.value = encodeURIComponent(e.value);
    });
  });
}

Finally you will want to initialize these two functions on page load:

$(document).ready(function() {
  $('form').on('submit',function() { customValidation() });
  fixSpecialChars();
});

Any function that you want to run on the form submit event can make use of this deferred object model

To view this discussion on the web visit https://groups.google.com/d/msgid/heo-iforms/0357da5f-663f-4f57-bda6-71400bd07dc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[SK]

Your script has been working well but now I have run into the same issue with textarea entries.  I tried modifying your script as follows but it doesn't work.  Do you have any suggestions as to what I can try?  Thanks.

$('input:text').each(function(i,e)   {

if (! e.value == '')  {

e.value = encodeURIComponent(e.value);

}

})

$('input:textarea').each(function(i,e)   {

if (! e.value == '')  {

e.value = encodeURIComponent(e.value);

}

})     

[ckittred]

A textarea is not actually an input, it's own element type. Try modifying the second block to start with this: $('textarea').each(function(i,e)   

[Scott Morris]

Additionally, if you want the same code to apply to both, you could also do something like this:

$('input:text, textarea').each(function(i,e)   {

if (! e.value == '')  {

e.value = encodeURIComponent(e.value);

}

})

To post to this group, send email to heo-i...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/heo-iforms/069f450d-6d98-4c97-95d3-26413c0b0fe0%40googlegroups.com.

[Kaenrath, Sue Ann]

Modifying the second block to “$('textarea').each(function(i,e)” works.   Sorry Scott I could not get “$('input:text, textarea').each(function(i,e)”   to handle the textarea.  Thank you both for the help.  

To view this discussion on the web visit https://groups.google.com/d/msgid/heo-iforms/CAE50V566HHDWyjRNanGtQtNcAW%2B4FHLidyzYWfpH0UTggSUeyA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[SK]

I have run into another issue - the script doesn't work when using the web client to place orders.  Does anyone have any suggestions as to what I can try to determine why this is happening?  Thanks.