custom points

[Sof]

Well the way I see it, with regards to David's workaround, I would have to:

-load the initial image to .NET
-change the color using .NET
-write that image to disk
-build a URL and assign it to the annotation image
-reload image

Right now loading annotation images alone for 30 plots @ 50 pts each takes about 8 sec (borderline acceptable).  Using the above, it will no doubt take longer, most likely pushing us into the unacceptable region.

We could pre-design all the images and have them on disk at start-up which would be 16 images X 3 (sub-class style of each image) X 40 colors (max plots) = 1920 images.  But no, we are not going to cart around 2000 images on every target machine! 

You guys got any better ideas?  We may have to go with using polygon draws on the annotation.  That, however, presents it's own  headaches!!!  That is why we are trying to shoe-horn the annotation images.

[JonathanN]

Hi Scott,

We have actually been investigating this issue over the last few days and we tried several .wmf files and we had no problems using those CWImage methods (Reload, Substitute, etc). Is there something specific about the .wmf file you are using that is different than most common .wmf files? Anything that can help us determine the actual problem would be useful. 

Could you perhaps post several .wmf files that are causing problems? Does the code snippet you posted not work on any .wmf files?

Thanks

Best Regards,

[Sof]

better yet, can you post your wmf image?

[JonathanN]

Hi Scott,

Here is the image, works.wmf. I have also attached a screenshot of an example program I wrote displaying the before and after image. Additionally, I have attached the C# example program so you have something to actually load up.

Let us know what you see!

Thanks

Message Edited by Jonathan N on 09-13-2007 04:53 PM

[JonathanN]

Hi Scott,

I just wanted to add on a few things. The reason that some of the .wmf files (we tested and that were included in the bug report) didn't work was because those wmf files used a metafile operand called "DIBSTRETCHBLT" to draw the image.  Now this operand takes in a DIB (Device Independent Bitmap) data block as a parameter which contains the bitmap to be drawn. Since the color was embedded within the bitmap, we were not able to change it.  So basically wmf files that contain "DIBSTRETCHBLT" or similar operands, which use DIB's cannot use the SubstituteColor feature.

If you take a look at the metafile records of the wmf file that I attached to the previous post, you will find that it used operands like POLYGON, POLYPOLYGON, etc, to draw the image. Other wmf files that didn't work used the DIBSTRETCHBLT to draw the images.

Thus the best option for you is to make sure that your wmf files don't use that operand (i.e. just use vector graphics).

Best Regards,

[Sof]

BTW, I implemented this and it worked.  The reason it was not working was because the custom WMF's I was creating had a "Bitmap" layer which probably translated to the DIBSTRETCHBLT section of the WMF.  Once I removed the Bitmap layer from the WMF and used Vector layers exclusively it worked as advertised.

Thanks for the help and sorry I hadn't gotten back to you sooner with results.

Scott