Modernizing .NETpad Step-By-Step, Part 8: Replace and Replace All (Premium)

In the previous article, we created a modern interface for Find/Replace and implemented Find, Find next, and Find previous. This time, we'll wrap up the Find/Replace work by implementing Replace and Replace all, and migrating all the new Find/Replace code into the main app, fixing a few bugs as we go.
Implement Replace
In the OG version of .NETpad, I implemented the Replace function as a series of custom input box dialogs that prompted the user for the text to find and then the text to replace it with, in turn. It worked, barely, but the user interface was non-standard and there were all kinds of unhandled cases.

One goal of this new version is to address those issues, though the pane-based approach has its own limitations too. The Find/Replace pane stays on-screen and lets the user continue finding and replacing text, rather than just performing a one-off task and disappearing as before. This is good ... and bad. But it's what we have.

When we created the pane, we set it up so that only the Find-related controls would appear when the user engaged in a Find operation (currently by clicking a temporary menu item). So Replace should work similarly, by un-hiding the Replace-related controls so they can be accessed. That way, the Find and Replace options will work sort of like toggles.

(Should Replace and Replace all behave differently? That is, if Replace and Replace all are both visible if the user chooses Replace, does the menu part of the UI need to change? That's an ongoing debate. For now, we will simply engage both as one, with the one difference being that the Replace button is the default when the user chooses that action.)

To get started, locate the ReplaceTestMenu_Click() event handler in MainWindow.xaml.cs. This is the event handler that fires when the user clicks the temporary Replace menu item, but it will eventually be wired to the Replace command. It's currently empty.

Looking at FindTestMenu_Click(), it's clear that we can simply just run that method first, since we would otherwise just duplicate most of that code. Then, we can un-hide the Replace-related controls (as that method hides them), change the default handler (what fires when the user taps Enter), and put the focus on the correct control. (There may be a more elegant way to do all this, but we'll look at code cleanup and refactoring later.)

To test this properly, try a few things. Toggling between Find and Replace (by clicking those menu items). Selecting text and then choosing Replace. Not selecting text and then choosing Replace. And so on. For example, if you select text in the main app window's text box and then click "Replace," the Find/Replace pane should appear with all its controls, the selected text should appear in the Find text box, and the Replace text box should be selected so the user can type the replacement text.

OK, next we need to implement the Replace action associated with the Replace button. We can find the original...