https://www.microsoft.com/en-us/kinectforwindows/develop/developer-downloads.aspx

After installing the SDK, you might want to install the Developer Toolkit also, in order to study the source code for different functionalities. The Toolkit is available here:

https://www.microsoft.com/en-us/download/details.aspx?id=34807

You have plenty of sample projects for the various things that you can program for Kinect, from gesture recognition to face or voice recognition.

Once you installed those two things, you can start developing something interesting. For example, in the sample projects you have an application that demonstrates how to use swipe gestures to browse through a photo archive. In this tutorial, we will use the same functionality to create a more useful application: an add-in that allows a presenter to swipe through the slides of his PowerPoint presentation.

In order to do that, we will use a few elements:

1. The Kinect drivers and SDK. Be aware that the Kinect drivers are not available separately, but only inside the SDK, and if you will want to install your final application on another machine, you will need
   to install the SDK on that machine also
2. The Kinect sensor
3. An add-in containing code for gesture recognition and for PowerPoint slide change
4. Visual Studio 2010

First, create a PowerPoint 2010 Add-in in VS 2010, by choosing the standard project template.

In the Kinect Developer Toolkit, you will find a sample application named “Slideshow Gestures – WPF”. Install the project and open it with VS 2010.
Look at the references and you will see that it uses a .dll named Microsoft.Samples.Kinect.SwipeGestureRecognizer.dll.
Copy this dll to your Add-in project and add it to references, as it will be in charge of the swipe gesture recognition.

Add these two using directives to the main page of your project:

using Microsoft.Samples.Kinect.SwipeGestureRecognizer;
using Microsoft.Kinect;
 

And then, in the AddIn class, declare the Kinect sensor and the Recognizer private members:

private KinectSensor nui;
private Recognizer activeRecognizer;
 

In the Startup method of the AddIn application, we initialize these variables:

private void ThisAddIn_Startup(object sender, System.EventArgs e) 
 {
 this.activeRecognizer = his.CreateRecognizer();
 this.InitializeNui();
 }

In the CreateRecognizer method, we hook to the swipe events of the gesture recognizer:

 private Recognizer CreateRecognizer()
 {
 // Instantiate a recognizer.
 var recognizer = new Recognizer();
 // Wire-up swipe right to manually advance picture.
 recognizer.SwipeRightDetected += (s, e) =>
 {
 try
 {
 this.Application.ActivePresentation.SlideShowWindow.View.Next();
 }
 catch (Exception ex)
 {
 //…
 }
 };

 recognizer.SwipeLeftDetected += (s, e) =>
 {
 try
 {
 this.Application.ActivePresentation.SlideShowWindow.View.Previous();
 }
 catch (Exception ex)
 {
 //…
 }
 };
 return recognizer;
 }

