The message string in EMAIL_SEND_NOPROFILE() gets chopped with certain characters

[acceptthis]

I use email_send_noprofile() to send data that was entered on an iPhone. Some of the characters aren't being translated and cause parts of the message to be dropped or changed. I know that the dash character causes problems. In fact, it's a certain dash that will cause the problem while another doesn't. Here's a screen shot I took of the data in the sql file:
thumb_47644.png
You can see that they are different. One is longer than the other, and the first dash doesn't cause a problem, but the second one does. I assume characters will also cause problems.

First, has anyone else had this problem and found a solution?

The closest function I've found to do what I want is REMSPECIAL() to strip the message of all non-alphanumeric characters, but without the spaces, it makes the message unreadable. Is there another Xbasic function? Or is there JavaScript that would strip/clean it up first on the phone?

Thanks for reading,
Brad

[mikeallenbrown]

Can't see your screenshot because it's too small. Anyways, I supposed you could use stritran() in xbasic. Alpha documentation: https://documentation.alphasoftware....20Function.xml

I think the better way is to handle this through JavaScript before is gets to the server. The replace() function is the JavaScript you could use. Maybe replace this short dash with the long one.

[acceptthis]

thanks for the reply. Sorry about the screen shot. it is tiny.

I'll test stritran() and then read up on replace(). Unfortunately, I don't think there's a function that will catch all the offending characters at once. I'll probably have to fix them one at a time. I wonder if this problem is occurring at my email server because the text is fine when in the debugger.

[acceptthis]

It appears that I'll have try and catch it in JavaScript first. stritrans() needs the right character to replace, and when I put in the dash, it replaces the ones that don't create the error and not the one that is giving me the problems. I don't even know the ascii value of the offending character.

[acceptthis]

For now, I'm going to uncheck "use special characters" in validation rules to keep the user from using special characters. Unfortunately, I won't be able to use periods, commas, dashes, etc.

2023-04-16 (1).png

[acceptthis]

For those interested, it wasn't as hard as I was expecting. I put this code in the "onBlur" event:

var str = {dialog.Object}.getValue('FIELD');
var newStr = str.replace(/-/g,'... ');
{dialog.Object}.setValue('FIELD', newStr );

HOWEVER, in testing I found the real problem. It occurs when using dictation on the iPhone. If I say, "dash," it inserts a different character than the keyboard dash. So, I don't know how to fix it because I don't know how to reference the character that Apple Dictation is inserting. If I don't know what the character is, I don't know how to replace it. Android, on the other hand, inserts an actual dash.

Crazy....

[Russell Craycraft]

Can you copy and paste the character that Apple Dictation is inserting?
Also you may want to try this code:

var str = {dialog.Object}.getValue('FIELD');
var newStr = str.replace(/[^\w\s]/gi, '');
{dialog.Object}.setValue('FIELD', newStr );

This should replace any character that is not a word character (a-z, A-Z, 0-9, or underscore) or a whitespace character.

[acceptthis]

Hey Russell,

Thanks for the reply. I'll give that code a try.

This is the dash apple inserts –
this is the normal dash -

I've put it through a few ascii converters online, and I get different numbers from them. At this website: https://www.binaryhexconverter.com/a...imal-converter I get 8211