【PowerPoint VBAの深淵】ノート編集の「保存フラグ不全」を封殺する極限のハック
PowerPoint VBAを触りこなす諸君、ご苦労。
自動化の旅路において、我々は常にOfficeの「気まぐれ」と戦っている。特に `Presentation.Saved` プロパティの挙動は、まさにその最たるものだ。スライドのテキストを書き換えただけでは、PowerPointのUndoスタックすら更新されないケースが多々ある。
特に「ノートページ（NotesPage）」の編集だ。`Slide.NotesPage.Shapes` を叩いてテキストを流し込んでも、アプリケーションは平然と「変更なし」と判定し、閉じる際の保存確認すら出さない。この「未保存のままアプリが終了する」という仕様は、自動化システムにとっては致命的な欠陥だ。
今回は、この「保存フラグの欺瞞」を打破し、確実に変更をコミットさせるためのアーキテクチャ・ハックを伝授する。
—
なぜ `Saved = False` が機能しないのか
PowerPointの内部エンジンは、スライド本体のDOM変更とノートページの変更を厳密に分離している。一部の操作は、UI上の変更として「ダーティ（Dirty）」フラグを立てるが、ノートのテキスト変更は、極めて低いレイヤーでの処理となり、アプリケーションの `Saved` 状態に伝播しないことがある。
これは「バグ」というより、PowerPointの描画エンジンが、ノートページの更新を「非同期的なコンテンツ更新」として扱っていることに起因する。
—
解決策：ダミー編集による強制ステート遷移
最も堅牢で、かつパフォーマンスを損なわない手法は、「無害な変更を加えて、強制的にダーティフラグを立てる」ことだ。
単に `ActivePresentation.Saved = False` と記述しても良いが、これは「保存が必要」という宣言に過ぎない。Officeの内部整合性を担保し、Undoスタックに確実に乗せるためには、オブジェクトモデルを通じた物理的な「微細な変更」が必要だ。
実装コード：`ForceSaveDirty` メソッド
‘ @brief ノート編集後の保存フラグ不全を解消する強制ダーティ化ルーチン
‘ @param targetSlide 操作対象のSlideオブジェクト
Public Sub ForceSaveDirty(targetSlide As Slide)
Dim dummyShape As Shape
‘ 1. スライド上に一時的なダミーシェイプを作成
‘ 既に存在するシェイプのプロパティを微小変更するのも手だが、
‘ オブジェクトの複雑性を避けるため、透明なシェイプを生成する
Set dummyShape = targetSlide.Shapes.AddShape(msoShapeRectangle, 0, 0, 0, 0)
‘ 2. 確実に変更を認識させるため、プロパティを動かす
dummyShape.Visible = msoFalse
‘ 3. 削除してUndoスタックに「削除イベント」を刻む
‘ これにより、プレゼンテーション全体が「変更された」と認識される
dummyShape.Delete
‘ 4. 念のためSavedプロパティを明示的にFalseへ
‘ ただし、上記操作によって自動的にFalseになることが期待値
If targetSlide.Parent.Saved Then
targetSlide.Parent.Saved = msoFalse
End If
‘ メモリの解放：VBAのGCを待つのではなく明示的にNothing
Set dummyShape = Nothing
End Sub
—
アーキテクトの視点：なぜこの手法なのか
このコードのポイントは、単なるプロパティの書き換えではなく、「DOMの構造を一時的に変化させた」点にある。
1. Undoスタックの汚染回避:
`dummyShape` の生成と削除は、対になる操作であるため、Undoスタック上では相殺される。ユーザーが「Ctrl+Z」を押した際、ノートの変更は維持されたまま、ダミーの生成・削除の履歴だけが消える（あるいはダミー操作が相殺される）ため、UXを損なわない。
2. イベント駆動との親和性:
`Application.PresentationSave` イベントなどをトリガーにしている場合、この操作によって確実にイベントが発行される。
3. パフォーマンスのオーバーヘッド:
`AddShape` して即 `Delete` するコストは、ミリ秒単位以下だ。数千枚のスライドを処理するバッチ処理であっても、処理速度への影響は誤差範囲である。
—
運用上の極意：メモリとライフサイクルの管理
大規模な自動化システムを構築する場合、「オブジェクトの参照を保持し続けないこと」が鉄則だ。
- 明示的解放: `Set obj = Nothing` は、VBAにおける礼儀であり、メモリリークを防ぐ唯一の防波堤である。
- Late Binding vs Early Binding: 開発時は `Early Binding`（参照設定あり）でインテリセンスをフル活用し、配布・実行環境では `Late Binding`（`CreateObject`）へ移行することを検討せよ。バージョン差異によるDLLのロードエラーを回避できる。
結びに代えて
PowerPointは、ExcelやWordに比べてオブジェクトモデルが成熟しきっていない側面がある。しかし、その「不完全さ」を理解し、今回のような「アーキテクチャの隙間」を埋める術を習得した諸君なら、どのような自動化プロジェクトも制御下に置けるはずだ。
技術は常に、仕様の隙間にある。
次回のコードレビューで、この「ダミー編集ハック」が標準として組み込まれていることを期待する。
健闘を祈る。
