Search Backwards (Last Line to First)

LiveCode is the premier environment for creating multi-platform solutions for all major operating systems - Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Simon Knight
Posts: 919
Joined: Wed Nov 04, 2009 11:41 am

Re: Search Backwards (Last Line to First)

Post by Simon Knight » Tue Feb 09, 2010 1:41 pm

Bernd,
I will write a binary file using your code snip and also send you the complete stack just in case you spot the obvious school boy error. From memory I do do a binary read from the port and all my understanding of line ending has come from cutting text from a field and looking at it in a hex editor (sounds like a school boy error to me!).

best wishes
Simon
best wishes
Skids

Simon Knight
Posts: 919
Joined: Wed Nov 04, 2009 11:41 am

Re: Search Backwards (Last Line to First)

Post by Simon Knight » Tue Feb 09, 2010 2:34 pm

Bernd,

I have reinstated my code as posted on this forum and I am unable to reproduce the fault (yet). I have attached the binary data as a zip archive. My quick look at it indicated that each data line is terminated with a CR LF.

best wishes

Simon
Attachments
BinaryExportPortData.zip
(43.02 KiB) Downloaded 214 times
best wishes
Skids

bn
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4163
Joined: Sun Jan 07, 2007 9:12 pm

Re: Search Backwards (Last Line to First)

Post by bn » Wed Feb 10, 2010 12:56 am

Simon,
I looked at your binary data. It uses a return/linefeed as lineending. If you have a binary dump of your serial data that does not work, that would be very helpful.
In the meantime I rewrote your handler, trying to adapt it as close as possible to your original handler. Here I use the offset function instead of repeat for each line, thus avoiding the line problem, since you said that sometimes there might be problems with the line endings. And there is a size restriction to the line size (if that still applies, it used to be around 64000), seems unlikely but the offset version avoids the line ending problem(if it exists)

Code: Select all

on mouseUp
   --   answer file " choose file"
   --   if it is empty then exit mouseUp
   --   put url ("binfile:" & it) into gDatabuffer
   
   put line 1 to - 2 of gDatabuffer into tData -- leave last line alone
   
   put "$GPGGA" into tStartString
   put numtochar(13) into tEndString -- you could also put the asterix into the tEndString, if there is always an asterix
   put 0 into tStart
   put 0 into tEnd
   put 0 into tStartIncrement
   
   repeat 
      put offset(tStartString,tData,tStartIncrement) into tStart
      if tStart = 0 then exit repeat -- string not found, either not there or end of tData
      add tStart to tStartIncrement -- tStartIncrement has now the character position of the found chunk "$GPGGA"
      put offset(tEndString,tData,tStartIncrement) into tEnd -- tEnd is x chars further from tStartIncrement
      if tEnd = 0 then exit repeat -- should not happen but anyways but also bails out if last line incomplete
      
      put char tStartIncrement to tStartIncrement + tEnd of tData into tmySubData -- it is the searched for string with "$GPGGA" in it
      
      -- this is pretty much your old code, so it should work without too much hassle
      If item 1 of tmySubData ="$GPGGA" AND item 7 of tmySubData= "1" AND item 9 of tmySubData <gHDOP then
         
         if gStartTime="000000" then 
            put item 2 of tmySubData into gStartTime
            --answer gstartTime
         end if
         
         DisplayTime (item 2 of tmySubData)
         DisplayPosition tmySubData
         If gLastFix<>"" then  SetDistanceMoved gLastFix, tmySubData
         put item 8 of tmySubData into fld"satcount"
         put item 9 of tmySubData into fld"HDop"
         put tmySubData into gLastFix
         CalculateAvSpeed item 2 of tmySubData
         --exit repeat
      ELSE 
         put tmySubData & "XXX" after gRejectedFixs
      end if
   end repeat
end mouseUp
A dump of a failed run would really be the best thing to track this down.
regards
Bernd

Post Reply