Executable Export Image - Picture Method - LV Crash - DAbort 0x786DE250 in drawmgr.cpp

[James.M]

Hey guys,

I have a crash showing up in my application when trying to export an image to the clipboard to be pasted in to my Word document. The crash occurs at the Export Image invoke node, but only occurs in the executable and only occurs on the 102nd iteration. If I run the executable with 101 iterations it's fine. If I run with 50 iterations, then run it again at 52 iterations without closing the executable, it crashes.

Code, snippet, executable, crash dialog below. Do any of you have any suggestions or workaround ideas? Is there something that I could change in me executable build settings to fix this?

To run the code, you can change any parameters and then hit Go to run the iterations.

Thanks for the help!

[zou · Accepted solution]

Have you tried other image format, other than EMF ?

[James.M]

Well dang that fixed the crash issue. I'm remembering that there was a reason I used EMF, but maybe something else has changed since then and BMP will work. It looks like BMP and EMF are the only two that don't error out, and EMF crashes at 102. 

Stupid "Did you try..." moments like this make me miss working with other LV developers who could point out suggestions when I hit an issue.

Thanks!

[James.M]

Turns it I was right about there being a reason I didn't use BMP. Pasting as a BMP doesn't populate the "Shapes" count in the Word document, so I can't reference that specific shape to alter it's properties. I was using the properties of the shapes in order to make the pictures in-line with the text when the previously weren't inserting as in-line. I think I've worked around this now though because the report is outputting alright.

Thanks for the help!

[James.M]

Well, now it turns out I need to use EMF because the way the BMP format insert the shape results in some weird stuff that I can't work with.

Does anybody have a suggestion to get around the 102nd image copy crash? Is there a way to kill the VI's memory space and reload after a few runs? Would Call By Reference not load the VI in to memory until the call?

[zou]

When you export an BMP (raster image) to EMF (vector image), you only get an EMF wrapper of BMP, not a true vector.

There is no way to do that convert.  Not in any programming language.

Maybe you can show us the image?  and tell us why you want to resize it 100+ times?

[James.M]

The VI I attached and the executable along with it have one of the images set as the default value.

I'm not trying to resize a single image 100+ times, I'm trying to resize/copy/paste 100+ images in turn. The crash occurs at the export image node and getting rid of the resize/zoom/etc doesn't get rid of the crash.

I'm not sure what you mean about the EMF wrapper. Does not having a true vector image affect the way an image is copied to clipboard?

[zou]

An EMF file, just like the LabVIEW picture control, can have vector parts (such as draw a line, a rect, etc.) and raster parts (such as fill a rect with a pattern).

When resize, the vector parts will keep its line width; the raster part will loss its resolution.

[James.M]

I'm fine with losing the resolution on overlays and vectors. Like I said before, the resize isn't the issue here. The crash occurs with or without the resize.

[zou]

If no memory leak, and resize is not a problem, sounds like a LabVIEW bug.

Alternative, you can do this with .net plus GDI+

GDI+ is not hard to learn.

It's part of the OS.  Already on your hard disk.