Word macro to allow the user to edit two displayed documents in the middle of complex

[PeterT]

Hello Everyone!

My first thread..and the first thing I learnt is that my Title is way too long!
This is the full title: "Word macro to allow the user to edit two displayed documents in the middle of complex nested Range.Find loops, and continue when finished editing."

OK, so I have a complex macro that compares similar texts having identical reference prefixes in two documents.
The Working document (A) is searched for a particular style, then the reference prefix is extracted.
The prefix is then used to search through the entire other document (B) for a matching reference.
If found, both documents are displayed side-by-side with the two groups of paragraphs, that are associated with the reference prefix, selected.
The user is asked if they want to copy the entire group from doc A to B, or B to A, or edit either doc.
So to allow the user to edit the docs numerous times in the middle of that process, and then resume, working through the entire doc A, is my need.

I have done a lot of searching and so far found using a nonmodal form with a DoEvents loop until the form is unloaded by clicking a button on the form works, but the CPU get "hammered" during the loop.
Does anyone know of a better way?

Best regards,
PeterT

[macropod]

Without seeing the code you're using, it's impossible for anyone to advise on how it might be improved. Can you attach a document to a post with useform and code (delete any sensitive content from the document)? You do this via the paperclip symbol on the 'Go Advanced' tab at the bottom of this screen.

[PeterT]

Thank you Paul.

OK, I've attached everything in the PeterT.zip attachment:
My code in a .bas text file (saved using the Export function of the VBE),
The UserForm files (saved using the Export function of the VBE),
And copies of two documents to be compared.

Explanations:
I suggest you first have a quick look at the code. The DoEvents loop is about 75% down in the code, surrounded by long lines of hashes. If all that I've supplied is way too much to work with, then please let me know. I can provide some simpler example code to demonstrate my "Y" problem, but maybe there is a "Z" solution! - like you've suggested Paul. As I've tried to summarize in my original post, my "X" goal is to allow the user to edit the documents at the point of where the DoEvents loop is currently located. Once editing is complete, the idea is to have the user indicate to the macro that it should continue working through the nested search loops.

And in the hope of being clear about my "Y" problem: When the DoEvents loop is running, which allows the user to edit the documents, even when the user does nothing the CPU load is very high. I'm wondering if:
1. There is a way of reducing the load on the CPU during the loop?
2. There is an easier way of indicating to the macro that the user has finished editing (and is ready to proceed working through the Main document) without using a Form?

For the benefit of others who might want to play with the code, the top "Const WrkgFldr As String = " will need to be changed to point to your folder containing the supplied doc's. I think I have supplied all of the code that will allow it to run...

I'm using Word 365 64-bit (Current Channel) on Windows 10.
I have the UserForm and the code stored in the Word Normal.dotm project, not in any of the documents to be compared.

Please don't hesitate to ask any questions if something isn't clear.

Best Regards,
PeterT

[macropod]

So why are you using DoEvents? I can't see that it's doing anything other than chewing up CPU resources. Why not use a wait function in the loop instead? If you set the wait time to 1 second, for example, your average wait time till resuming after closing the userform would only be 0.5 second.

As for looping through all paragraphs and only doing something with the "Bible Text" Style, a wildcard Find looking for all content formatted in that Style would be far more efficient.

[PeterT]

Thanks for your reply Paul.

1. The idea is to allow the user to edit the Word docs once the UserForm1 has popped up and the loop has been entered. After the user has finished doing whatever editing, they click the [Continue] button on the UserForm1. The click event handler unloads the form. Back in the main macro, the loop then detects that the form is no longer visible, so the loop exits and the macro continues to run through the rest of the document. Without the DoEvents in the loop the user can't do any editing in Word - the running macro "locks" the user out, so to speak...

Before discovering DoEvents, when I tested any sort of wait or sleep function (such as: Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal Milliseconds As LongPtr) ), the user can't do anything in Word during the wait or sleep period either.

2. Oh, yes, of course! Thank you! This whole CompareSameTextIn2Docs was based on the ColourNIVWordsRed macro I wrote some months back. At that time I didn't think I could nest Range.Find processes, so had the top level loop use For-Each-Next for all paragraphs, and then a Range.Find once any "Bible Text" Style paragraph was detected. You'll notice I found I could nest Range.Find's and have done that in CompareSameTextIn2Docs. I will now update the code to use a Range.Find to replace the For-Each-Next - thanks!

Best regards,
Peter

[macropod]

In that case, you might consider re-working your code, breaking it into separate routines, such that you can exit when the userform is called, then restart with a variable that gets passed telling Word where to resume when the userform is closed.

[PeterT]

Thanks Paul,

When I was searching for a solution to be able to pause a macro to allow editing of the doc's, suggestions of breaking the code into two parts were common.

Considering that at the point in the code where I want to allow editing, it is four levels deep into nested Range.Find processes. It seemed way too difficult to try to save all the variables of where in the documents the nested searches were up to, so that the searches could resume after editing. It seemed a lot easier to have a way of putting the macro on hold, so to speak, to allow editing, and once the editing had been completed, resume the macro.

Best regards,
Peter