In the InitializeNui() method, we are checking for all the available Kinect sensors:

 private void InitializeNui()
 {
 this.UninitializeNui();
 var index = 0;
 while (this.nui == null && index < KinectSensor.KinectSensors.Count)
 {
 try
 {
 this.nui = KinectSensor.KinectSensors[index]; 
 this.nui.Start(); 
 this.IsDisconnected = false;

You will find all this code in the “Slideshow Gestures” application from the Kinect Developer Toolkit. In our PowerPoint Add-in application, we are only using a part of that code, to achieve the intended functionality.

As you can see, the main actions are sliding through the PowerPoint presentation when the Recognizer is capturing a swipe left/right event.

Next, you only need to create an installation package to distribute this add-in. In the Solution Explorer, right-click on the project and select Publish. Specify a location on the disk and click Next. Choose “From a CD-ROM…” and click Next, then Finish.

Install the add-in on a presentation machine and check these steps to make sure it is properly installed: In PowerPoint, to File->Options->Add-Ins. In the “Active Application Add-ins”, you should see the add-in. If the add-in is not present, verify the “Manage: “ list at the bottom of the page: select COM add-ins in the list, click Go, check the <name of your addin> option in the list, click OK.

To connect the Kinect sensor to your PC, you need a Kinect adapter, as the connector of Kinect doesn’t match the USB of your PC, and they also need an external power source. Once the Kinect sensor is connecter and the PowerPoint presentation is started, the red light on the sensor should be on, which indicates that the sensor is recognized by the application.

Start the PowerPoint slideshow.

Stand in front of the Kinect sensor at a distance between 1.5 meters and 4 meters

To move to the next slide, do a swiping movement with your right hand, from right to left. The hand should be at chest-level and the movement should be continuous

To move to the previous slide, do a swiping movement with your left hand, from left to right

That would be all. You can use this sample in your team presentations, to leverage the Kinect technology and demonstrate that it can have a multitude of uses, outside the gaming world.

You can download the sample from here: https://sdrv.ms/13PMDX0

https://msdn.microsoft.com/en-us/magazine/cc163634.aspx

With help from Dmitry, who relentlessly investigated the matter, here are the main steps for creating this project.

First of all, we create a VS 2010 Win forms project and make sure we set the project for .NET 4 , not .NET 4 Client profile.

Add a reference to System.Design and then create a form named ParentForm. This will be the form on which our Designer will be place.

Next, we create a form named DesignForm, which will be the actual area for the controls to be placed.

On the ParentForm we add this code:

public ParentForm()
 { 
 InitializeComponent(); 
 System.ComponentModel.Design.DesignSurface
 ds = new System.ComponentModel.Design.DesignSurface(); 
 ds.BeginLoad(typeof(DesignForm));
 Control c = ds.View as Control; 
 c.Parent = this; 
 c.Dock = DockStyle.Fill;
 }

Now, the DesignForm is a child of ParentForm.

We will now proceed to the creation of class EditableLabelDesigner derived from ControlDesigner

class EditableLabelDesigner : ControlDesigner 
 { 
 private const int WM_LBUTTONDBLCLK = 0x0203;
 
 public override void Initialize(IComponent
 component) 
 { 
 base.Initialize(component); 
 }
  

 protected override void WndProc(ref
 System.Windows.Forms.Message m)
 {
 if (m.Msg == WM_LBUTTONDBLCLK)
 { 
 ((EditableLabel)Control).ShowInplaceEditor();
 }
 base.WndProc(ref m);
 }
 }

The WndProc method will catch the WM_LBUTTONDBLCLK event and show the editable area on the label.

Next, create the custom control EditableLabel:

Add new user control EditableLabel

[Designer(typeof(EditableLabelDesigner))] 
 
 public partial class EditableLabel : Label
 {
 public EditableLabel()
 { 
 InitializeComponent();
 } 
 
 private TextBox inplaceEditor;
 private bool isRedrawn = false;
 public TextBox InplaceEditor
 {
 get { return inplaceEditor; }
 }
 
 public bool IsRedrawn
 {
 get { return isRedrawn; }
 set
 {
 if (value == true) 
 {
 if (inplaceEditor != null) 
 {
 Text = inplaceEditor.Text;
 inplaceEditor.Visible = false;
 }
 } 
 isRedrawn = value;
 }
 }
 
 
 
 protected override void OnPaint(PaintEventArgs e)
 {
 if (!isRedrawn)
 { 
 IsRedrawn = true;
 }
 base.OnPaint(e);
 }
 
 public void ShowInplaceEditor()
 { 
 isRedrawn = false;
 if (inplaceEditor == null)
 { 
 this.inplaceEditor = new TextBox(); 
 inplaceEditor.Parent = this.Parent.Parent; 
 inplaceEditor.Multiline = true;
 }
 
 
 inplaceEditor.HideSelection = false; 
 inplaceEditor.AcceptsTab = true; 
 inplaceEditor.Text = this.Text; 
 inplaceEditor.Visible = true; 
 inplaceEditor.Location = new Point(this.Parent.Location.X
 + this.Location.X + 10, this.Parent.Location.Y + this.Location.Y
 + 32); 
 inplaceEditor.Size = new Size(this.ClientRectangle.Width
 - 4, this.ClientRectangle.Height - 4); 
 inplaceEditor.Font = this.Font; 
 inplaceEditor.SelectAll(); 
 inplaceEditor.BringToFront(); 
 inplaceEditor.Focus();
 }
 }
 

In the ShowInplaceEditor, the TextBox is added to the DesignForm’s parent, so it will be editable. 

Finally, in the ParentForm constructor, we add the EditableLabel on the DesignFom:

 IDesignerHost idh = (IDesignerHost)ds.GetService(typeof(IDesignerHost));
 IToolboxUser itu = (IToolboxUser)idh.GetDesigner(idh.RootComponent); 
 itu.ToolPicked(new ToolboxItem(typeof(EditableLabel)));

Make sure to put the ParentForm as the staring form of your project, and you’re done.

You can find the sample project here.

An ocx (yes, apparently they are not extinct) component written in C++ was receiving a string from a .NET application. After executing a bunch of procedures on this string, it was supposed to return it to the calling .NET application, to be displayed. The ocx’s solution was VS 2008.

The string was at some point going to the component as ‘99’ and it was receiving an initial ‘0’, so the expected result was ‘099’. Instead, we were receiving only ‘09’.

In the component’s code we had a CString object holding the string value and passing it to various methods and functions. Some of these functions were old C functions, and they were working on the string held in the CString object.

What we had could be reduced to this:

         CString test;
         test = "99";
         char* pchar = (char*)test.GetBuffer(0);
         strcpy(pchar, "099");
         test.ReleaseBuffer();
         _tprintf(_T(“%s”), test);

The strcpy part was coming from one of the C-style functions, and was supposed to add the extra ‘0’ to the beginning of the string.

GetBuffer() is returning a pointer to the object’s null terminated character buffer. So we had a pointer to a string with 2 characters, and then we copied 3 characters at this address: strcpy(pchar, "099");

We were lucky enough not to corrupt any other program variable, but we ran into trouble a little bit later, when we called test.ReleaseBuffer():

void ReleaseBuffer( _In_ int nNewLength = -1 )
                {
                   if( nNewLength == -1 )
                   {
                       int nAlloc = GetData()->nAllocLength;
                       nNewLength = StringLengthN( m_pszData, nAlloc);
                   }
                       SetLength( nNewLength );
                }

As you can see, we already have a nAllocLength member variable of CString holding the string’s length. And that is 2, even after we copied the 3-characters string over the buffer. So, we will be calling SetLength(nNewLength) with a value of 2:

void SetLength( _In_ int nLength )
                {
                  if( nLength < 0 || nLength > GetData()->nAllocLength)
                      AtlThrow(E_INVALIDARG);                         

                  GetData()->nDataLength = nLength;
                  m_pszData[nLength] = 0;
                }

So, in the final line of SetLength, the last character of ‘099’ is set to 0, and the string becomes ‘09’.

As the developer of the control confirmed that this problem was not present in the previous versions, I checked this behavior on VC++ 6.0 also.

Here, the definition of ReleaseBuffer is different:

void CString::ReleaseBuffer(int nNewLength)
{
   CopyBeforeWrite();  // just in case GetBuffer was not called

   if (nNewLength == -1)
     nNewLength = lstrlen(m_pchData); // zero terminated

   ASSERT(nNewLength <= GetData()->nAllocLength);
   GetData()->nDataLength = nNewLength;
   m_pchData[nNewLength] = '\0';
}

We don’t have a member variable in CString to hold the string’s length anymore, but we take the length directly from the string’s buffer, with lstrlen(m_pchData). This will allow us to write any string, with no regards to the initial size held in the CString class, and we will still get the length. Then the string will be nicely ended with ‘\0’:            m_pchData[nNewLength] = '\0';

This will make the code ‘work’ in VC++ 6.0 and it will cause the unexpected behavior once we move to newer versions.

To fix this, we need to pass the length of the incoming string to GetBuffer. Instead of

char* pchar = (char*)test.GetBuffer(0);

we will have

char* pchar = (char*)test.GetBuffer(3);

This way, there will be no going over the boundaries of the existing string, and the length will also be properly defined, so ReleaseBuffer and SetLength will not mess with the string anymore.

As per the method’s documentation, it can be used as:

str x = await sc.GetDataAsync(int value) 
 

And the method itself, if we look at the declaration, returns

System.Threading.Tasks.Task<string> 
 

In order to use the new await keyword, introduced in .NET 4.5, we need to be in an async method. You can find more information about asynchronous programming in VS 2012 on MSDN:
https://msdn.microsoft.com/en-us/library/hh191443(v=VS.110).aspx

So, assuming I am doing this proxy initialization and method call in Button_Click, the code needs to look like this:  

private async void Button_Click_1(object sender, RoutedEventArgs e) 
 { 
 ServiceReference1.Service1Client sc = new ServiceReference1.Service1Client(); 
 string str = await sc.GetDataAsync(10); 

This will prevent the application from freezing until the method returns from the service. You can test this by adding a System.Threading.Thread.Sleep(5000); in the GetData method of the service, and you will see that the other controls of your application remain responsive.

Further on, let’s say that you don’t want to have an async method, and you insist on your application remaining frozen until the work on the service side is done. Maybe you secretly believe that this approach will give you special super-powers, or maybe you have some other valid arguments for doing so. Anyway, if you want to do that, you only have to look at the method’s signature and see the return type:

System.Threading.Tasks.Task<string>

You can then go on like this, retrieving a Task<string> object from the proxy method and then reading the Result property, which will contain the actual string returned by the service’s GetData.

Task<string> s = sc.GetDataAsync(10);
this.TextBox1.Text = s.Result; 

Sure enough, you will be able to enjoy your popcorn while staring at the locked screen for the next 5 seconds, while the WCF service does it’s Sleep(5000) routine.

Let’s say that you create an add-in in VS 2010 and you need to have it perform different actions on the build events.
You will add the

_applicationObject.Events.BuildEvents.OnBuildBegin += new _dispBuildEvents_OnBuildBeginEventHandler(BuildEvents_OnBuildBegin);

instruction in the OnConnection() method and then add the BuildEvents_OnBuildBegin method:

  void BuildEvents_OnBuildBegin(vsBuildScope Scope, vsBuildAction Action)
        {
              Console.WriteLine("onbuildbegin");
        }

Build the add-in, go to Debug->Start Debugging, which will open a new instance of VS 2010. Create a new application which will use the add-in, load the add-in with Add-in Manager and put a breakpoint in the BuildEvents_OnBuildBegin method. Build the new application and you will see the execution stopping at the breakpoint, as expected.

If you do the same scenario in VS 2012, you can see that the OnBuildBegin event seems not to be raised anymore and the BuildEvents_OnBuildBegin method is no longer being called.
The apparent ‘workaround’ for this is to add a reference to _applicationObject.Events.BuildEvents in the OnConnection method of the add-in Connect class: 

private _BuildEvents _buildEvents;
public void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom)
              {
            _buildEvents = _applicationObject.Events.BuildEvents;

Curious to see if this is a bug in VS 2012, I looked for previous scenarios and bugs referring to this issue. I could find a reference to a similar situation in VS 2003, which was signaled as a bug and seemingly fixed. I also found this KB, which explains pretty much the same thing and offers the same solution:https://support.microsoft.com/kb/555102

It all pointed towards a bug which existed in earlier versions, had been fixed and the fix wasn’t ported to VS 2012. It turned out that this wasn’t the case.

When the developers of VS 2012 analyzed the call stack, it could be seen that the RCW for the BuildEvents object was finalized by the GC and the event is unadvised. Adding a reference to BuildEvents in the class saves the object from being GC-ed and is actually the correct way to do it. The reasons why this used to work on previous versions are not quite clear, but it has probably something to do with a very short cycle for subscribe and receive event, in which the GC didn’t intervene and the event could be caught before finalizing the object.

Also, this wasn’t always true, as we can see if we dig deeper and find these articles and discussions which mention the problem for VS 2005, VS 2008 and VS 2010:
https://www.mztools.com/articles/2005/MZ2005012.aspx
https://social.msdn.microsoft.com/Forums/en/vsx/thread/d48448d1-b00e-4520-bdf7-685640b0f072
https://social.msdn.microsoft.com/Forums/en/vsx/thread/ee827d4f-db11-497b-9135-bb344a144d52