Error -2147417846 in Word_Get_Range.vi in Report Generation Toolkit RGTK

[LuI]

Hi,

in my large app there's a need to report lots of text results to various positions in the report. I've created a template with roughly 200 bookmarks. And I've got a wrapper around 'Append Report Text Str.vi' that stores an array of strings at an array of bookmarks. This one runs quite OK most of the time, especially since I've put a 200ms delay into the for loop that calls 'Append Report Text Str.vi' as often as required. But sometimes I got the error Error -2147417846, which is basically caused by Word_Get_Range.vi. Finally this states, that 'the application is busy' (my translation of a German error message). I assume that this means that MS Word 2k is busy.

IS THERE ANYTHING I CAN DO?

* Assuming that the whole RGTK is based on Active-X calls to MS Word 2k, is there any means to detect such situations when Word is busy?
* How much calls can it accept?
* Is there any delay that keeps those errors from arising?
* Does this error mean that the last text was not written and the call must be repeated?

I've got the impression that the whole RGTK is not that rock solid stable; Sometimes I got weird error messages within Word, for example that the hyphenation module for Italian Language could not be found. But I'Ve never ever used anyting with Italian, neither installed support for this nor do I speak Italian.

Any Ideas?

Greetings from Germany!
--
Uwe

[Watermann]

hi Uwe,

sorry, but I found nothing relating to this error number.
how is the behaviour when increasing the loop delay?
is it possible to test the application with MS Word 2003?

greets!

[LuI]

Waterman,

---

@Watermann wrote:
hi Uwe,

sorry, but I found nothing relating to this error number.
how is the behaviour when increasing the loop delay?
is it possible to test the application with MS Word 2003?

greets!

---

At this time I have a delay of 250 ms inside the loop and it works most of the time when adding text strings only. It breaks however when I attempt to add a graph into the report and than have the loop with other text strings following quickly. In execution highlighting mode it works reliably.


Ähm, maybe I could try getting a Word2003 license. But I'd prefer avoiding the hazzle of upgrading just for a try.

I was a technical author for several projects and with several version of MS Word. My impression was that there have been just a very few bugs that had been fixed with newer versions. Almost ever they introduced new features with new bugs instead.

So if you have a good reason that this would help, I'd try it.

Thanx for your reply!

Greetings from Germany!
--
Uwe

[Watermann]

hi Uwe,

I found only an older case in database where something was told of a bug of MS Word... so I wouldn't advice you to upgrade just for a try... think this relates to something else...

sounds like the data flow (if too much) needs more time then the 250ms. that would explain why the application works reliable in highlight mode...
can't you increase the loop delay to (e.g.) 500ms for testing purposes? or would that be to slow for you?

[LuI]

Well, the whole run puts about 90 text strings into a word document.
AND even worse, the system is supposed to run up to 10 processes in parallel.
To have that really 'safe', I'd assume I had to put a wait before every single call to MS-Word. Now it counts ;-((
AND there's no way to test the whole setup, except performing a load ballance test.

It would have been so much easier if such a number was availabel as 'each call to MS Word takes not more than 345 ms'. Or 'Use the xxx.yyy.zzz event to determine that MS Word has finished the actual action'. The latter was the more elegant way and IMHO, the way NI should provide with THEIR toolkit!

[Michael_Munroe]

One other idea is to check the Options->Save tab. Disable both Allow background saves and Save AutoRecover info. If you are constantly sending new data to Word, and the AutoRecover kicks in, the application will be busy. If your code saves the document periodically with the background save enabled, the next call could fail.

[LuI]

Michael,

thanx, I'll check that.

But finally this is curing the symptoms, not the causes, I'd say.
Assume some more time consuming jobs like scaling pictures or so. Either the ActiveX interface should not accept new jobs until the actual is ready. Or it should provide an event as mentioned before. Or it should operate a 'job list' and shall not produce such errors....

Greetings from Germany!
--
Uwe

Message Edited by LuI on 06-28-2005 06:29 PM