No correct way to host multiple `TextEditor` instance in a ViewContent

[garuma]

Although it's doable to introduce an intermediary widget (e.g. Gtk.Alignment) as the ViewContent.Control and swap TextEditor instances as a child of that container, there is no way to inform the rest of the IDE that the internal content has changed and thus everything that depends on calling ViewContent.GetContent needs to be re-called again.

For instance:

• Pathbar doesn't work
• Document events are not re-registered
• Extensions are not re-applied correctly
• ...

There should be an event on ViewContent or an extra interface added to signify that a ViewContent can be the host of multiple editors.

VS bug #569963

[mhutch]

What's the use case for this?

[garuma]

The Android designer represents multiple layout files in a unified single view

[mkrueger]

Can you try to call StartReparseThread () ? Or re attach the project AttachToProject (null);AttachToProject (oldProject);

Extensions are per text editor so that should be no problem. The current design for Document is a 1:1 representation it's not changeable in the current form - but re attaching the project or reparsing should update everything.

[garuma]

@mkrueger this doesn't seem to work because the if line in http://source.monodevelop.com/#MonoDevelop.Ide/MonoDevelop.Ide.Gui/Document.cs,749 doesn't allow null to be passed in (the adhocProject field is null in that case causing the check there to pass and nothing to happen, changing the condition to (project != null && project == adhocProject) seems to do the trick but is that correct?).

StartReparseThread is internal so we can't call it directly and it seems like it wouldn't cause our text editor extensions to be registered.

[mkrueger]

give yourself an ivt - internal API can be used by us. Or try UpdateParseDocument ().

The UpdateParseDocument call should work - closing. Other than that - you can add to the infrastructure as well you've a use case we didn't have when designing that. I can surely help with the design here and there but I would need something more to discuss/comment about.

my2cents atm is just work around the issue by queueing a parse update if it's really just the path bar that makes issues.

Extensions are applied by text editor so having multiple text editor instances is the way to go. So a custom ViewContent is required - see TextEditorViewContent. It should be possible to control all that from that custom view content for this use case.

As an alternative it would be possible to add an ContentChanged event to ViewContent - but it's better if you implement it and try it out if it works.

My guess is that it is enough that Document would listen to it and let it call InitializeExtensionChain () on the ContentChanged event.

[xamarin-release-manager]

Fixed in version 7.6.0.158 (master)

Author: Jérémie Laval Commit: 4fa26d58109595d0e960207a02a20a964bf9c21c (mono/monodevelop)

[garuma]

@mkrueger sorry I hadn't seen you updated your comment.

I just tried calling document.UpdateParseDocument and it doesn't work. The path bar is not visible in the second text editor instance (to be clear when I said the path bar didn't work I meant that the widget itself wasn't getting registered not that it was displaying wrong data).

We already have our own custom BaseViewContent implementation and that's where I currently host the multiple instances of TextEditor via an intermediary Gtk.Alignment. As mentioned previously, the GetContent calls to our toplevel BaseViewContent are then re-routed to whatever is the active TextEditor instance.

Basically I don't see how this situation would work properly without that ContentChanged event.

[mkrueger]

How do you switch the text editor ?

[Therzok]

@garuma is this fixed with the new doc model?