Sending SMS through Handi Rusli coding and Rahul Library

[mstrcmtr]

Handi Rusli of Komunitas Programmer FoxPro Indonesia Created Sms.Prg which use to send Sms through

Mobile Phone with IrDA and support AT Command (Nokia 6210, Nokia 6510, Nokia 8310, etc)

Rahul make Library of the same prg and created Pageframe and all required controls

Message Limit 160 Characters only

http://www.tek-tips.com/threadminder.cfm?pid=184

Message sending successful IF not use Chr(13) for line break in message e.g.

'Dear Customer' + ' Sale Invoice No 230 is ready ' && Successful

OR

'Dear Customer' + CHR(13) + ;
' Sale Invoice No 230 is ready' && UnSuccessfull

Attaching zip file containing all files available on net

What is the problem in Chr(13) or what use for Line Break in message

 

[Tore Bleken]

chr(13) isn't Line Break, it's Carriage Return. Chr(13) originally meant something like "put the cursor to the leftmost position on the same line". This means that the correct way to show two text strings separated by chr(13) is to put the to streings on top of each other, not below each other.

Quite a lot of equipment are "lazy" and show the two lines below each other, and as a consequence of this many programmers are "lazy" and only use chr(13) or chr(10) alone.

In order to be 100% safe, you should ALWAYS use chr(13) + chr(10). Btw, chr(10) is Line Feed.

 

[Olaf Doschke]

The message is sent with a closing CHR(13), so when you have an additional one within the message, that seems to cause the error.

That means you can't send SMS with CHR(13), you may try CHR(10) only, despite of what Tore Bleken said. Windows way of CRLF is not the worlds way and not a COM or Modem standard. The code does [tt].Output = cString + CHR(13)[/tt] which to me means the CHR(13) ends the message and so any further CHR(13) is introducing a new line within the SMS AT command being sent, a new command not starting with AT and so an invalid command.

If you google "SMS line break" you'll find very many discussions as this one in forums and there is no general standard, it seems to vary per GSM version or even per Mobile Phone, what to do. I'd simply live with SMS not containing line feeds, what sense do they really have with the 160 char limitation they have? So if a try with CHR(10) also fails, simply remove any CHR(13) from messages you want t0 be able to send, it'll even be better to remove any ascii code below 32, even tab (ascii code 9).

Bye, Olaf.

 

[mstrcmtr]

You are right Olaf ASCII codes are main problem CHR(13) + CHR(10) combining both will also not working

Client had showed someone message received on his mobile like this

Dear Customer,
Your Invoice # 4571-7654
Amount (45690.00 )
Dated 04/Apr/2016
Regards,
U.Z. Manager

What is the way to get this through coding i have

 

[mstrcmtr]

on Following site

http://support.nowsms.com/discus/messages/1/1137.html

How can use in coding

%0D = char(13) = \r (return)
%0A = char(10) = \n (newline)

lcEdt1 = ;
"Dear Customer, " + '%0A' + ;
"Your Invoice # 4571-7564 "

Tried but Not working adding this '%0A' resulting as added text in SMS

 

[JRB-Bldr]

As you can tell by looking at an ASCII chart...

Return (a.k.a Carriage Return) is Decimal 13​

New Line (a.k.a Line Feed) is Decimal 10​

So in VFP that would correspond to.

CHR(13)  && for Return 
CHR(10)  && for New Line

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

I don't see a general way to do this, Sorry.

Since \ and % and letters and digits are all valid SMS characters you also can't use that for line feeds.
Did you try CHR(10) only?

Bye, Olaf.

 

[mstrcmtr]

Work Successful

lcEdt1 = ;
"Dear Customer, "+CHR(10)+ ;
"Sale Invoice ready No "


------------------

Un Successful

lcEdt1 = ;
"Dear Customer, " + CHR(10) + ;
"Sale Invoice ready No "

 

[Olaf Doschke]

I see no difference.

Bye, Olaf.

 

[Olaf Doschke]

If you enter the message into an editbox simply do the following:

