Under VS2022, in a styles file, ctrl-f opens a search window, and not the file's search box at the top right corner

[npolyak]

ctrl-f should open a search box at the top right for the file not the search dialog for the whole solution.

Seems like ctrl-f works fine in a XAML resource files, only Styles files have problems.

This problem is unique to VS2022 - everything works fine under VS2019.

[james-vanrossum-sonardyne]

Have found this too and it affects avalonia XAML files - quite irritating!

[odalet]

@grokys I think I came up with a solution for this one. Seems to work well in VS2022 and did not break VS2019, but still It's rather ugly. Basically it is a hack on top of your previous hack.

I'm not sure why, but (using dnSpy too) I saw that Visual Studio 2022 did not want to cast EditorHostPane into IVsFindTarget3 and hence was falling back to the global Search in Files dialog. Here is the relevant code from EditorPackage in Microsoft.VisualStudio.Editor.Implementation.dll:

IVsFindTarget3 vsFindTarget = QuickFindUtilities.GetCurrentFindTarget() as IVsFindTarget3;
if (vsFindTarget == null || !QuickFindUtilities.IsAdornmentSupported(vsFindTarget))
{
	QuickFindUtilities.LaunchFindInFiles(nCmdID == 230U);
	return 0;
}

So, in order to have this code go beyond and open the quick search box, I modified IVsFindTarget3 this way in the extension:

namespace Microsoft.VisualStudio.Editor.Internal
{
    [ComImport]
    [TypeIdentifier]
    [Guid("A2F0D62B-D0DD-4C59-AAB8-79CD20785451")]
    [InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
    public interface IVsFindTarget3
...

Changing the namespace and adding the TypeIdentifier attribute made it work again in VS2022... Though I'm really not satisfied with this as:

• It was already a hack to rely upon a VS internal interface, but now I even hijack the namespace
• I don't really understand why TypeIdentifier is needed now
• I certainly don't understand why moving to another namespace (that most probably collides with some other code loaded by VS) suddenly makes the casting work. I know that COM Interop interfaces are peculiar beasts that do not behave like regular types, but still!

Anyway, the bottom line is I have a fix for this and will soon provide a PR. However, It's fragile.

PS: The need for this kind of hacks arises because of all the interfaces forwarding in EditorHostPane and EditorHostPaneis needed because of the way, the Editor+Preview UI is built. So, I wondered how other extension authors were tackling similar problems and came across this one: https://github.com/madskristensen/MarkdownEditor

Its UI is similar to Avalonia's but it does not try to have the editor and the preview be child items of the same control. It, instead, takes advantage of the "Margin" concept to have the preview stick to a border of an otherwise regular Code Window.

I'm probably missing a lot of impacts, but with this way of doing things:

• I think, all the interface forwarding stuff would be gone
• But, "Avalonia Xaml" would probably need to be a full features "Language Service"
• And I suspect it would be difficult to change the preview orientation on the fly (in the Markdown extension, this setting must be changed in VS Options, and any opened editor needs to be closed/re-opened)

Maybe this way of doing things is worth exploring for Avalonia (I think it'd prevent the interface forwarding) although it would be a major refactoring and probably cause newer issues...

[npolyak]

@grokys I think I came up with a solution for this one. Seems to work well in VS2022 and did not break VS2019, but still It's rather ugly. Basically it is a hack on top of your previous hack.

...

Maybe this way of doing things is worth exploring for Avalonia (I think it'd prevent the interface forwarding) although it would be a major refactoring and probably cause newer issues...

Thanks for investigating. Did you figure out why it is only happening in XAML Styles files, but not in XAML resource or UserControl files?88

[odalet]

This is a surprise to me: in my case, the issue arises consistently whatever the kind of axaml file. I double-checked this by creating one instance of each item proposed by the Avalonia extension, that is: resource dictionary, styles, templated control, user control and window.

Note that I only use the axaml extension. I didn't test the paml or xaml extensions.

[odalet]

If you right-click then choose "Open With..." one of the files that does not have the issue, what is the current "default" editor for it? It should be "Avalonia XAML Editor" (or possibly "Automatic Editor Selector (XML)" if your extension is not axaml):

[npolyak]

So, perhaps I was wrong, it was sometimes happening also with the resource files.

[npolyak]

They are all opened by Avalonia XAML Editor

[npolyak]

Basically I reset some key bindings and now everything works differently and I cannot event reset them to the original state (reset does not do anything).
To some degree I solved the problem, but not 100%
I removed the key binding from Edit.Find and changed Edit.FindNextSelected to Ctrl-F both for global and C# editor.
Now Ctrl-F works in AXAML files, but the document search pane at the right top corner does not open initially. Then if I do Ctrl-Shift-F to open the global search dialog and then close the dialog the document search pane starts opening. I have to do Ctrl-Shift-F (and then close it) for every document in which I want to see the document search pane. I have to do it only once, so, that even if I close the document and then reopen it (within the same instance of VS), the document search pane will still be visible in it.
Now I have to do it also for non-AXAML files e.g. for C# files.

[odalet]

Oh, seems you've messed your VS key bindings... In case you wanted them back to the defaults, here are mine which I never changed: vs2022-keyboard.txt

Rename it to something.vssettings before importing them back into VS.

I hope that once I have time to submit the PR and when/if it is merged and a new version of the extension is published, you won't have to resort to this hack anymore.

[npolyak]

Thanks, I'll wait for your change to change back the keyboard settings.

[npolyak]

The issue is still there even after I re-installed the Avalonia extension. When will the new extension be ready?

Thanks

Nick

[odalet]

That's because, although my PR was merged, a new version of the extension was not released yet. If you want to try it, you can download the source code, build the extension and install it though.

[npolyak]

Hey @Takoooooo, when do you think a new extension will be published?