Friday, June 01, 2007

I was quite surprised to learn that apparently I have missed an important new feature of Windows Mobile 6 (Professional)- inking and ink serialization support. Gone are the days when a developer had to tinker with oh-so-temperamental InkX control. Now everyone and his brother can take advantage not only of high-quality precision ink support with smoothing and serialization, but also of handwriting recognition built into Windows Mobile 6 Professional. To quote the documentation - "It provides a rich inking experience, through high quality curve–fitted ink with anti-aliasing, transparent ink, and highlighter ink. It provides an API for Ink collection, data management, rendering, and recognition. It also provides Ink controls to support the note–taking scenario."

Another important feature is interoperability and serialized data format compatibility with ink support on Tablet PC.

While all of this is nice, there is slight bit of bad news - using this rich set of goodies requires C++. There are 2 ways to use ink in Windows Mobile 6 - InkCanvas control and an COM automation library. InkCanvas control offers the ability to use a regular Win32 control (similar to InkX) to write, highlight, collect ink etc via a set of Windows messages. COM automation library on the other hand allows accessing the entire set of features offered by WISP. And there is no managed wrapper for the time being.

As a public service, we at OpenNETCF.com are proud to offer WISPLite managed wrapper. The wrapper offers the entire WISPLite functionality (although not every method of every interface has been tested). There is InkControl class, which wraps InkCanvas, and a OpenNETCF.WindowsMobile.Ink namespace that contains imported COM interfaces. Some of the interfaces do not wrap cleanly, so a bit of coding is needed.

Here is what the demo app looks like (warning, before running it, change line 132 in Form1.cs to be

inkControl1.SetPenStyle((float)trackBar1.Value, penColor, penType); )

Saving ink data to a file:

using (SaveFileDialog fd = new SaveFileDialog())
{
  fd.Filter =
"Ink files (*.isf)|*.isf|All files (*.*)|*.*";
 
if (fd.ShowDialog() == DialogResult.OK)
  {
   
byte[] data = (byte[])inkControl1.GetInkData(IC_INKENCODING.BINARY);
    FileStream stm = File.OpenWrite(fd.FileName);
    stm.Write(data, 0, data.Length);
    stm.Close();
  }
}

Getting ink as bitmap and retrieving recongnition result:

pbPreview.Image = inkControl1.GetInkDataAsBitmap();
lblReco.Text = inkControl1.RecognizedText;

In conclusion I'd like to ask to report problems with this wrapper to this blog's comments.

6/1/2007 2:20:22 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [3]  | 
8/7/2007 11:42:27 AM (Pacific Daylight Time, UTC-07:00)
Hi Alex,

Thank you so much for the managed Ink wrapper! I coded one small WM6 ink project using C++ and then knew all over again why C# and managed code were such an advance. So thanks for saving me the work of building the wrapper myself...

The InkControl demo works fine on both the emulator and my WM6 device. It inks and recognises fine.

However, I have a problem with the other InkObj (WispLite) demo. It loads and runs ok and allows you to write in the allotted space on the form. Then, once you lift the pen, instead of recognising the ink, it fails to respond to any other control (including the Exit menu). The only thing that works anymore is the X button on the form. Since the other demo works, I assume its not my device hardware of software.

Before running the app, I installed the Ink Library and then the community preview edition of the Smart Framework then the latest Service pack in that order.

Any clues as to what could be causing this behaviour?

Thanks...

Robert
9/27/2007 9:28:07 AM (Pacific Daylight Time, UTC-07:00)
Alex, halo:

I have recently used your wrapper for AxWindowsMediaPlayer. It is really good and saved me alot of times for my project.

I do experience one problem though. I used your AxWindowsMediaPlayer as the way I usd wmp.dll on another desktop app, since they expose the same object model. But when I try to play files from a server, the desktop app streams from the server, but the device doesnt, it starts to playback only after the content is downloaded. I would say this is probably nothing to do with the wrapper that you implemented, because it expose the interface from COM.

Another clue is that when i open the same content from the wmp application on the device, it can stream. I was thinking the OCX and WMP app use the same functions, so if the WMP can stream, so can my app. Or I am making a wrong assumption.

Do you see any problem in my logic?
Thanks in advance.

Xuan Li
2/6/2008 2:40:46 AM (Pacific Standard Time, UTC-08:00)
there are some problems when compiling the source
Name
E-mail
Home page

Comment (HTML not allowed)  

Enter the code shown (prevents robots):