text: Overlay internal property which wraps the IInkOverlay interface (for more information on IInkOverlay see the technical overview ).Overlay();
  /Overlay property to make the required calls to IInkOverlay.
  InkRecognizer a m_pictureBox field which is the standard PictureBox control used to display an image and we use this.
  InkSignature (for more information on extended properties see technical overview).
  InkControlBase Workarounds
  During the development of these control, we implemented some code in the OnMouseDown and OnMouseUp of the InkControlBase.
  Focus Issue if.
  Capture Issue
  The next issue faced was the Capture issue which seemed IInkOverlay always set Capture =);
  }
  InkCanvas. For more information on using Control2 see here. The InkNotesCF Sample demonstrates the use of InkCanvas control.
  Next up we will be looking at Sharing Ink on the Desktop and Windows Mobile.
  Previously:
  InkNotesCF:
  Next we look at the custom controls that where created for the Mobile Ink Library ...
  With ...
  A while ago Alex blogged about using WISP Lite (WISP stands for Windows Ink Services Platform) from managed code (see here). Previously accessing the Windows Mobile Ink API was only available from native code and some examples from Loke and the WM Team can be seen here and here.
  Currently the Smart Device Framework has a the OpenNETCF.WindowsMobile.InkX control but uses the InkX Control API underneath the covers. Since the Windows Mobile Ink API is only supported on Windows Mobile 6.0 and InkX is compatible on Pocket PC 2003+ we decided to release the OpenNETCF.WindowsMobile.Ink source code as a open source project to the community and name it 'OpenNETCF Mobile Ink Library'. Eventually it may be included in the Smart Device Framework but at this point we have no plans to do so.
  If you are interested in using it you can get more information on the project here and don't forget to check out some of the other projects (and products :) ) we have.
  In the next few days I will be following up with some technical information on OpenNETCF Mobile Ink Library.
  Recently I've been doing some build scripts for some products and setting up build environments for clients using MS Build and NSIS Installer. A question that came up was on on the assembly version number and how does the compiler determine the version number if the AssemblyVersion in the AssemblyInfo.cs file is set to 1.0.* ?
  A version number of an assembly consists of major.minor.build.revision. A bit of digging I found this link on MSDN. Basically if you have major.minor.* then * (which is build) will be the number of days since January 1, 2000 and revision will be the number of seconds since January 1, 2000 divided by 2.
  A while back I wrote about creating a IDisposable SolidBrush for the Compact Framework 1.0 for a project I'm working on. I'm done that project now and going back to 1.0 after using v2.0 (and recently playing with v3.5) is not a fun task. The CF team has really done a great job in giving us more functionality since 1.0!
  Control.InvokeRequired is a new feature in CF2.0 and was never available in CF1.0. Why do you need it? Well if you are doing multithreading code and need to update the UI, the UI must be update in the main GUI thread. In CF1 if you update the UI from a background thread the most likely outcome would have been your application hanging. In CF2, you would get an exception saying "Control.Invoke must be used to interact with controls created on a separate thread" (a lot better than your application hanging!).
  There are two ways to implement this functionality in CF 1.0.
  Method 1
  The first method is described here by David back in 2005. Basically you save the Thread.CurrentThread when your form gets created and then you do a comparison whenever you need to update the UI.
  Method 2
  The second method requires the use of a private member within System.Windows.Forms.Control called 'm_thread' which stores the Thread the control was created on. See the screen shot below using the debugger:
  Using Reflection we can obtain this object as follows:
  object controlThread = typeof(Control).GetField("m_thread", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(this);
  Once we get the thread the control was created on we can then compare with the current thread as follows:
  if (controlThread == null) return false; Thread currentThread = Thread.CurrentThread; return (controlThread != currentThread);
  Wrapping this up in a nice property we get:
  private bool InvokeRequired
  {
  get
  {
  object controlThread = typeof(Control).GetField("m_thread", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(this);
  if (controlThread == null)
  return false;
  Thread currentThread = Thread.CurrentThread;
  return (controlThread != currentThread);
  }
  }
  I created a sample for both CF1.0 and CF3.5 (NOTE: for 3.5 you will need Visual Studio 2008 and for 1.0 you will need Visual Studio 2005) application that will update a Label showing how many times the text was changed.
  The following code is used to accomplish this:
  private void BeginUpdateLabel()
  {
  ThreadPool.QueueUserWorkItem(new WaitCallback(UpdateLabelCallBack), chkUseInvoke.Checked);
  }
  private bool m_useInvoke = true;
  private void UpdateLabelCallBack(object state)
  {
  m_useInvoke = (bool)state; //determine if Invoke should be used or not
  UpdateLabel(this, EventArgs.Empty);
  m_useInvoke = true; //reset back to true
  }
  private void UpdateLabel(object sender, EventArgs e)
  {
  if (m_useInvoke)
  {
  //Check to see if we should invoke
  if (this.InvokeRequired)
  {
  this.Invoke(new EventHandler(UpdateLabel));
  return;
  }
  }
  //Update the label
  this.label1.Text = "I was changed (count = " + m_count.ToString() + ")";
  m_count++;
  }
  BeginUpdateLabel() will start a Thread and call the UpdateLabelCallBack() method. Here we determine if we should use Invoke or not depending on checkbox state. UpdateLabel() will determine if invoking is required and we will either call Invoke() to update the label or just update the label.
  If you uncheck the checkBox and click on the 'Update Label Using Thread' button using CF3.5 you will get a NotSupportedException but in CF1.0 the code will be allowed to run with no exceptions. If you click it enough times you will probably have the application freeze.
  So if you are still using CF1.0 hopefully this will come in handy and using the InvokeRequired property above will hopefully allow you to port your code to CF2.0 or CF3.5 when the time comes. (NOTE: The sample application actually shares the same Form.cs file.)
  You can download the sample here.
  The opinions expressed herein are my own personal opinions and do
  not represent my employer's view in anyway.
  Theme design by Jelle Druyts