wordreport.c error

[LuisG]

Menchar,

You don't need to add the .sub files to the project. These files are companion files to .fp files, and they contain the hierarchy and the documentation of the attributes of the interface. When you browse to one of the attribute function panels, such as SetCtrlAttribute or WordRpt_SetTextAttribute, for example, and you bring up the Select Attribute Constant or the Select Attribute Value dialogs, the information in those dialogs comes from the .sub file.

For ActiveX wrappers like word2000.fp, the .sub file also defines the help context ids used by the server's documentation. So, for example, if you installed the Word help, clicking on the help in the wrapper's function panel will allow CVI to bring up the Word VB help instead.

Luis

[menchar]

Luis -

Thanks for the info.

I am still a bit confused on how to use the ActiveX interfaces to Word.

Do I have to include anything in my project other than the front panels for wordreport and word2000?  I see the worreport.c and word2000.c files recompiling automatically every time the project loads or the debug mode changes, but do I have to explicitly include these sources in the project? 

I realize I need the header file included to compile references to the wordreport.c functions.

And finally, we've encountered yet another weirdness in using wordreport.

I've found the when running in debug mode, CVI will insist on breaking within wordreport.c even though there's no breakpoint present.  We have it breaking at the Error: label in WordRptDocumentSaveAs (...) even though no breakpoint is present.  Break On Library Errors is checked in the Run ... dialogue, but there's no error taking place.

I've seen this when I set a breakpoint inside wordreport.c and then clear it - the IDE never really clears the breakpoint it seems.

Can you shed any light on this?

Thanks,

Menchar

[menchar]

Luis -

We seem to have figured out how to use word2000.fp and wordreport.fp  just like any other instrument - the only nuance is that the IDE manages the relevant .c files and recompiles them as it needs to automatically.

But we're still getting goofed by the phantom breakpoints inside the wordreport.c file.  I have seen this behavior on multiple projects.  It prevents us from being able to run a debug build unattended to catch errors.

Menchar

[LuisG]

Menchar,

You do not need to add anything to your project other than WordReport.fp. CVI will take care of the linking in the source code that is required by wordreport. You shouldn't have to worry about word2000.* at all, since this is a dependency of WordReport.fp that is managed by that module. It does not need to be added to your project.

When you change between the release and debug configurations, CVI does need to recompile the object files that correspond to the loaded modules (in this case, wordreport and, by dependency, word2000). Once CVI compiles an .obj file for an instrument, it caches it in the cvibuild directory of the current project, so that for this project at least, it doesn't need to be compiled again.

With respect to the unexpected breakpoint, this is an ActiveX-related issue that happens sometimes with Word. It only seems to happen with Word. We investigated this back in 2001, but couldn't figure out why this was happening with Word. The breakpoint itself is caused because a correputed variant triggers a debug-level exception from the underlying system code. The variant becomes corrupted after making a COM invoke call to the Word server. We don't know exactly why, since this is happening outside of CVI's code. The good news is that it doesn't seem to have any impact on the correctness of the code. It's just an annoyance that happens when debugging some programs that use Word.

Luis

[menchar]

Where is this abberant behavior documented?  You've made it clear that NI has known about this problem for 6 years or more.  Do you just let every customer stumble into this flaw and try to figure it out for themselves?

Do you know what would happen with this type of error if we were running a debug build of the executable without the IDE? 

[LuisG]

I haven't been able to reproduce this problem in a while, so I can't really confirm this. But if it's the problem I'm thinking of, it should not be an issue if you run it outside of the debugger.

Therre is no report on this issue in the NI KnowledgeBase because it's not something that is sufficiently well understood to completely describe (when does it happen, when does it not, etc...), because there is no solution to provide, and because it doesn't affect the correctness of the program execution.

Luis

[menchar]

Great.

Trust me, it's still happening.