5

Consider the following table in Word 2013

A BBB
A CCC
D E F

A, B and C are merged cells.

A and B are empty. C has text A inside.

Now the following code

Set rng = ActiveDocument.Range(0, 0)  
With rng.Find
    .Forward = True
    .Wrap = wdFindStop
    .Execute "A"
End With

Crashes word on Execute "A".

If I change text to Execute "B" it doesn't find anything but doesn't crash word. Issue is present only in word 2013.

We tried searching manually and Selection.Find cell by cell, but both of those are rather slow.

Is there a quick way to circumvent this error?

EDIT: this is minimum fail example that I constructed. In our application we use a lot of Range.Find, sometimes with wrap and almost never starting from Document.Start

EDIT2: further investigation shows that Error isn't present if you open Document in compatibility mode (Word 97-2003 format).

Smandoli
  • 6,919
  • 3
  • 49
  • 83
kilotaras
  • 1,419
  • 9
  • 24
  • Assuming that you do not have to avoid using Selection.Find in this case, what does the Range.Find version do that, e.g. Selecting the whole document or the Table doesn't do for you? (FWIW I see the error too, and using .Execute2007 also crashes Word). –  Apr 05 '14 at 19:22
  • 1
    what do you expect as an answer? I did also check your problem and it's not working for me as well. Therefore I think it is a simple 'bug' which we are not able to solve. And it seems that you have a solution of using `selection.find` feature. What is a goal of the bounty you proposed? – Kazimierz Jawor Apr 06 '14 at 21:14
  • 1
    How can A, B & C be merged but A & B are empty? A screen shot would help me understand better, thanks. – Automate This Apr 06 '14 at 21:26
  • @PortlandRunner Crate table 3x3. Merge two cells in first column, last two cells in second and third rows independently. – kilotaras Apr 07 '14 at 07:03
  • @KazJaw Selection.Find is ridiculously slow in Select part. To give better understanding. We need to verify that our document has format A....B...C...A...B...C where A,B,C are special delimiters with specific style. To do this with select would require to actually select text which is more than 100x slower (even with UpdateScreen off) – kilotaras Apr 07 '14 at 07:11
  • Oh and if you add `FindText:="A"` too the execute statement above, it doesn't crash, but it doesn't find the table or the containing text either. – Rich Apr 10 '14 at 14:38
  • Kilo, is your intention to ONLY search for those values in the tables? Or is your problem that you want to search the rest of the document too, but the specific table situation you describe prevents you from doing so? – Blackhawk Apr 11 '14 at 14:42
  • @Blackhawk the rest of the document. Problem is that sometimes we need to do find next (not all), so we cant go for "check all tables with select, if nothing - run Range.Find" as that is incredibly slow. Looks like we'll have to say "sorry folks, use Word 2010" to clients. – kilotaras Apr 11 '14 at 15:29
  • 1
    Here's a [possible related issue](http://blogs.msdn.com/b/cristib/archive/2012/08/31/vsto_2d00_net_2d00_code_2d00_throws_2d00_system.accessviolationexception_2d00_error_2d00_when_2d00_automating_2d00_the_2d00_find_2d00_object_2d00_in_2d00_word_2d00_kb_2d00_292744.aspx). They talk about looking at the Windows Event Viewer to find the specific Application error associated with the crash. Even if that issue isn't the same as yours, it might help to look at those logs. You can pull up the event viewer by clicking "Start" ---> "Run", then typing "eventvwr.msc" and hit enter. – Blackhawk Apr 11 '14 at 16:38

1 Answers1

1

And you can't just activate a .Find object off the Tables(index).Selection object rather than the range object?

If you are just activating the .Selection object off of the ActiveDocument instead of the Table object then, yeah that could take forever. But coming directly off the table index will speed it up significantly. 

ActiveDocument.Tables(1).Select
With Selection.Find
    .Forward = True
    .Wrap = wdFindStop
    .Execute FindText:="A"
End With
Rich
  • 4,134
  • 3
  • 26
  • 45
  • Problem is you then need to do a lot of those, if you're looking for something that isn't there. Select text between tables, select table, repeat. We tried it before and it was actually slower than straight Select till end approach. – kilotaras Apr 10 '14 at 09:05
  • Then you should iterate through the tables in a separate segment of code just for tables, and then a secondary set of code just for the document. If you keep eliminating possibilities, it will limit the scope of your programming capabilities in the long run. – Rich Apr 10 '14 at 14:48
  • If you specify the exact table it doesnt have to search the rest of the tables in the document. – Rich Apr 12 '14 at 22:14