I have serialized ink analysis data that's raising an exception when I
try to load it. It comes down to the ink data containing a stroke that
doesn't have any packets. I can work around the problem by passing
true for doNotAutoAddStrokes to the InkAnalyzer.

But I'm curious how I ended up with an empty stroke. Is it normal
behavior to have a stroke with zero packets? How might it get created?

Thanks,
Ravi.

Out of curiosity, how did you discover that you had a stroke with no
packets? I've tried actually creating a zero packet stroke before in a
RealTimeStylus plugin to compensate for the inability to "cancel" a packet
but I remember having lots of trouble with it.

--
Josh Einstein (Tablet PC MVP)
Einstein Technologies
Tablet Enhancements for Outlook - Try it free: www.tabletoutlook.com


"Ravi" <ravi.usenet******.com> wrote in message
news:1183730758.166627.293630@n60g2000hse.googlegr oups.com...
>I have serialized ink analysis data that's raising an exception when I
> try to load it. It comes down to the ink data containing a stroke that
> doesn't have any packets. I can work around the problem by passing
> true for doNotAutoAddStrokes to the InkAnalyzer.
>
> But I'm curious how I ended up with an empty stroke. Is it normal
> behavior to have a stroke with zero packets? How might it get created?
>
> Thanks,
> Ravi.
>

On Jul 6, 12:23 pm, "Josh Einstein" <j...@einsteintech.net> wrote:
> Out of curiosity, how did you discover that you had a stroke with no
> packets? I've tried actually creating a zero packet stroke before in a
> RealTimeStylus plugin to compensate for the inability to "cancel" a packet
> but I remember having lots of trouble with it.

It got discovered when my deserialization code choked on it. The
strack trace showed an ArgumentException thrown from GetPacketData. I
loaded the data into an Ink object, called GetPacketData() on each
stroke to identify the problem one, and dumped properties for it.

Looking back at the ink data, I notice that all the other strokes have
exactly one packet each. That's not necessarily incorrect since the
user might have been trying to tap on a small button but missing
slightly. A little odd though.

This app still uses InkCollector for collecting strokes.

Thanks,
Ravi.

That is strange. I would imagine that any stroke, even a tap would need at
least a packet representing pen down and pen up. I honestly don't know much
about the internal structure of the Ink object or how InkAnalyzer persists
it.

In the meantime if Ink object loads it ok maybe you can just round trip it
through the Ink object until you figure out what the problem is?

--
Josh Einstein (Tablet PC MVP)
Einstein Technologies
Tablet Enhancements for Outlook - Try it free: www.tabletoutlook.com


"Ravi" <ravi.usenet******.com> wrote in message
news:1183744950.087464.24380@g13g2000hsf.googlegro ups.com...
> On Jul 6, 12:23 pm, "Josh Einstein" <j...@einsteintech.net> wrote:
>> Out of curiosity, how did you discover that you had a stroke with no
>> packets? I've tried actually creating a zero packet stroke before in a
>> RealTimeStylus plugin to compensate for the inability to "cancel" a
>> packet
>> but I remember having lots of trouble with it.
>
> It got discovered when my deserialization code choked on it. The
> strack trace showed an ArgumentException thrown from GetPacketData. I
> loaded the data into an Ink object, called GetPacketData() on each
> stroke to identify the problem one, and dumped properties for it.
>
> Looking back at the ink data, I notice that all the other strokes have
> exactly one packet each. That's not necessarily incorrect since the
> user might have been trying to tap on a small button but missing
> slightly. A little odd though.
>
> This app still uses InkCollector for collecting strokes.
>
> Thanks,
> Ravi.
>