Page 1 of 1
unknown bug in my lineoffset code
Posted: Tue Mar 29, 2016 4:22 pm
by ittarter
Hi guys,
I can't figure out where I'm going wrong here.
the first line of fld "chapter info" is
[chapterID] 01
(these items are tab delimited)
So when I put this line in the Message Box,
Code: Select all
put lineoffset(tab & "01",fld "chapter info")
I get a result of 1, as I should.
However, my ACTUAL code doesn't work:
Code: Select all
put the selectedtext of fld "downloadlist" into tChap
put lineoffset(tab & tChap,fld "Chapter info") into tLine
yields 0. tChap is still 01 (I can see this in the variables tracker of the script editor). I can also search for "[chapterID]" & tab & tChap, with the same result, 0.
What is going on?? I mean, I can always do a repeat for each line, that searches for an item 2 of tLine equal to tChap, but that's just so messy...
Re: unknown bug in my lineoffset code
Posted: Tue Mar 29, 2016 4:48 pm
by FourthWorld
You might double-check the hilitedText of the list field to make sure it contains no extra tabs, spaces, or other white characters which could account for the seeming disparity.
Re: unknown bug in my lineoffset code
Posted: Wed Mar 30, 2016 6:51 am
by ittarter
Nope, not that. Thanks for the help though. I've given up and switched over to a repeat-based search of the field.
Re: unknown bug in my lineoffset code
Posted: Wed Mar 30, 2016 4:07 pm
by [-hh]
tChap may start with a tab? (The variable tracker updates slowly ...)
You could try
Code: Select all
put the selectedtext of fld "downloadlist" into tChap
replace tab with empty in tChap #<-----
put lineoffset(tab & tChap,fld "Chapter info") into tLine
[Also, if you don't really need the line number but eventually the content of that line then you could also think about using "filter".]
Re: unknown bug in my lineoffset code
Posted: Wed Mar 30, 2016 5:18 pm
by FourthWorld
ittarter wrote:Nope, not that. Thanks for the help though. I've given up and switched over to a repeat-based search of the field.
If the repeat loop succeeds with the same data that lineoffset failed with, it would be interesting to see the loop code to determine what was wrong with the lineoffset call.
Re: unknown bug in my lineoffset code
Posted: Wed Mar 30, 2016 6:07 pm
by jacque
When this happens to me I do something like this:
Code: Select all
put the selectedtext of fld "downloadlist" into tChap
answer (tChap=01)
set the clipboardData to tChap
Select the known first chapter (to get 01) and run the handler. If the comparison yields false, open a text editor and paste. Have the editor show invisible characters, and usually you can see what the problem is.
Re: unknown bug in my lineoffset code
Posted: Wed Mar 30, 2016 11:02 pm
by ittarter
FourthWorld wrote:
If the repeat loop succeeds with the same data that lineoffset failed with, it would be interesting to see the loop code to determine what was wrong with the lineoffset call.
Well, here it is! (The field with chapters listed was changed to a combo box for aesthetic reasons.)
Code: Select all
put pItemName into tChap
repeat for each line tThis in fld "chapter info"
add 1 to tCount
if item 2 of tThis = tChap then
put tCount into tLine
exit repeat
end if
end repeat
Zero problems. So yeah, weird.
Re: unknown bug in my lineoffset code
Posted: Wed Mar 30, 2016 11:07 pm
by ittarter
[-hh] wrote:[Also, if you don't really need the line number but eventually the content of that line then you could also think about using "filter".]
I need the line number. It's the first line of a block of data that is being called line by line. It's not sexy but it works. item 2 of line (tLine +1), item 2 of line (tLine +2), and so forth.
Re: unknown bug in my lineoffset code
Posted: Wed Mar 30, 2016 11:09 pm
by ittarter
jacque wrote:
Code: Select all
put the selectedtext of fld "downloadlist" into tChap
answer (tChap=01)
set the clipboardData to tChap
Line 2 is a new concept to me. It's like an if statement and results in true if tChap = 1, false otherwise? Neato.
Re: unknown bug in my lineoffset code
Posted: Wed Mar 30, 2016 11:43 pm
by jacque
I should have put the number in quotes though to make it a literal string: answer (tChap="01")
Without the quotes, the engine will evaluate tChap as a number, which would match either "1" or "01" or "0001" and still evaluate to true. With the quotes, the string must match exactly. Also, technically, you don't need the parentheses but it makes reading the script easier for me. It would work the same if you wrote: answer tChap = "01"
Edit: do you have wholeMatches set to true? That would cause a lineoffset to fail.