Hi!

I read on this subject, I just want to know if there's a new way to handle
this.

When I erase using the Point Erase mode, when I lift up my pen, some parts
of the strokes are "unerased".

Is there a way to correct this behaviour?

Thanks

VB

Hi Vincent,

can you include some information about the context of your question?

What type of application are writing (WPF, Winforms, Win32, etc.)? Which
object are you using to collect and erase ink (InkCanvas, InkOverlay, etc.)?
Any other relevant settings properties (DrawingAttributes etc.)?

Thanks
Stefan Wick
http://blogs.msdn.com/swick/


"Vincent Bergeron" wrote:

> Hi!
>
> I read on this subject, I just want to know if there's a new way to handle
> this.
>
> When I erase using the Point Erase mode, when I lift up my pen, some parts
> of the strokes are "unerased".
>
> Is there a way to correct this behaviour?
>
> Thanks
>
> VB
>
>
>

Hi Stefan.

> What type of application are writing (WPF, Winforms, Win32, etc.)? Which
> object are you using to collect and erase ink (InkCanvas, InkOverlay,
> etc.)?
> Any other relevant settings properties (DrawingAttributes etc.)?

I'm writing a Win32 application using the InkOverlay.

Here's the DrawingAttributes for the Pen
Width := 53;
Height := 1;
FitToCurve := False;
IgnorePressure := False;
AntiAliased := True;
Transparency := 0;
RasterOperation := IRO_CopyPen;
PenTip := IPT_Ball;
Color := clBlack;

I tried the C# examples of the SDK and they're doing the same thing. But the
Windows Journal Viewer do not. Maybe it's erasing the ink a different way...

Thanks

VB

Hi Vincent,

you are correct Windows Journal is using a different, custom mechanism to do
point-erasing.

What you observed in InkOverlay is a performance optimization. The strokes
collection does not get re-rendered until the pen (or mouse) goes up. Instead
the eraser path simply gets cut out to visualize the post-erase result. Then
when the pen/mouse goes up, the new stroke shapes get rendered properly, with
smooth edges etc.

There are two options for you to change this behavior:

a) implement your own point-erase behavior without this perf optimization.
The SDK sample "Ink Clipboard" contains a simple example for a custom
point-erase implementation.

b) listen to the "InkDeleted" event on InkOverlay's Ink object and then
invalidate the affected region where the stroke segments got deleted.

Also - just FYI - the InkCanvas object in WPF does not have this limitation
when using its EraseByPoint EditingMode.

Thanks,
Stefan Wick

http://blogs.msdn.com/swick


"Vincent Bergeron" wrote:

> Hi Stefan.
>
> > What type of application are writing (WPF, Winforms, Win32, etc.)? Which
> > object are you using to collect and erase ink (InkCanvas, InkOverlay,
> > etc.)?
> > Any other relevant settings properties (DrawingAttributes etc.)?
>
> I'm writing a Win32 application using the InkOverlay.
>
> Here's the DrawingAttributes for the Pen
> Width := 53;
> Height := 1;
> FitToCurve := False;
> IgnorePressure := False;
> AntiAliased := True;
> Transparency := 0;
> RasterOperation := IRO_CopyPen;
> PenTip := IPT_Ball;
> Color := clBlack;
>
> I tried the C# examples of the SDK and they're doing the same thing. But the
> Windows Journal Viewer do not. Maybe it's erasing the ink a different way...
>
> Thanks
>
> VB
>
>
>