ComponentFactory / Krypton

Krypton WinForms components for .NET
BSD 3-Clause "New" or "Revised" License
1.87k stars 686 forks source link

Mouse cursor in KryptonRichTextBox can not be changed (fix inside) #62

Open MGRussell opened 7 years ago

MGRussell commented 7 years ago

In other words doing kryptonRichTextBox1.Cursor = Cursors.Hand; does nothing. This is not behavior inherited from RichTextBox, which does support differing cursors. The problem is that the cursor of the InternalRichTextBox used by KryptonRichTextBox is not kept synchronized with the cursor of the exposed KryptonRichTextBox.

A solution is just to add

    protected override void OnCursorChanged(EventArgs e)
    {
        base.OnCursorChanged(e);
        _richTextBox.Cursor = Cursor;
    }

To the protected overrides in KryptonRichTextBox.cs. They start at line 2006.

MGRussell commented 7 years ago

There are actually a number of related issues here. KryptonRichTextBox exposes a limited interface that is linked to an internal RichTextBox. However, since not all functionality is linked - it seems numerous events and behavior are effectively hidden.

Another example of this is MouseMove. OnMouseMove events do not properly fire in the KryptonRichTextBox. The solution there is pretty similar to before, but linking the internal RichTextBox to the KryptonRichTextBox instead of the opposite direction as above. So for instance solving the MouseMove event involves just adding:

        protected override void OnMouseMove(MouseEventArgs e)
        {
            base.OnMouseMove(e);
            _kryptonRichTextBox.OnMouseMove(e);
        }

To the InternalRichTextBox implementation. It begins at line 163 in KryptonRichTextBox.cs. Similar overrides would probably also need to be added to support other mouse functions as well as keyboard functions.

Threetwosevensixseven commented 7 years ago

Can't you just do kryptonRichTextBox1.RichTextBox.Cursor = Cursors.Hand? The wrapped controls are all exposed this way as public properties.

MGRussell commented 7 years ago

Definitely looks like that should work, along with the ContainedControl property.

I'm curious about the intended use of the interface. It's a bit counter intuitive to me that the vast majority of the exposed interface is just a straight forward pass through to the underlying control, yet some very common use things (like these) are not passed through.