Thank you so much, i will try it now.

regarding the DataObject issue, i've communicated with the fpSpread Tech. support and they added a method for me RenderToMeta file so that i can get the fpspread into a meta file format and then set the picture prop of the box to that meta file at the time of printing.

and it works fine, but for your knowledge the fpSpread support tech told me that its tool implements IViewObject:raw and should render correctly to a metafile device context.

below is the final reply of the fpspread product manager.

"" Hi Andrew,

I agree with the FlowChartX support tech, you should not have to do
anything special in your code to make this work.  Spread implements
IViewObject:raw and should render correctly to a metafile device
context.  It does not, however, have any default behavior for
IDataObject -- it is implemented only for use with OLE drag and drop,
and you need to write code in the appropriate events to specify what
formats and data you want to provide to the drop target.  If the flow
chart control is calling into the IViewObject:raw method to draw the
control in a meta file, and not trying to get a meta file from the
IDataObject interface, then it should work. ""

Thanks again,
Andrew

Hi Stoyo, sorry for disturbing you again.

But the box hosting an axcontrol is still shifting one pixel to the right and other to the bottom even when i set the control padding to 0.
Also, i feel that the performance of DrawShape is not consistent i mean sometimes there is a shifted pixel to the right and to the bottom edges and sometimes (rare) to the bottom only!!

Is there any solution for this?

Thanks again

Yes, i'm sure of using that version.

what do you mean by the box co-ordinates?
the axcontrol is shifted with any box dimension, but in general the box size is rarely less than 70-100 width and 20 height.

Also even when the padding is = 0 the bottom or  right border is still visible.

Ok, we've found now how it happens in GDI+ graphics mode; we were trying it only in the classic mode where it works fine.

Upon a further investigation, it seems that happens when ZoomFactor is different than 100. Can you confirm that? We are not sure if we can fix anything about this. ZoomFactor leads to a ScaleTransform applied to the Graphics object; in GDI+ this might lead to non-integer coordinates of the box border, while the hosted ActiveX control can only have integer coordinates, and thus there's some space left sometimes between the box border and the hosted control. If this happens at your side because of ZoomFactor too, you might try using some rounded values as a workaround, e.g. 25, 50, 75, 100.

Stoyan

We can see this happen only after zooming in. So you are not using any of the ZoomToFit, ZoomToRect, ZoomIn methods or the ZoomFactor property?

Are you using MeasureUnit = Pixel ?