Methods Roshei & Sofei Possukim - Corrected

Thanks to a friendly user of my website, I came upon a bug in two methods I thought were simple pieces of code, but in fact they needed correction. This is the 2nd time she found a bug! Thank you again Zahava P.!!

Ever since I expanded the database, from just Torah to now include the entire Tanach, a variety of issues suddenly arose that I was made aware of only later.

Previous methods regarded the Torah database to be one big book, where Parsha borders were ignored. If results spanned from one Parsha into another another, that was okay.

But with the expanded Tanach as my new database, some methods or option (gematria's "successive possukim") no longer make sense. Now, borders between books became significant.

For example, in a gematria search with the “successive possukim” option selected, it makes no sense if the gematria result began in one book and the rest of the gematria was found in the next. To illustrate, if the last verse in Torah comprised one part of the gematria, and the rest of the gematria was found in verses of the next book, Yehoshua, this "hit" would make little sense.

(My screw-up came up because I had to allow for spanning to occur for the books Shmuel A & B, Divrei Hayomim A & B, Ezra & Nehemia, and Melachim A & B, and this code was incorrect.)

This same problem exists in methods such as “Equidistant Letter Sequence”, “Sofei Possukim” and "Roshei Possukim". Because in each of these methods, the results found might span from one book across into the next, and such spanned results have no good purpose.

I coded my way out of this “new” problem in 3 situations but I could not do so with the “Equidistant Letter Sequence” method. This code as it is is already quite complex so I just couldn't. Instead, I simply put the burden on the user, forcing the user to specify proper borders for his search region. The "Range" parameter can easily be set right by the user on the Home Page.

I'm sorry I could not code my way out of the “Equidistant Letter Sequence” method and had to resort to issuance of an error to bypass this inability. It's awkward because the same error ought to pop up for “Sofei Possukim” and "Roshei Possukim", because these too make no sense were results to span across separate books. But here this situation can no longer happen because I code it so that spanning will not take place.

Here's the error that shows for the “Equidistant Letter Sequence” method when the range parameters must first be properly specified:

(With this correction, and with what I did to streamline "Find a Phrase", I believe the entire program is now 100% well and accurate, ב׳׳ה.)

Now at version 48.