Find and Delete string functions

[andrewjfox]

Hi,

I'm having some trouble with Find and Delete string functions

following code reads data into a buffer then deletes messages as they're processed

define RADIO_ABORT_RSP = {0x98,0x98,0x98,0x98}

 pDevice = CommDevice[i][RADIO_PORT]
	  try
		 strResponse[MAX_READERS] = pDevice.Read(0)
		 if(!IsEmpty(strResponse[MAX_READERS]))
			strResponse[i] += strResponse[MAX_READERS]
		 endif
	  catch()
		 strResponse[i] = ""
	  endcatch

	  RspIndex = Find(strResponse[i],ChrA(RADIO_ABORT_RSP),0)
	  if(RspIndex >= 0 )
		 AbortRspRecvd[i] += 1
		 strResponse[i] = Delete(strResponse[i],RspIndex,RADIO_ABORT_RSP_LEN)
	  endif

Note that only 1 of the many messages is shown but they are all processed much the same way. This works ok for a little while then, if for any reason the buffer starts to get bigger than around 80 chars, Find stops working and subsequently the buffer gets bigger quicker.

I've also had problems where if the processing gets out of sync and Delete is called with num chars > than buffer length, it crashes DF. I have put extra limit checking in but should Delete be safe from this?

Any help is greatly appreciated.

Andrew

[AzeoTech]

I'm not seeing the Find() issue. I created a string with a 150 characters or so and it was able to find the last character without issue. Maybe you can post a simple .ctl doc that demonstrates the problem?

I do see the Delete() issue, and from I can tell, it appears to be an Microsoft MFC bug, possibly on newer Win7 machines. We've added some code in DAQFactory to adjust the requested count if needed to avoid tripping the MFC bug. It will appear in the next release, or email if you want a pre-release.

[andrewjfox]

Hi,

I have been struggling to find where my problems are so started breaking the whole thing down. I put together a simple test of my message handling only (taking out comms port issues) and have attached

Startup seq adds messages to the buffer, while ProcessRadioPackets finds and removes them. At the end I would expect to see all counters return to 0, however this is not the case and some messages cause more problems than others. I cannot determine if the problem is with the Find'ing or the Delete'ing of the messages from the buffer.

Development machine is Win 7 Pro 64bit, running DF Developer, but my target system will be Embedded Win7 32bit. Iwas originally having problems on target and switched to development machine to speed up process, but am having same problems.

Regards

Andrew

port_demo.ctl

[andrewjfox]

Hi,

I have an update on the test ctl doc regarding comms port issues. I have been having problems ever since moving to Win7 from XP with comms ports. The sequence SendData is basically setting up a comm port using object methods, and echoing data, but this doesn't work.

Has something changed in Windows OS to change the way the object based comms ports works?

Andrew

port_demo.ctl

[AzeoTech]

OK, first Find(): the issue here is that the Find() function is a C level function, even though it goes through MFC. I hate to blame Microsoft again, but I'm going to. Despite the fact that Find() in MFC takes a string object (CString), which has a length and thus allows 0's in it, apparently, Find() converts the search string to a standard null terminated string and ignores anything past any 0's in the string. This means that as far as find is concerned, your RADIO_PKT_BEGIN_STD and RADIO_PKT_END are the same, and are simply chr(2).

My personal recommendation then is to avoid using strings for this sort of processing. Keep all the data as arrays. You can compare two arrays in a single line, so for example, to see if the beginning of the array "response" (which is just the asc() array version of strResponse) is RADIO_PKT_END, you'd do:

if (min(response == RADIO_PKT_END))

Note that we don't need to subset response because it will get truncated to the length of radio_pkt_end. Also, note that if response is shorter than radio_pkt_end, but the characters match up to that point, you'll get a false positive, so you might want to make it:

if ((min(response == RADIO_PKT_END)) && (numrows(response) >= numrows(radio_pkt_end)))

From this you can build up your own find() routine if you need to find packets in the middle rather than the beginning, though then you'd need to subset response, and you'd want the length check before the search.

As for the second part about sockets, yes something changed in Windows that causes loop back type sockets not to connect. I think it probably has something to do with Windows Firewall but haven't taken the time to chase it down. It affects other parts of DF (like making a Connection to yourself), as well as other programs. It has nothing to do with the object based comms, which you can demonstrate by simply creating a non-object socket and having it try and connect to 127.0.0.1.

[andrewjfox]

It all makes sense now.

You guys really are world class in your dedication to users.

Once again, Thankyou