To wrap or not to wrap - that is the question!

[K.Daube]

Paraphrasing Shakepeare's Hamlet, I wonder what this parameter of t he Find method is all about:

• When starting a search for a word which exists multiple times in a document, and continue searching after t he last find in the document (at that moment of course I do not know that it is the last occurrence), I find find myself again in the first find...
• With my development FMfindRepl I have the same effect, even defining the parameter as 0.
• In the FM Find/Change dialog Wrapping can not be influenced.

FDK reference states:

FS_FindWrap A BoolT flag that determines whether the find operation will wrap when it reaches the location where the search began.

• Default is True; the find operations wraps.
• If False, after reaching the location where the search began, the find operation returns an empty
  F_TextRangeT and FA_errno is set to FE_NotFound.

In FMfindReplace I have this defintion for the Find parameters:

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

But this obviously has no no effect.

There was ample discussion on this 10 years ago: Telling Find method NOT to wrap

Rick makes the proposal «Before each find, try setting the document's TextSelection property to the TextLoc you want to start the search from».

But I have no idea how to follow this advice, because the result of the find is a new text location...

So the question remains:

How to stop searching after the last find in a document?

Edit 

The problem becomes cumbersome when searching in a book.

• If, for example, search term does not exist in the first document, a script gets the feedback "not found" and the second document can be searched (standard FM Find/Change opens the files hidden, hence you do not notice the processing of this file).
• In the second document the search term exists multiple times - you need to observe yourself that you have wrapped the search and need to close the document yourself.
• Then you can continue Search in Book and FM (in case of standard Search/Change) will continue in the third document. Assuming that there is only 1 occurrence of the search term, Repeatedly pressing the Find button will not advance to the next document
• ...

It will be darn difficult to make my script do the right thing: observe the end of the document and then go to the next one, if the user presses just Find, Find, ... until he finds the desired environment of his search term.

[StudioSm]

I would like to know that too, actually 🙂

[K.Daube]

I will try with the following procedure:

• During the find cycle function HasWrapped checkes whether a wrap has happened. If so, the cycle will be trminated. In a book that means to go to the next component.
• HasWrapped compares the currently found location with the FirstFoundLoc. IMHO I need to compare only TR.beg of the found item  and not also TR.end. Thanks the object property Unique  the comparison is far more easy than for an arbitrary type of object ...
• Defining FirstFoundLoc requires to define when we start the Find cycle (bFirstFind). In a book search this is when I enter the document. Generally it is when I define new Find criteria: Change of FindType (Marker, Text, etc.) and/or when the find string is changed. Since this change does not trigger if programmatically changed by selection in the catalogue drop-down list, I also need to check for the selection here. bFirstFind must also be set when the search method has changed (e.g adding the Word or Case criterion).

Edit

This method works (at least for text - need further tests), although my particular scripts demands certain detail definitions. The experience is not completely the same as with standard FM Find/Change - but it is transparent to the user, as i provide information in the panel about the status of the find.

[K.Daube]

At least one problem remains: I can not start the search with a hidden book compoent (invisible). In this case I do not get a selection, although I explicitly define

  oTLstart = new TextLoc (oDoc.FirstPgfInDoc, 0);

 And I leave the traversed documents open. Well, this may be a disadvantage for laarge books with many components. Will try to fix this until "release".

[K.Daube · Accepted solution]

One more strangeness with this property:

When I leave out the setting of the Wrap parameter to 0 (→ do not wrap) in the function GetFindParameters the while in the snippet will not come to an end. Hence at least for searching Anchored Frames the wrap parameter works ...

Snippet from function CollectUserStrings:

oTRfound = oDoc.Find(oTL, oFindParms);
oFindParms = KLD_F.GetFindParameters ("ANCFRM", "", 0, false, false, false)
//                             (sType, sSearch, iMode, bWord, bCase, bBack)
while (oTRfound.beg.obj.ObjectValid()) {
  oFrameTI = oDoc.GetTextForRange (oTRfound, Constants.FTI_FrameAnchor);
  for (k = 0; k < oFrameTI.length; k++) {
    oTextItem = oFrameTI[k];
    oObject = oTextItem.obj;
    sFound = oObject.UserString;
    oTL  = oObject.TextLoc;
    oUstring = new KLD_F.UserString("AFrame", oObject, sFound, oTL);
    aoUserStrings.push (oUstring);
  }
  oTRfound = oDoc.Find(oTL, oFindParms);
}

 Therefore in my script FMfindRepl I have both set the "noWrap" parameter (for situation like the one above) and check in other situations with the function IsWrapped whether I'm back to start of the find sequence or not...