As I mentioned elsewhere, I'm working on a DXCore plugin to enable (Tablet PC) ink drawing on the Visual Studio editor surface. A problem I stumbled upon in this regard was the scrolling functionality. Generally this is really easy to implement, using a transformation with the ink renderer. So I had this method:

void UpdateScrollPosition(TextView textView) {
  Point p = new Point(textView.ColumnWidth * textView.HorizontalScrollPosition,
    textView.LineHeight * textView.VerticalScrollPosition);

  collector.Renderer.PixelToInkSpace(textView.Graphics, ref p);
  Matrix matrix = new Matrix();
  matrix.Translate(-p.X, -p.Y);
		
  collector.Renderer.SetViewTransform(matrix);
}

After wondering for a while why this didn't work, I put in some logging and found that the value passed in as -p.Y was actually growing for every call into that method, regardless how I was dragging the vertical scrollbar. The explanation was simple in the end, as these explanations tend to be: the PixelToInkSpace method takes any current transformations into account, so that any calculation is relative to an origin set earlier - in the last update, in fact. So the solution was to use an offset for the calculation and everything started working:

void UpdateScrollPosition(TextView textView) {
  Point p = new Point(textView.ColumnWidth * textView.HorizontalScrollPosition,
    textView.LineHeight * textView.VerticalScrollPosition);
  Point origin = new Point(0, 0);

  collector.Renderer.PixelToInkSpace(textView.Graphics, ref p);
  collector.Renderer.PixelToInkSpace(textView.Graphics, ref origin);
  p.Offset(-origin.X, -origin.Y);
  Matrix matrix = new Matrix();
  matrix.Translate(-p.X, -p.Y);
		
  collector.Renderer.SetViewTransform(matrix);
}

When installing add-ins for Visual Studio, a number of different paths can be used. One of them is C:\Documents and Settings\All Users\Application Data\Microsoft\MSEnvShared\Addins - in a default installation of a US English Windows. Obviously a proper installer would use Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) to make sure the path is correct for the current system and for the current language. For example, for a German system the result would be C:\Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\Microsoft\MSEnvShared\Addins.

Now, the funny thing is that a part of the path is stored by Visual Studio verbatim. To be precise, VS stores the path as %ALLUSERSPROFILE%\Application Data\Microsoft\MSEnvShared\Addins, as you can see in VS using Tools/Options/Add-in/Macros Security.

Obviously they forgot that the Application Data part wouldn't be called that in a localized version of Windows. So if you want to install your add-in into that path, you should make sure you fiddle around with it to create a mixed-language version, which fits the template used in the VS settings.