Microsoft error report popup

[menchar]

Ian -

Thanks.  Well, we certainly are pasting in bitmaps - many of them.

It does also seem to us as if there's some dynamic allocation or postponed rendering or somesuch that is right on the edge.  That's why I thought saving it off perdiodically would help, and now the app doesn't crash but we're getting another weird error that looks like some internal buffer getting clobbered - we wind up with a file pathname in a field instead of a title (!?).

At first blush this seems like it might be related.  We're doing about a 40 page report, and there's probably at least 20 bitmaps pasted into it.

It sounds like you empirically determined a file size limit and just stayed below it? 

Menchar

[Ian.W]

Yes, we did indeed just stay below the problematic number of bitmaps.

However, it was not a clear-cut, repeatable thing, and if I recall correctly was really hard to document across different versions of Word and Windows, especially with different behavior exhibited after a fresh reboot. (I think it was in the era of Word 97 on Win 98 and Word 2002 on XP).  We tried all sorts tricks like saving, Delay(), Process____Events() etc. but without success.

Pasting 20 bitmaps (say ~600 x 600) into a single document would have been over our limit for sure. We kept the bitmaps under 5 or maybe 8, and with text the report would have been 25-40 pages in total.

After walking away from that issue, we did see one other similar problem when dumping large numbers of bitmaps (20-40 screenshots) to PowerPoint 2002 via ActiveX: If left open after the creating and pasting, the instance of PowerPoint would occasionally just randomly close some time later, perhaps 3 minutes later.  Everything was properly cleaned up and closed when our app was done pasting, but there seemed to be an over eager garbage collector lurking in the system.  The workaround was to save, close, and re-open the ppt for further editing.

All this has left me rather leery about pasting bitmaps to Office apps.

[menchar]

Ian, thanks for the info.  We'll keep looking at this, we're running more test cases today.

Yup, I don't like the bitmap pasting, it was a system engineer who hacked this all together

He has Word dynamically pasting in everything onto a blank document, including all sorts of fixed fields we could have treated as part of a template, using bookmarks for the dynamic stuff.

The clipboard persists across multiple invocations of Office applications - that's what makes me wonder if that's what's breaking.    And it could account for the apparent randomness, each system a little different as to clipboard state I bet, depending upon what's been running on that system since bootup.  I'll hunt around and see if the Win32 API shows some way of flushing it.

We close the doc, then open it, several times, adding more bitmaps each cycle.  And it's OK on the first cycle now, but goofed on the second. 

Curious the silence from NI on this, I don't think they like supporting their Office ActiveX interface. 

[AndrewMc]

Menchar,

We do not have a problem supporting our interface for Office ActiveX.  It is important to note, however, that we are simply wrapping around Office products' ActiveX servers.  Most of the time when there is an issue like that of Ian (and possibly your issue), it's not due to the way that we're wrapping around the server, but rather an issue with the server itself (and the way it's being used). 

The original forum post is at what point CVI is capable of catching exceptions.  Unless CVI's memory space is being corrupted, we don't typically see a Microsoft dialog take over.  If you have a specific, small example showing this behavior, we would love to take a look at it (as we are constantly wanting to improve CVI).  Otherwise, it just looks like narrowing the problem more would help to address the issue.  Try to figure out at what specific line the exception occurs.  Then, once you find the point where it breaks, look at the contents of the clipboard at that point, check the status of the variables, check the PowerPoint document to make sure everything is intact, etc.


Message Edited by AndrewMc on 11-05-2007 01:58 PM

[menchar]

Thanks for the interest.

I am curious if this function:

CVI_AppSetBreakOnFirstChanceExceptions (CAObjHandle objectHandle, ERRORINFO *errorInfo, long enabled, long *returnValue);

is intended to catch exceptions of the type we're seeing?

[AndrewMc]

This function is intended to catch exceptions when using CVI's ActiveX server.  In this case, you are using Microsoft's ActiveX Server; so this function would not work for that.

[menchar]

I'm curious if maybe we're filling up the Office Clipboard (a separate item from the Windows Clipboard).  It can hold 8MB of stuff and I also see a Microsoft KB item for at least one version of Word that fails to warn when the Office Clipboard fills.

We're using    WordRpt_InsertScaledImage ()   to insert a bitmap that's been created using the CVI function:

SavePanelDisplayToFile ()

Is the bitmap winding up on the "Office" clipboard by any chance?  Is it on the "Windows" clipboard?

Thanks.

Menchar

[menchar]

I noted that when I manually place a bitmap file into a Word 2003 document while using Word interactively on my desktop PC it does result in the bitmapped file being placed on the "Office Clipboard".

I haven't cut or copied the image in the normal sense, just inserted it from a file.

If this is analogous to what happens with the Word Automation controller when we insert a bitmap file, I imagine it could be on the "Office Clipboard" as well.  Depending upon when the clipboard gets cleared (it's not clear from anything I can find exactly when the Office Clipboard is cleared - it persists across Word sessions, it's not a "Word" clipboard), this could account for the goofy behavior we're seeing if it fills up and causes problems.  It looks like the Office Clipboard is supposed to gracefully discard the oldest item on the clipboard when it's out of room.

It seems that some system resource is getting consumed and eventually the Word controller breaks in some ugly way.  We've noticed that an item on the Word doc that should have been rendered into text instead gets left as a pathfilename to a temp file.  It's as if the controller is spawning a thread to do rendering and that this thread then gets aborted, resulting in the unrendered field in the document and an aborted thread that the CVI runtime can't catch.

Menchar


Message Edited by menchar on 11-09-2007 01:18 PM

[Ian.W]

menchar,

That Office clipboard theory seems quite plausible. On occasion in the past I have seen paste operations that unexpectedly resulted in an Adobe Acrobat icon being pased into a Word doc rather than text or an image. IIRC, it happened after a second run of the app that was doing the pasting.  That was with XP and Office XP(2002).  Perhaps this is related to your "pathname in place of text" issue. 

I don't think I've seen any of this kind of pasting issue in Vista/Office 2007- which is my main platform now - but I have not purposefully pushed the limits.

Please keep us posted of any breakthroughs - or requests to test something.

--Ian