Future Plans for the TextToolbar

[WilliamABradley]

Just some ideas on where this control could be improved.

• Find a fix for the Link Display update for RTF (TextToolbar Control for Editing RichEditBox #1116 (comment)).
• Add Font and Size Picker to RTF.
• Add Indicator to let people know there are more buttons (TextToolbar Control for Editing RichEditBox #1116 (comment)).
• Work on Mobile Keyboard Attachment.
• Add resizing logic (may require a re-write of the XAML layer, ditching the Command Bar (Breaking Change)), this could involve moving the Buttons into groups, ditching the Separators. This will make it harder to insert Custom Buttons, but it doesn't make it impossible. See OneNote Resizing, or other Microsoft Office Applications on how this could work. Where groups collapse into one icon, and when you click it, it creates a Flyout.

If you have any other ideas, let me know, I'll add it to the list.

[nmetulev]

Great list

[WilliamABradley]

@nmetulev @michael-hawker Perhaps allowing Support for more Editors, such as Monaco, TextBox for the Sample App?
This could be used to add things such as Comment/UnComment Button, etc.

@skendrot This rambling is somewhat what you were talking about in the original PR.

It would require a considerable re-write, perhaps making the Editor property an Object, and then determining if it is a RichEditBox, or an Inheritor of an Editor Interface, (Removing the Windows Specific APIs, allowing for possible future Cross Platform Ideals, which would also make the Toolbar more Portable in the future). This way you could wrap the Monaco API or Editor around this Editor Interface and enable functionality this way.

Although that would mean RTF is incompatible, MarkDown would require a re-write but not as much, etc.

There might be a way of making this toolbar adapt to the Type of Editor it is attached to, I'm not sure yet, but I would prefer it to not be a Breaking Change.

[michael-hawker]

Yeah, that's an interesting idea, probably a couple of ways to do it. If the Editor was just an element, you could push more of the interaction with that to the formatter or a separate helper, so you'd have different extension classes per object you want to support without having to require the object to inherit from a specific interface.

[michael-hawker]

@WilliamABradley forgot about it yesterday, but did notice I was able to get into a state in the Sample App where I switched from RichText to MarkDown and it left some of the RichText formatted as bold/italic in the RTB. I'll see if I can get a solid repro and open an issue. Probably not a common scenario.

[hawkerm]

@WilliamABradley noticed in the sample app that switching to the Custom formatter wasn't working. I had to switch off the properties tab and back to it to get it to update?

Also the auto-resizing behavior kind of fits into #353, at least if it's just a ... at the end for overflow. The group collapse would be neat, but probably a bit more advanced.

[WilliamABradley]

I was thinking more of this:

Although probably simpler.

@hawkerm The reason why Custom Formatter doesn't work with the Combobox, is that in real usage, the Custom Formatter has to be loaded into the Control, which is why there is a Use Custom Formatter button at the bottom of the sample.

[michael-hawker]

@WilliamABradley actually, instead of having a button, you should just listen to the property change for the value from the dropdown setup in the OnNavigatedTo:

            if (DataContext is Sample sample &&
                sample.PropertyDescriptor.Expando is IDictionary<string, object> dict &&
                dict.ContainsKey("Format") &&
                dict["Format"] is ValueHolder value)
            {
                value.PropertyChanged += (s, ev) =>
                {
                    if (s is ValueHolder holder &&
                        holder.Value is Format format &&
                        format == Format.Custom)
                    {
                        UseCustomFormatter();
                    }
                };
            }

@nmetulev there's a bug using the above though if the valueholder is changed, as it uses objects the != comparison here. I was pretty surprised, but it's because we're going through a object type conversion the enum value comparison isn't used unless we do if (!_value.Equals(value)) instead. See this article.

I also noticed we have some dead code in some of the samples which try and set their own datacontext when we do it for them now. All these sections can be removed. I'll file a bug to track these separately. I'll submit a fix for them later this week.

[WilliamABradley]

I could do that, but having it as a button shows how a programmer has to load the Custom Formatter manually.

[michael-hawker]

You could still leave the button and/or just show that code in the 'code' tab.

Since the drop-down is used to change between the other two modes it's a bit odd from a user perspective in trying out the sample.

[michael-hawker]

Hitting 'Enter' in the url textbox of the link add should close and insert the link.