【テクニカル・上級編】Windows FormsのForm.AutoScrollとAutoScrollPositionを使ったカスタムキャンバスのスクロール位置復元：画面再描画時のズレ防止 – Visual Basic (VB / VB.NET)解析バイブル

WinFormsの深淵：AutoScrollの暴走を制御し、描画更新時のスクロール位置を完全掌握する

Windows Formsを用いた大規模なカスタムキャンバス、あるいは大量の動的コントロールを配置する業務アプリケーションの開発において、多くのエンジニアが直面する「不可解な挙動」がある。

データ更新、あるいはコントロールの再配置を行った瞬間に、ユーザーが苦労して辿り着いたスクロール位置が、無慈悲にも $(0, 0)$、つまり左上端へと強制的に引き戻される現象だ。

これは単なる「不具合」ではない。WinFormsのレイアウトエンジン、`AutoScroll`ロジック、そしてWindows OSの描画メッセージループが複雑に絡み合った、アーキテクチャ上の必然的な衝突である。本稿では、この現象の真因を解明し、Windows APIを用いた低レイヤーからの制御によって、プロフェッショナルが求める「滑らかで堅牢なUI更新」を実現する極限の知見を伝授する。

1. なぜスクロール位置は「失われる」のか

まず、現象のメカニズムを理解せよ。`AutoScroll`が有効なコンテナにおいて、内部のコントロールの数やサイズが変更されると、コンテナは `Layout` イベントを発生させ、自身の `DisplayRectangle` とスクロールバーの必要性を再計算する。

この再計算プロセスにおいて、WinFormsの内部実装は「新しいレイアウトに基づいた初期状態」へとビューをリセットしようとする。特に、コントロールを `Add` したり、`Size` を変更したりする操作は、コンテナに対して「領域が根本的に変わった」という信号を送る。このとき、`AutoScrollPosition` を保持しようとする意志は、レイアウトエンジンの再構築プロセスによって上書きされてしまうのだ。

`SuspendLayout()` と `ResumeLayout()` を併用するだけの初歩的な対策では、この「再計算によるリセット」を完全に防ぐことはできない。なぜなら、`ResumeLayout(True)` を呼び出した瞬間に、溜まっていたレイアウト要求が一気に処理され、そのプロセスの中でスクロール位置が消失するからだ。

2. 究極の回避策：WM_SETREDRAW による描画凍結

シニアエンジニアが取るべき手段は、高レベルなプロパティ操作ではなく、Windows APIを用いた「描画エンジンの完全な凍結」である。

具体的には、`user32.dll` の `SendMessage` を用い、`WM_SETREDRAW` メッセージを対象のコントロールに送る。これにより、OSレベルでそのウィンドウに対する描画更新要求を無視させ、レイアウトの再計算に伴う視覚的な「跳ね返り」を封じ込めることが可能になる。

実装の核となる戦略

1. Win32 APIによる描画停止: `WM_SETREDRAW` を使い、コントロールの描画更新をハードウェアレベルで止める。
2. 状態のキャプチャ: 更新直前の `AutoScrollPosition` を正確に保持する。
3. 破壊と創造: コントロールの削除・追加、あるいはデータの再描画を完遂する。
4. 状態の復元: キャプチャした位置を再適用する。
5. 描画再開と強制更新: `WM_SETREDRAW` を戻し、`Invalidate` で描画を再開させる。

3. 実践的コード：スクロール位置保持型カスタムキャンバス

以下に、実戦投入可能なレベルのコードを示す。単なるサンプルではなく、メモリリークを防ぐための `Dispose` への配慮と、API呼び出しの正確性を重視している。

Imports System.Runtime.InteropServices

