How to stop Find at the end of the document?

[K.Daube]

Dear all,

There is a flag in the Find parameters which shall stop the wrap around:

  oPropVal1 = new PropVal() ;
  oPropVal1.propIdent.num = Constants.FS_FindWrap ;  
  oPropVal1.propVal.valType = Constants.FT_Integer;  
  oPropVal1.propVal.ival = 0 ;                    // don't wrap  
  findParms.push(oPropVal1);  

I have found that a Find loops 'endless' even if this flag is used. And BTW I have no influence on this from the UI panel.

I want to create a Find procedure, which has two options:

• Start the find at the top of the document and end it at the end of it
• Start the find at the current location and end it at the end of the document.

→ Do You have any idea how to achieve this?

In a former project concerning Footnotes I developed a method by looping through all ¶ and checking against the starting point of the Find and the resulting Find location. But it seems that this is not reliable 

My current code is here. 

[K.Daube · Accepted solution]

With many experiments I got some insight into this problem. I did my experiments in an aged document. Hence the various paragraphs were not created in the order the user sees them:

• 
• Linked list of items in flow provide an order of creation. It is clear, that when looking for paragraphs (NextPgfInFlow) you will not get footnotes.
• Linked list of items in document (NextPgfInDoc) provide an order of creation also. Here the results are more numerous than in the first case. Looking for paragraphs also provides footnote paragraphs.
• Find method provide the order as the user sees it. But there is a suborder depending on items in objects: When looking for any paragraph, you first come along all in the text frame, then you get those in tables and last you get those in nested text frames (text frame in anchored frame). Here I used  «Search for paragraph tag "*" with wild cards».

In this example document it is not possible at all to define an "end of search" when starting, for example after the table. The next occurrence of a searched text will appear close to the top of the document → obviously a wrap happened at the visible end of the document. This happens even if the NoWrap flag is set in the find parameters. This flag has a different purpose than what I expected from it.

Conclusion

There is no such thing as an "end of document" - it depends on the search method and the document structure. hence I must forget my idea of just searching from current location to the "end of the document".

[Russ Ward]

Hi Klaus, what happens if you do the search with the UI? If it searches endlessly, then I would expect the same behavior from the script. But if the UI stops, then I think the script should also. If so, there might be a solution, although I do not see a problem with your code.

Something to think about... I'm not sure that the "no wrap" logic has anything to do with the flow of text, order of paragraphs, etc. I think maybe FM simply remembers the text location of the first item found, then stops when it finds it again. It seems that if you alter text during a manual find, it "resets" the "no wrap" logic. I'm not 100% sure about that. But in either case, as a last resort, maybe you could do that yourself in your code. That is, store the text location of the first find and stop your loop when you get back there.

It's been a while since I did any searching with a script. Hope this helps,

Russ

[K.Daube]

Thnak you Russ.

It seems that the incriminated flag works for find-replace. Assuming the searched object exists 3 times:

• Searching for something - finds the first object
• Find Next finds the next (2nd) occurrence
• Find Next finds the next (3rd) occurrence
• Find Next finds the next (1st) occurrence
• ...

If I change the object at the second occurrence, then the Find-Next 'loop' stops at the next time i come round the corner to this object.

[frameexpert]

I had some issues with the Find function when I did a lot of FrameScript scripting so I never fully trusted it. FrameScript had a Find String InObject command which worked around this because I could loop through the paragraphs in document order and do a find on each paragraph.

ExtendScript doesn't have this so, I basically do this:

1) Get a TextList of all of the items in the document's main text flow that I want to search. For example PgfBegin, TblAnchor, FnAnchor.

2) As I process the list, I branch as appropriate: process the table cells and paragraphs, process the footnote paragraphs, etc.

3) For each paragraph, I return the text from a getText function and apply a regular expression to it. The regular expression is my Find criteria.

4) If there are one or more matches, then I use Find. I use my match to set a TextLoc in the paragraph and at the match offset and start my find from there. If my find returns a TextRange, then I make sure that I am in the correct paragraph and then process the TextRange. Note that if I am replacing text, I will process the regular expression matches in reverse order so I don't mess up the offsets.

This is a lot of code just to do what the Find method should, but I have most of these things in reusable functions. I like the idea that I have control over the order that the paragraphs are processed and that I don't have to rely on the Find method.

[K.Daube]

Thank You Rick for the long explanation of your process.

I have used this (or something similar) in my scripts where I anyhow stored the objects of interest (e.g. user variables and their location of use) in a list/array. But for a general purpose search it is in my opinion to heavy - or I'm to old for the weight...

Hence I decided to not clarify the issue (how to stop ...) any further.