Fixes #3777 - HexView Focus Issue - Adds View.AdvancingFocus events

[tig]

Fixes

• Fixes HexEditor right side editing is broken #3777
• Fixes ShadowView throws System.IndexOutOfRangeException if left is less than zero. #3757
• Fixes PositionCursor gets confused because HasFocus is setting Application.GetFocused incorrectly #3786

Proposed Changes/Todos

• Code cleanup
• Add View.AdvancingFocus
• Fix HexView focus issue
• Fix HexView right side editing
• Add Utf8 / Unicode input and editing
• Fix display issues

Pull Request checklist:

• I've named my PR in the form of "Fixes #issue. Terse description."
• My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
• My code follows the Terminal.Gui library design guidelines
• I ran dotnet test before commit
• I have made corresponding changes to the API documentation (using /// style comments)
• My changes generate no new warnings
• I have checked my code and corrected any poor grammar or misspellings
• I conducted basic QA to assure all features are working

[tig]

[BDisp]

The HexView is the only focusable view in the HexView scenario and it has two focusable subviews. Isn't possible to navigate between them with only tabbing, without forcing pressing Shift-Tab to go from the text view to the hexa view?

[BDisp]

If you paste this glyph 🦱https://www.compart.com/en/unicode/U+1F9B1 it will throw this exception.

But is a surrogate pair and WindowsDriver and NetDriver doesn't support it. Only CursesDriver support it by paste the UTF-8 Encoding: 0xF0 0x9F 0xA6 0xB1. Only for memorize later.

[BDisp]

When have edited changes the text stays selected. That's ok but the cursor is invisible and it's more harder to know where is it.

[tig]

The HexView is the only focusable view in the HexView scenario and it has two focusable subviews. Isn't possible to navigate between them with only tabbing, without forcing pressing Shift-Tab to go from the text view to the hexa view?

Sorry, but I don't understand. The HexEDITOR scenario has only ONE focusable view.

[tig]

When have edited changes the text stays selected. That's ok but the cursor is invisible and it's more harder to know where is it.

I don't understand.

What's wrong with this?

[tig]

🦱

This happen with TextField and TextView too. Please raise a separate issue for this.

[BDisp]

Sorry, but I don't understand. The HexEDITOR scenario has only ONE focusable view.

Sorry @tig, I made confusing because I though it was using a TextView. I was a long time I saw the code and I didn't remember that. If we are in editing in the hex and press tab then the cursor go to the text. When we press tab again it stay in the text. I have to press Shift+Tab to go to the hex editor and I think that only press tab should be enough. That really doesn't have nothing with navigation but only HexView realted. But there is no big problem if it stay like it's right now. I think that before, pressing the Enter key it toggle between text and hex, but not sure. With the mouse is more easy, of course. Thanks.

[BDisp]

Sorry, but I don't understand. The HexEDITOR scenario has only ONE focusable view.

Sorry @tig, I made confusing because I though it was using a TextView. I was a long time I saw the code and I didn't remember that. If we are in editing in the hex and press tab then the cursor go to the text. When we press tab again it stay in the text. I have to press Shift+Tab to go to the hex editor and I think that only press tab should be enough. That really doesn't have nothing with navigation but only HexView realted. But there is no big problem if it stay like it's right now. I think that before, pressing the Enter key it toggle between text and hex, but not sure. With the mouse is more easy, of course. Thanks.

Whoooo. You already did that. Thanks.

[BDisp]

I don't understand.

What's wrong with this?

When we don't edit anything, navigating in the hex side will highlight the text side at the hex side position, so the highlighting is always visible. When we are navigating on edited values the text are already highlighted and doesn't highlight the current hex position on the text side, because the attribute is the same, no matter the values was or wasn't edited. I think that if the text was edited then the current position should have a different attribute, because if we are navigating in the text side on edited values, the hex side doesn't highlight the current text position. Thus, we don't know where the current position of the other side is, if the side that have the cursor is navigating, if the values were edited.

[tig]

Sorry, but I don't understand. The HexEDITOR scenario has only ONE focusable view.

Sorry @tig, I made confusing because I though it was using a TextView. I was a long time I saw the code and I didn't remember that. If we are in editing in the hex and press tab then the cursor go to the text. When we press tab again it stay in the text. I have to press Shift+Tab to go to the hex editor and I think that only press tab should be enough. That really doesn't have nothing with navigation but only HexView realted. But there is no big problem if it stay like it's right now. I think that before, pressing the Enter key it toggle between text and hex, but not sure. With the mouse is more easy, of course. Thanks.

Whoooo. You already did that. Thanks.

Yeah, this is why this PR aslo adds View.AdvancingFocus events.

The idea is, if someone wants to override the behavior of AdvanceFocus because they have "internal subviews that are not really subviews" like HexView, they can get notified. Here's how HexView does it

    /// <inheritdoc />
    protected override bool OnAdvancingFocus (NavigationDirection direction, TabBehavior? behavior)
    {
        if (behavior is { } && behavior != TabStop)
        {
            return false;
        }

        if ((direction == NavigationDirection.Forward && _leftSideHasFocus)
            || (direction == NavigationDirection.Backward && !_leftSideHasFocus))
        {
            _leftSideHasFocus = !_leftSideHasFocus;
            RedisplayLine (Address);
            _firstNibble = true;

            return true;
        }

        return false;
    }

[tig]

I don't understand.
What's wrong with this?

When we don't edit anything, navigating in the hex side will highlight the text side at the hex side position, so the highlighting is always visible. When we are navigating on edited values the text are already highlighted and doesn't highlight the current hex position on the text side, because the attribute is the same, no matter the values was or wasn't edited. I think that if the text was edited then the current position should have a different attribute, because if we are navigating in the text side on edited values, the hex side doesn't highlight the current text position. Thus, we don't know where the current position of the other side is, if the side that have the cursor is navigating, if the values were edited.

How's this?

[BDisp]

How's this?

Wonderful. Thanks.

[tig]

This is ready to review again.

[tig]

Oops. I pushed my fix to #3757 to a different branch. Just fixed here too.