If you use "find" you'll have to "go invisible" to each substack, as has been
pointed out, or you'll get each substack flashing to the front. The other thing
is that the find command will find the first instance of the string in each
stack, so you will have to use the foundchunk function and to store the find
then repeat the find/store-chunk routine until all have been found.
The alternative is to use offset. This could be sped up if you know which
fields are of interest, which you almost certainly will -- you don't want to
search label fields and other stuff that doesn't contain actual data. If you go
that route, here's a useful function that returns all the offsets of a string
in a container. It is quite fast.
function offsets str,container,includeOverlaps
-- returns a comma-delimited list of all the offsets of str in container
-- third param is optional:
-- offsets("xx","xxxxxx") returns "1,3,5" not "1,2,3,4,5"
-- ie, by default, overlapping offsets are not counted
-- if you want overlapping offsets then pass "true" in 3rd param
-- returns 0 if str is not in container
if str is not in container then return 0
if includeOverlaps = empty then put false into includeOverlaps
put empty into offsetList
put 0 into startPoint
repeat
put offset(str,container,startPoint) into thisOffset
if thisOffset = 0 then exit repeat
add thisOffset to startPoint
put startPoint & comma after offsetList
if not includeOverlaps then
add length(str)-1 to startPoint
end if
end repeat
return item 1 to -1 of offsetList -- delete trailing comma
end offsets
You can indeed avoid going to the individual substacks by first setting up a
list of long id's of fields ("fieldlist") for all the fields of interest in all
the substacks. Store this as a script local or a customproperty so it's a
one-time task.
repeat for each item f in fieldlist
put offsets(tString,f) into tOffsets
if tOffsets = 0 then next repeat
repeat for each item i in tOffsets
put the number of words of char 1 to i of the text of f into nbrWords
put "…" && (word nbrWords - 3 to nbrWords + 3 of the text of f) && "…"
into tContext
-- more scripting to load the context into your display field and
-- set the linktext of the line to the occurrence found, or
-- whatever your idea is for the user access to the original occurrence
end repeat
end repeat
I strongly suspect this approach will be faster than going to each stack
invisibly and doing repeated finds.
-- Peter
Peter M. Brigham
[email protected]
http://home.comcast.net/~pmbrig
On Dec 17, 2012, at 6:54 PM, Peter Bogdanoff wrote:
> I do see that there is much more management with the "offset", however, I
> believe I can use the offset without having to actually navigate to the other
> stack, and I found that going to another stack and using the "Find" there
> unlocks the screen (bad).
>
> I want the entire search done in one go with a list of all the found
> occurrences.
>
>
> On Dec 17, 2012, at 3:45 PM, [email protected] wrote:
>
>> I do not know if I am understanding you correctly, but my instincts say that
>> "find" is the right way to go. "Offset" would require more management,
>> whereas "find" is pretty self reliant.
>>
>>
>> How would you use "offset" over multiple stacks anyway? Navigate to each
>> card in each stack, and then test each field in turn, noting if the offset
>> function returned a value or not? Certainly there is a value to this, in
>> that the "offset" function can be tailored to find multiple instances.
>>
>>
>> Perhaps a mixture of the two, "find" to get quickly to a card that has a
>> hit, and then "offset" to find multiple instances?
>>
>>
>> Craig Newman
>>
>>
>>
>>
>> -----Original Message-----
>> From: Peter Bogdanoff <[email protected]>
>> To: How to use LiveCode <[email protected]>
>> Sent: Mon, Dec 17, 2012 6:31 pm
>> Subject: Find vs. Offset
>>
>>
>> Hi,
>>
>> I have a stack with multiple substacks. One of the substacks is a Search
>> tool to
>> find text in the other substacks. Given a string to find, it searches the
>> other
>> stacks, returns a list of the cards where the string was found (there may be
>> multiple hits on the same card), and puts excerpts of the strings of text (3
>> words before and after the found chunk) into a field. The user then clicks
>> on a
>> line of the field to go to a card where the text was originally found--there
>> I
>> do another Find to put the found box around the text.
>>
>> Am I right in assuming that I should use the offset function to do the
>> original
>> search rather than the Find command?
>>
>> I see that when I use the Find command, although I lock the screen, it is
>> unlocked after going to each stack. Also I suspect it is a much slower
>> method.
>>
>> There is a lot more scripting to do with the offset to search multiple
>> fields,
>> and multiple hits in the same field, to I would like to know if this is the
>> best
>> method.
>>
>> Any experience with this?
>>
>> Peter
>> UCLA
>>
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [email protected]
>> Please visit this url to subscribe, unsubscribe and manage your subscription
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [email protected]
>> Please visit this url to subscribe, unsubscribe and manage your subscription
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [email protected]
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
