We have an ASP.NET web system using Infragistics library (.NET framework 4, Visual Studio 2010). We tried to upgrade the project from Infragistics4 10.3.20103.1013 to 10.3.20103.2217, and found an issue on the Infragistics4.WebUI.Excel.v10.3 library. We use the library to generate an excel report with images (view the attached jpg file), below is the code in a loop for adding images to an excel worksheet:
MemoryStream ms = new MemoryStream((Byte[])a_dv.Table.Rows[k][m]);
WorksheetImage imageShape = new WorksheetImage(System.Drawing.Image.FromStream(ms));
imageShape.TopLeftCornerCell = wb.Worksheets[0].Rows[intCurrentRow].Cells[m];
imageShape.TopLeftCornerPosition = new PointF( 0.0F, 0.0F );
imageShape.BottomRightCornerCell = wb.Worksheets[0].Rows[intCurrentRow].Cells[m];
imageShape.BottomRightCornerPosition = new PointF( 100.0F, 100.0F );
wb.Worksheets[0].Shapes.Add(imageShape);
It is working right on 10.3.20103.1013 but not on 10.3.20103.2217, in which the height of those images are lengthened recursively: the height of the image at the first row is correct (fig. 1), and the image on the next row is lengthened by ~2 times (fig. 2), and the image on the next row is lengthened by ~3 times (fig. 3), so on and those latter images are ridiculously lengthened. Please advise for the solution. Thanks.
Check the PositioningMode of the shapes you are creating. I believe it was around the 10.3 version when code for honoring this property was added. So it's possible it was only working before because we were not honoring the PositioningMode correctly. This is probably the case if you are placing shapes on the worksheet and then resizing rows and columns. But if that is not the issue, would you be able to post a sample which reproduces this?
Tested through the 3 positioning mode, it seems they're not behaved as espected:
1. DontMoveOrSizeWithCells - Work as expected
2. MoveAndSizeWithCells - the WorksheetImage moves with the cell, but not resized
3. MoveWithCells - the WorksheetImage moves with the cell, also resized abnormally (as mentioned in the first post)