''' <summary>
''' 高度なスクロール制御機能を備えたカスタムキャンバス・ベースクラス
''' </summary>
Public Class AdvancedCanvas
    Inherits Panel

    ' --- Windows API Constants ---
    Private Const WM_SETREDRAW As Integer = &H8

    ' --- Windows API Declarations ---
    <DllImport("user32.dll", ExactSpelling:=True)>
    Private Shared Function SendMessage(hWnd As IntPtr, msg As Integer, wParam As IntPtr, lParam As IntPtr) As IntPtr
    End Function

    Public Sub New()
        Me.AutoScroll = True
        ' 高速描画のための設定
        Me.DoubleBuffered = True
    End Sub

    ''' <summary>
    ''' コンテンツを安全に更新するためのコアメソッド
    ''' </summary>
    ''' <param name="updateAction">コントロールの追加や削除を行うデリゲート</param>
    Public Sub SafeUpdateContent(updateAction As Action)
        ' 1. 現在のスクロール位置をキャプチャ
        ' ※AutoScrollPositionは、設定時は正の値、取得時は負の値で返ってくる特性がある点に注意
        Dim currentPos As Point = Me.AutoScrollPosition
        Dim scrollX As Integer = Math.Abs(currentPos.X)
        Dim scrollY As Integer = Math.Abs(currentPos.Y)

        Try
            ' 2. レイアウト計算の停止
            Me.SuspendLayout()

            ' 3. Windows APIを用いて描画更新を完全にロック
            ' これにより、内部的なLayoutイベントによる描画のチラつきと位置リセットを防ぐ
            SendMessage(Me.Handle, WM_SETREDRAW, IntPtr.Zero, IntPtr.Zero)

            ' 4. ユーザー定義の更新処理を実行
            ' ここでコントロールの追加、削除、データの再配置を行う
            updateAction.Invoke()

            ' 5. 描画ロックを解除
            SendMessage(Me.Handle, WM_SETREDRAW, New IntPtr(1), IntPtr.Zero)

        Catch ex As Exception
            ' エラー発生時も描画ロックを解除しないと、コントロールが真っ白なまま固まる
            SendMessage(Me.Handle, WM_SETREDRAW, New IntPtr(1), IntPtr.Zero)
            Throw
        Finally
            ' 6. レイアウトを再計算し、スクロール位置を復元
            Me.ResumeLayout(True)
            
            ' 重要: レイアウト再計算後に位置を再設定する
            ' AutoScrollPositionへの代入は、内部的にスクロールバーの値を直接操作する
            Me.AutoScrollPosition = New Point(-scrollX, -scrollY)
            
            ' 7. 最終的な描画を強制
            Me.Invalidate()
        End Try
    End Sub

    ''' <summary>
    ''' メモリ最適化のため、不要になったコントロールを確実に解放する
    ''' </summary>
    Public Sub ClearCanvas()
        SafeUpdateContent(Sub()
            ' コントロールを破棄しながら削除（メモリリーク防止の鉄則）
            While Me.Controls.Count > 0
                Dim ctrl = Me.Controls(0)
                Me.Controls.Remove(ctrl)
                ctrl.Dispose() 
            End While
        End Sub)
    End Sub
End Class

4. アーキテクトの視点：パフォーマンスとメモリの極限

この実装を運用するにあたり、シニアエンジニアが留意すべき「重み」が二つある。

メモリ管理の厳格性

`SafeUpdateContent` 内で大量のコントロールを入れ替える場合、単に `Controls.Clear()` を呼び出すだけでは不十分だ。WinFormsのコントロールは `Unmanaged Resource`（ウィンドウハンドル等）を保持している。`Controls.Clear()` はコレクションから参照を外すだけで、OSのリソースを即座に解放するとは限らない。
必ず、上述のコード例のように `Dispose()` を明示的に呼び出し、ハンドルを確実に破棄すること。これを怠れば、長時間稼働する業務システムにおいて、徐々にメモリ消費量が増大する「メモリリーク」の温床となる。

描画負荷の分散

もし、扱うオブジェクトが数千、数万に及ぶ場合、コントロール（`UserControl` 等）を個別に配置する設計自体を見直すべきだ。コントロールの数が増えるほど、`Layout` イベントの計算コストは指数関数的に増大する。
その場合は、コントロールを配置するのではなく、`OnPaint` をオーバーライドし、`Graphics` オブジェクトに対して直接 `DrawLine` や `DrawImage` を行う 「軽量描画エンジン」 への移行を検討せよ。その際も、本稿で示した `WM_SETREDRAW` による制御技術は、描画のチラつきを抑えるための武器としてそのまま転用できる。

結論

Windows Formsは、レガシーな技術でありながら、その挙動を深く理解し、Win32 APIという「真の力」を適切に組み合わせることで、現代の高度な要求にも応えうる堅牢な基盤となる。

`AutoScrollPosition` の消失に悩まされる段階を脱し、OSの描画サイクルを支配下に置くこと。それこそが、システムを「動かす」エンジニアと、「掌握する」アーキテクトを分かつ境界線である。