I just had a thought does the string matching go something like this:
With EndString = "\r\nOK\r\n"
1: Received CR => match for EndString[0], try EndString[1] next;
2: Received LF => match for EndString[1], try EndString[2] next;
3: Received CR => doesn't match EndString[2], try EndString[0] next;
4: Received LF => doesn't match EndString[0], keep looking for a match for EndString[0]
Which looks like a bug to me!
Or, at least, a serious limitation that should be documented.
At step 3, I think it should re-check for a match with EndString[0].
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I now think that this has nothing specifically to do with end-of-line sequences, but is a general flaw in the matching process - as hypothesised in my 2nd post.
I'm a bit reluctant to try an update as I remember the install process being a bit fraught the first time around when it was a paid product delivered on a CD...
Do you have any tips for a painless update?
Cheeky question: could you rebuild my test case to see if it does fix it...?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As long as you install 4.07 to a different directory, you should be able to remove 4.06 from Delphi's component list, build 4.07, add it to Delphi's component list and test. If things don't work out, you should be able to remove 4.07 from Delphi's component list, rebuild 4.06 and add 4.06 to Delphi's component list. Shouldn't be too much of a problem as long as you are careful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's the kind of thing I was thinking of when I said, "I remember the install process being a bit fraught the first time around when it was a paid product delivered on a CD..."
It assumes that I am a Delphi guy, and tells me next to nothing about C++ Builder
:-(
Oh well, I'm trying it on a different PC; I note that my original (v4.06) installation seems to be using A406_R51...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your package names for 4.07 will be the same. I was simply too lazy to change them when I made the new release. Bad decision, but I am kind of stuck with it now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"apro" will match;
"aapro" will not match, but "a apro" will match;
"apapro" will not match, but "ap apro" will match;
"aprapro" will not match, but "apr apro" will match;
"aproapro" will match (twice).
Full details in the comment at the top of Unit1.cpp
See what you think...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-02-06
Hello
Seems that this thread has died long ago, but I have this problem too, with 4.07 and XE2.
TApdPackage does not with #10 (Linefeed)
The error is somewhere in the "endstring" match, where it tries to match control char (#$A] with three byte endString "#10" which of course does not match.
Someone must have changed this, I'm almost sure it once was working….
Hope someone out "there" has a fix for this.???
Here's two examples first one doesn't work (using control chr 10) the second is with a "text" <LF> endstring and that works fine.
I'm trying to specify the "OK" at the end of a modem's AT Command responsed as the EndString for a DataPacket.
So I specified the EndString as "\r\nOK\r\n", but this failed to trigger - even though the trace shows that sequence was received:
0020.881 Packet Enable 00000000 Packet:ApdDataPacketGsmCmgr
0020.881 Packet StartStr 00000000 +CMGR:[20]
0020.881 Packet Waiting 00000000 Packet:ApdDataPacketGsmCmgr
0020.881 Packet EndStr 00000000 [0D][0A]OK[0D][0A]
0020.881 Trigger Status 00000035
0020.881 TrDatChg Timer 00000038 [01][00][00][00]
:
:
0021.053 Dispatch ReadCom 00000001 [0D]
0021.053 Trigger Avail 00000001
0021.054 Dispatch ReadCom 00000001 [0A]
0021.054 Trigger Avail 00000001
0021.055 Dispatch ReadCom 00000001 [0D]
0021.055 Trigger Avail 00000001
0021.056 Dispatch ReadCom 00000001 [0A]
0021.056 Trigger Avail 00000001
0021.057 Dispatch ReadCom 00000001 O
0021.057 Trigger Avail 00000001
0021.058 Dispatch ReadCom 00000001 K
0021.058 Trigger Avail 00000001
0021.059 Dispatch ReadCom 00000001 [0D]
0021.059 Trigger Avail 00000001
0021.060 Dispatch ReadCom 00000001 [0A]
0021.060 Trigger Avail 00000001
0021.060 TrDatChg Timer 00000008 Deactivated
0021.060 Packet Idle 00000000 Packet:ApdDataPacketGsmCmgr
0021.060 Packet Disable 00000000 Packet:ApdDataPacketGsmCmgr
0021.060 Packet StringPacket 00000000 Packet:ApdDataPacketGsmCmgr
If I change the EndString to "\r\n\r\nOK\r\n", it does trigger!
So why can't it "see" the original (sub-)string, and trigger on that?
I think I've seen this before - there seems to be something about the CRLF end-of-line sequence...
I just had a thought does the string matching go something like this:
With EndString = "\r\nOK\r\n"
1: Received CR => match for EndString[0], try EndString[1] next;
2: Received LF => match for EndString[1], try EndString[2] next;
3: Received CR => doesn't match EndString[2], try EndString[0] next;
4: Received LF => doesn't match EndString[0], keep looking for a match for EndString[0]
Which looks like a bug to me!
Or, at least, a serious limitation that should be documented.
At step 3, I think it should re-check for a match with EndString[0].
I just got a log file from a client showing the same problem! My program is using APro 3.06. What version are you using?
--
Regards,
Paul Breneman
www.TurboControl.com
www.TurboControl.com/TPSupport.htm - TurboPower support links
It's v4.06 with C++ Builder 5
I now think that this has nothing specifically to do with end-of-line sequences, but is a general flaw in the matching process - as hypothesised in my 2nd post.
See also this cross-post (in glorious technicolor): http://www.8052.com/forumchat/read/162159
Try the latest 4.07 build. I made some significant changes to TApdDataPacket in an effort to fix some of the weirdness.
I'm a bit reluctant to try an update as I remember the install process being a bit fraught the first time around when it was a paid product delivered on a CD...
Do you have any tips for a painless update?
Cheeky question: could you rebuild my test case to see if it does fix it...?
In my experience there is no such thing as a painless update. ;) All I can suggest is try it and see if it works for you.
True enough...
Trouble is, if I try it and it doesn't work, will I be able to get back to my current setup - which at least works with known limitations...?
As long as you install 4.07 to a different directory, you should be able to remove 4.06 from Delphi's component list, build 4.07, add it to Delphi's component list and test. If things don't work out, you should be able to remove 4.07 from Delphi's component list, rebuild 4.06 and add 4.06 to Delphi's component list. Shouldn't be too much of a problem as long as you are careful.
I'm using C++ Builder v5.0 (Build 12.34) + Update Pack 1 - not Delphi.
So, which packages should I use?
Where do I check the VCL version?
In the RuntimePackages options I have VCL50 - so, presumably, that's v5.0?
But there is no A406_D50.bpk nor A406_R50.bpk package.
Should I use A406_D51.bpk & A406_R51.bpk instead?
Unfortunately, I am a Delphi guy and know next to nothing about C++ Builder. Perhaps some of the other C++ people on the list can help?
That's the kind of thing I was thinking of when I said, "I remember the install process being a bit fraught the first time around when it was a paid product delivered on a CD..."
It assumes that I am a Delphi guy, and tells me next to nothing about C++ Builder
:-(
Oh well, I'm trying it on a different PC; I note that my original (v4.06) installation seems to be using A406_R51...
Your package names for 4.07 will be the same. I was simply too lazy to change them when I made the new release. Bad decision, but I am kind of stuck with it now.
It doesn't build:
Linker Fatal Error: Unable to open file 'VCLMID50.LIB'
(there is no 'VCLMID50.LIB' to be found anywhere in the CBuilder folder tree)
Here's a C++ Builder test case:
http://www.antronics.co.uk/downloads...Packet.zip
With the EndString set to "apro":
"apro" will match;
"aapro" will not match, but "a apro" will match;
"apapro" will not match, but "ap apro" will match;
"aprapro" will not match, but "apr apro" will match;
"aproapro" will match (twice).
Full details in the comment at the top of Unit1.cpp
See what you think...
Sorry, that should be:
http://www.antronics.co.uk/downloads/TApdDataPacket.zip
Hello
Seems that this thread has died long ago, but I have this problem too, with 4.07 and XE2.
TApdPackage does not with #10 (Linefeed)
The error is somewhere in the "endstring" match, where it tries to match control char (#$A] with three byte endString "#10" which of course does not match.
Someone must have changed this, I'm almost sure it once was working….
Hope someone out "there" has a fix for this.???
Here's two examples first one doesn't work (using control chr 10) the second is with a "text" <LF> endstring and that works fine.
APRO v4.07
Compiler : Unknown
Operating System : WinNT 6.1 Service Pack 1
Device: Winsock server on port 2012
Date/time: 06-02-12, 20:25:03
Time Type SubType Data OtherData
----- ----- -------- ----- ------
0000.001 TrDatChg Avail 00000001
0000.002 TrgHdAlc Window 006C1610
0000.002 TrgHdAlc Method 00000000
0000.002 TrigAllc Timer 00000008
0000.002 Packet Enable 00000000 Packet:ApdDataPacket1
0000.002 TrDatChg Timer 00000008
0000.002 Packet Collecting 00000000 Packet:ApdDataPacket1
0000.002 Packet EndStr 00000000 #10
0006.029 Dispatch ReadCom 00000022 10:134134A7+LINKFRYSE
R4A.012
0006.029 Trigger Avail 00000022
0008.426 Dispatch ReadCom 00000022 10:134135A7+LINKFRYSE
R5A.012
0008.426 Trigger Avail 00000022
0009.306 Dispatch ReadCom 00000022 10:134135A7-LINKFRYSE
R5A.012
0009.306 Trigger Avail 00000022
APRO v4.07
Compiler : Unknown
Operating System : WinNT 6.1 Service Pack 1
Device: Winsock server on port 2012
Date/time: 06-02-12, 20:28:34
Time Type SubType Data OtherData
----- ----- -------- ----- ------
0000.000 TrDatChg Avail 00000001
0000.001 TrgHdAlc Window 001416C4
0000.001 TrgHdAlc Method 00000000
0000.001 TrigAllc Timer 00000008
0000.001 Packet Enable 00000000 Packet:ApdDataPacket1
0000.001 TrDatChg Timer 00000008
0000.001 Packet Collecting 00000000 Packet:ApdDataPacket1
0000.001 Packet EndStr 00000000 <LF>
0010.387 Dispatch ReadCom 00000025 10:134134A7-LINKFRYSE
R4A.012<LF>
0010.387 Trigger Avail 00000025
0010.387 TrDatChg Timer 00000008 Deactivated
0010.387 Packet Idle 00000000 Packet:ApdDataPacket1
0010.387 Packet Disable 00000000 Packet:ApdDataPacket1
0010.387 Packet StringPacket 00000000 Packet:ApdDataPacket1
0010.387 Packet StringPacket 00000000 10:134134A7-LINKFRYSE
R4A.012<LF>
0010.387 Packet Enable 00000000 Packet:ApdDataPacket1
0010.387 TrDatChg Timer 00000008
0010.387 Packet Collecting 00000000 Packet:ApdDataPacket1
0010.387 Packet EndStr 00000000 <LF>
0016.228 Dispatch ReadCom 00000025 10:134134A7+LINKFRYSE
R4A.012<LF>
0016.228 Trigger Avail 00000025
0016.228 TrDatChg Timer 00000008 Deactivated
0016.228 Packet Idle 00000000 Packet:ApdDataPacket1
0016.228 Packet Disable 00000000 Packet:ApdDataPacket1
0016.228 Packet StringPacket 00000000 Packet:ApdDataPacket1
0016.228 Packet StringPacket 00000000 10:134134A7+LINKFRYSE
R4A.012<LF>
0016.229 Packet Enable 00000000 Packet:ApdDataPacket1
0016.229 TrDatChg Timer 00000008
0016.229 Packet Collecting 00000000 Packet:ApdDataPacket1
0016.229 Packet EndStr 00000000 <LF>