Win multilinetext scroll to bottom

[albuszheng]

Implemented a workaround using the underlying Win32 SendMessage method. Currently, the scroll_to_bottom() method in the MultilineTextInput sends the explicit low-level message to scroll, rather than ScrollToCaret, based on the solution suggested here.

The scroll_to_bottom will no longer jump up and down in MultilineTextInput running on Windows; it will consistently move to the bottom of the widget.

Fixes #3872

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[albuszheng]

The test failed on (windows-latest, 3.12) due to "Unable to download artifact(s)". I don't think it is related to the changes of the code.

[freakboy3742]

Thanks for the PR - this looks great as an implementation.

I've flagged one minor problem inline; the other issue is the lack of a test. We need to have a test for this behavior to make sure it doesn't reoccur.

The testbed folder already contains a test that exercises scroll_to_bottom(); as part of this change, we need to add an extra piece to that test so that the call to scroll_to_bottom() is done twice in a row, confirming that the scroll position doesn't change between the two calls. This test should fail on the current main code; but will pass with your change applied.

The testbed suite is currently failing on Linux machines - that's unrelated to your changes. GitHub has changed something recently; we're still trying to work out what that is.

[freakboy3742]

This line is a duplicate.

Suggested change

e.Handled = True

[freakboy3742]

FYI: I've just resolved the issue with Linux testing, and re-run the tests that were failing.

[albuszheng]

I found out that the current test case in the testbed will not fail with consecutive scroll_to_bottom calls on the current main code. Is there a way to access the scroll bar position from the multilinetextinput natively?

[freakboy3742]

I found out that the current test case in the testbed will not fail with consecutive scroll_to_bottom calls on the current main code. Is there a way to access the scroll bar position from the multilinetextinput natively?

That's what the calls to probe.vertical_scroll_position are exposing - the internal numerical position of the scroll. My guess is that the test needs to assert that the value of probe.vertical_scroll_position doesn't change before and after the second call to scroll_to_bottom().

[albuszheng]

I have added an additional test case for the multilinetextinput widget to check that the vertical_scroll_position value stays the same when scroll_to_bottom() is called consecutively.

[freakboy3742]

Thanks for the test update! I've pushed a couple of minor tweaks, but otherwise, this looks great - thanks for the PR!

[freakboy3742]

The change note should be a user-facing description of the feature/bugfix, not a description of the code change:

Suggested change

	`scroll_to_bottom()` now behave correctly and consistently for MultilineTextInput in Windows, and new test case is added.
	Calling `scroll_to_bottom()` on a `MultilineTextInput` that is already at the bottom of the scroll area no longer causes a "bounce" in the scroll position.

[freakboy3742]

If there's a specific bug involved, it can be helpful to reference that bug.

[freakboy3742]

It's worth adding a "wait for scroll position" here to make sure any scroll that does occur actually completes:

Suggested change

	assert probe.vertical_scroll_position == first_vertical_scroll_pos
	await probe.wait_for_scroll_position()
	assert probe.vertical_scroll_position == first_vertical_scroll_pos