* first replace all CHR(13) entered (RETURN keys cause CHR(13)+CHR(10)) with CHR(10)
lcEdit1 = ChrTran(Thisform.Edit1.Value,CHR(13),CHR(10))
* then replace double CHR(10) with single CHR(10):
lcEdit1 = StrTran(lcEdit1,CHR(10)+CHR(10),CHR(10))

Bye, Olaf.

 

[JRB-Bldr]

mstrcmtr -- Work Successful

lcEdt1 = ;​

"Dear Customer, "+CHR(10)+ ;​

"Sale Invoice ready No "​

------------------
mstrcmtr -- Un-Successful

lcEdt1 = ;​

"Dear Customer, " + CHR(10) + ;​

"Sale Invoice ready No "​

============================================================

Like Olaf says: What is the difference?

If one is SUCCESSFUL while the other is NOT-SUCCESSFUL and both are the same, then maybe your problem is Not coming from the message string itself, but from some other part of the SMS send attempt.

Good Luck,
JRB-Bldr

 

[atlopes]

You have solved your problem by now but, for future reference and your peace of mind, the official documentation in

http://www.etsi.org/deliver/etsi_ts/123000_123099/123038/13.00.00_60/ts_123038v130000p.pdf

(current version, at page 15) states:

LF [ = CHR(10) ]
Line feed: Any characters following LF which are to be displayed shall be presented as the next line of the message, commencing with the first character position.
CR [ = CHR(13) ]
Carriage return: Any characters following CR which are to be displayed shall be presented as the current line of the message, commencing with the first character position.
SP [ = CHR(32) ]
Space character

 

[Olaf Doschke]

In regard to the codeline I posted above: [tt].Output = cString + CHR(13)[/tt]

This CHR(13) is added by the SMSSending. No CHR(13) is allowed in your message text, this CHR(13) ends the message sending and any further characters are interpreted as the next GSM modem command, which causes errors most probably.

Remove all CHR(13) from your SMS messages and at that places only use one CHR(10), as my CHRTRAN and STRTRAN code do in combination.

Bye, Olaf.

 

[Mike Gagnon]

[pre]mstrcmtr -- Work Successful

lcEdt1 = ;

"Dear Customer, "+CHR(10)+ ;

"Sale Invoice ready No "
------------------
mstrcmtr -- Un-Successful

lcEdt1 = ;

"Dear Customer, " + CHR(10) + ;

"Sale Invoice ready No "[/pre]

The extra space between " and +?

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[mstrcmtr]

Yes space between "Dear Customer, " and + CHR(10) + may be the issue so i remove spaces

 

[Olaf Doschke]

No, that's 120% surely no issue

? "a" + "b"
? "a"+"b"

? 1+1
? 1 + 1

? CHR(65)
? CHR( 65)
? CHR( 65 )
? CHR(65) + CHR(66)
? CHR(65)+ CHR( 66)

And what's seldom known:
? _screen.caption
? _screen. caption
? _screen . caption

Spaces in source code have no influence on results of string concatenation or numeric calculations or parsing and passing of parameters. Only spaces within a string make a difference of it, very obviously. Spaces are rather ignored by the compiler. What for example does not work is printing _ S c r e e n . C a p t i o n, so spaces are not allowed within names.

If one call didn't worked and the next did, that's surely not because of that space but most probably because of the state change of your running class object or the modem.

In the moment you added the space you might have seen a messagebox popping up asking "Remove classes from memory?" That always happens, when you even just begin changing code of a class currently running in memory. that in turn causes the next run to work on a new instance and that might have helped, if the old in memory class instance was in a problematic state or might have caused trouble, if that reset your class state, but not your modem state.

Perhaps CLEAR ALL between running two versions of code to avoid the influence of remniscences of previously running code, class instances etc. Also your SMS GSM modem is in a certain state, not only VFP. So you only get reproducable behaviour after a reset of that, too. That's perhaps the most important difficulty in testing device specfic code. Devices also have to be brought into an initial and clean state.

Bye, Olaf.