AmpScm / AnkhSVN

AnkhSVN provides first class Subversion support for all recent Visual Studio versions.
Apache License 2.0
142 stars 37 forks source link

Annotate viewer broken under mixed-DPI #7

Open rhuijben opened 3 years ago

rhuijben commented 3 years ago

The annotate viewer is mostly broken in Visual Studio 2019 when using non standard Windows DPI settings.

The AnkhSVN2019 fork has a new implementation using a more modern approach. (The old version had to work with the old pre-VS2012 editor). We should decide if we want to fix the current version and/or go to that newer code.

PhilJollans commented 3 years ago

My check in comment on the initial changes to AnkhSVN2019 outlines why I made a new implementation.

Work in progress on annotate command

I have given up hope that I can repair the original implementation of the Annotate function. The original version places a WinForms user control inside a document window and embeds a text editor in that user control.

So far as I can tell, it is no longer possible to place a WinForms user control directly in a document window.

The approach taken to embedding a text editor in the user control is designed to work in Visual Studio going back to version 2005. I suspect that it is much more complicated than it needs to be in Visual Studio 2019.

For these two reasons I have started restructuring the implementation using a WPF control and instantiating the editor in a completely different manner.

This is long way from being finished, but it is the bones of a working implementation.

However, I am still considering whether the annotation margin should be implemented as an editor margin. Fundamentally I think that would be a good idea, but I still have some open questions about how to implement that.

If I went that way, it would require more restructuring.

The implementation works fairly well, by I never found a set modify the caption in the tab on the editor window. Just from the tab, is looks like a normal editor window. At the time, I posted a question on StackOverflow, but never found a workable solution.

There is an open issue about handling the zoom level, but I guess this can be fixed.

I never paid any attention to older versions of Visual Studio. If this repository is the version in VS Marketplace which supports VS 2017 and VS 2019, it will probably work.

I have not tried to compile the version from this repository. If it is easy, then I could try to integrate my version of the Annotate viewer into this repository (or a fork of it). However, I will definitely not have time before October.

I found compiling from the original CollabNet repository anything but easy.

PhilJollans commented 2 years ago

Hi Bert,

I have forked your repository with the intention of moving my implementation of the Annotate viewer into this version.
I have hit a problem which I don't understand and I don't know how to fix.

My implementation uses a WPF UserControl, which I would move into the project Ankh.UI. For this I have added references to PresentationCore, PresentationFramework, System.Xaml and WindowsBase.

If I now select Add / New Item / WPF / UserControl(WPF), then it adds a new control UserControl1.xaml to the project. So far, there is no code from me.

If I now build the project, I get the following error:

1>C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(268,9): error MC1000: 
Unknown build error, 'Could not load type 'SharpSvn.Implementation.SvnLibraryAttribute' from assembly 
'SharpSvn, Version=1.14001.54.0, Culture=neutral, PublicKeyToken=d729672594885a28' 
because the method '.ctor' has no implementation (no RVA).' 

I think RVA is probably Relative Virtual Address.

If I exclude UserControl1.xaml from the project, the error goes away. I can see no connection whatsoever between the WPF control and this error message.

I don't know if this is a problem which has to be fixed in SharpSvn or AnkhSvn, but for now, I am completely stuck.

rhuijben commented 2 years ago

This appears to be an issue with the reference assembly created by the Sharpsvn build... The designer should have picked the actual binary instead of the reflection only version.

PhilJollans commented 2 years ago

Is there anything I can do to get around the problem, or is it something which has to be fixed in SharpSVN?

rhuijben commented 2 years ago

Looks like this is/was an issue in https://github.com/JetBrains/Refasmer, which is used for creating the reference assembly. I'm building a new SharpSvn and will publish it in NuGet.

rhuijben commented 2 years ago

@PhilJollans I just updated the SharpSvn reference with some fixes via a newer Refasmer used there. If this doesn't fix this we should probably switch to a mock assembly instead of a reference assembly for this case, though I would hope not every reference assembly has this problem.