2012年8月30日木曜日

VBAでWordのウィンドウを水平方向に並べようとしたらWin32APIを連呼していた

【概要】

にて、Wordのウィンドウを水平方向に並べる(敷き詰める)マクロとともに、『Word2010に関してはApplication.Documents プロパティの挙動がおかしいため、正しく動かないことがある』という話が載っていました。

 手元のWord2010で確認したところ、たしかに正しく動かなかったので、Word2010におけるApplication.Documents プロパティの挙動について確認したところ、『Application.Documents プロパティは使えない』という結論に至ったので代替案を考えました。
 また、Word2000 ~ Word2013Preview のいずれのVersionにおいても、Wordのウィンドウを(プライマリモニタにおいて)水平方向に並べることができるようにマクロに手を加えてみました。

【Word2007以前の Application.Documents プロパティ】

まずはじめに、Word2007以前のApplication.Documents プロパティの挙動を確認しました。手元の環境で調べた限りでは、だいたい以下の通り。
  1. Application.Documents(Index) で、現在開いているDocumentオブジェクトにアクセスができる
  2. Indexには、"番号"もしくは"ファイル名"を用いることができる
  3. Index の番号は、現在開いているDocumentに対して
    新しく開いた順に1から連番で振られる
  4. どれか1つDocumentを閉じると、即座に
    残っているDocumentに対して新しく開いた順に1から連番で振り直される
このうち、1. 2.に関しては、MSDNに記載されている仕様の通りです。
 一方、3. 4.に関しては、特にMSDNに記載されているわけではないので、「たまたまこうなった」という程度の話かもしれません。(とりあえずは、常識的な挙動かなぁという印象を受けます。)

【Word2010の Application.Documents プロパティ】

MSDNを確認すると、Word2010の仕様として、保護ビューで表示されているDocumentに関しては、Appication.Documentsには含まれず、ProtectedViewsプロパティに含まれることが記載されています。もっとも、この仕様は今回の件には関係ありませんが…。

 Word 2010 Documents collection corrupted if work with several documents にて議論されているように、Word2010においては Application.Documents の挙動がかなり歪です。また、場合によっては、現在開いてるDocumentの情報を正しく保持しておらず、MSDNの記載とさえ一致していません。バグと言っても構わないレベルのような気がします。
 フォーラムでの議論内容を実際に手元で確認した限りでは、
  1. Application.Documents(Index) で、現在開いているDocumentオブジェクトにアクセスができる
  2. Indexには、"番号"もしくは"ファイル名"を用いることができる
  3. Index の番号は、現在開いているDocumentに対して
    新しく開いた順に1から連番で振られる
  4. どれか1つDocumentを閉じても、即座には
    残っているDocumentに対して新しく開いた順に1から連番で振り直されない
    1. Index 番号が飛び飛びになる(ことがある)
    2. Index 番号が存在しないDocumentが生じる (ことがある)
    3. Index 番号を複数持つ Documentが生じる (ことがある)
  5. それなりに時間が経つと、 現在開いているDocumentに対して
    新しく開いた順に1から連番で振り直されている
1. ~ 3.に関しては、Word2007以前と同様です。
 4. の Documentを閉じたときの挙動がかなり奇妙です。正直、奇妙というより、バギー過ぎて使い物にならないと考えた方がいいレベルだなと思いました。
 5. に関しても、数十秒から数分程度かかる場合まであり、どの程度の時間が経過すると、Index番号が振り直されるのかよくわかりません。

【Application.Documents の注意点】

そもそもの問題として、Application.Documentsでは、(当該コードを走らせている)単一のプロセスにおいて開かれているDocumentしか取得できません。このため、画面上に表示されているDocumentが、2つ以上のプロセスにわたっている場合には、画面上に表示されているDocument全てを操作するのに、Application.Documents は使えません。

 デフォルトの関連付けでは、Wordファイルを開く際には、1つのプロセス上で新しいウィンドウを作成するようになっているので、この点は一見問題にならなさそうに思えるのですが、実際にファイルを閉じたり開いたりしていると、たまに別プロセスで起動することがあり、この問題の発生確率は低くないと思われます。(もしかすると自分の環境だけかもしれませんが…。原因は未確認です。)
 また、コマンドラインオプションを使えば(*)別プロセスでの起動が可能なので、複数のプロセスが立ち上がっている可能性は考慮しておいた方がいいように思えます。

(*) Word のコマンド ライン スイッチ /n または /wで別プロセスを起動可能。

【Application.Documents に代わる代替策】

 以上の仕様を確認してみて、Application.Documentsは今回のマクロのように、Wordのウィンドウを操作するのには適さないという結論に至りました。そこで、いずれのVer.でも確実に使える代替方法を考えた結果、
  1. Win32APIのEnumWindowsを用いてWordのウィンドウハンドルを拾い
  2. MoveWindowでリサイズする
方法が良いかなと思いました。この方法がベストなのかはよく分かりませんが、自分の中では最終的にこの方法に落ち着きました。(実際のところ、Win32APIを使わないで済むように色々試してはみたのですが、いい方法が見つかりませんでした…。スマートな解決法をゆるく募集しております。)

 実際に、書いたコードは以下の通りです。
 1つ目のファイルは、Wordのウィンドウハンドルを取得するプロシージャ(GetAllWindowHandlesOfWord) を作成するためだけのもので、2つ目のファイルで、このプロシージャを用いて実際にウィンドウを水平方向に並べています。


Win32APIを使うにあたって、
EnumWindows関数 に関しては、列挙(EnumWindows by VBA) を、
MoveWindows関数 に関しては、「Win32API(C言語)編 第60章 ウィンドウの操作①」 を、
SystemParametersInfo関数 に関しては「エクセルVBAで画面の大きさを取得する方法!」 を、
参考にしました。各記事の作者の方々にはこの場を借りてお礼を申し上げます。

 なお、上記コードでは、プライマリモニタにウィンドウを並べる仕様になっています。マルチディスプレイ環境において、他のディスプレイに並べたい場合は、SystemPatametersInfoに代えて、GetSystemMetrics, GetMonitorInfo あたりを使うと良いかもしれません。(未検証です。) 

 また、上記コードは、64bit環境ではそのままでは動作しません。Win32APIを参照するためのDeclare の後ろに PtrSafeを記載してください。

【ウィンドウを並べる際の注意点】

 オリジナルのマクロは簡易的な仕様なので、色々考慮されていないのは当然なのですが、参考までに、汎用的に使えるプログラムを作る場合に考慮したほうが良いのではないかなと思う点を下記に列挙してみました。
  • 作業領域の左上の座標が(0,0)でない場合
    • タスクバーの位置が左または上の場合
  • マルチディスプレイ環境において、XY座標がマイナスの場合
    • プライマリモニタの左または上にモニタがある場合
  • マルチディスプレイ環境において、ディスプレイのサイズがそれぞれ異なる場合
    • Wordのウィンドウが異なるサイズのディスプレイ上に配置されている場合
 また、これは手元の環境特有かもしれないのですが、Word2002においては、ウィンドウを画面を最大化した場合に、Application.Width 及び.Heightプロパティでは最大化したウィンドウサイズを拾えない(通常時のウィンドウサイズを拾う)という挙動を示しました。もしかすると、ウィンドウを最大化して作業領域の大きさを取得するというテクニックはOfficeのVer.によっては使えないのかもしれません。




2012年8月25日土曜日

Word でキーボードショートカットキーを一括して登録する

【まえがき】

Word には、キーボードショートカットキーの割り当てを、デフォルト設定(Ctrl+Sが「上書き保存」など)も含め自由にカスタマイズできるようになっているのですが、
その設定方法が、Office2010を例にとると、

[ファイル] → [オプション] → [リボンのユーザー設定] → ショートカットキー:[ユーザー設定]を選択

と設定画面を開くだけでもめんどくさいです。
おまけに、設定画面も小さく、1つ1つ手作業でショートカットキーを登録するのは、苦痛以外の何物でもありません。私的に。
ショートカットキーの設定画面
もっとも、ショートカットキーを1個、2個登録するだけであれば、気にならないかもしれないのですが、普段使っているPCとは、別のPCでショートカットキーの設定を再現しようとして

  1. 普段使っているPCの設定を確認して
  2. 小さな画面で 1個1個設定する

という作業をしていたら、発狂しかけました。
将来OSを入れ替えた時など『忘れた頃にまたしなければならないのか』と思うと、絶望のあまり倒れてしまいそうなので、VBAでショートカットキーを一括して登録するコードを書いてみました。

【書いたコード】


配列 (macroSetting, commandSetting)に、
  • 実行するマクロ/コマンド名
  • 割り当てるショートカットキー
の順で、ショートカットキーの設定 (詳しくは後述)をまとめて格納した後、KeyBindings.Add()メソッド を用いてショートカットキーを登録しています。

ショートカットキーにマクロを割り当てる場合と、「上書き保存」など標準で組み込まれているコマンド (fixed command) を割り当てる場合とではAdd() メソッドの引数が変わるので、それぞれ設定を格納する配列を分けています。

点線より上側に、ショートカットキーの設定を書き並べれば使えるので、
ショートカットキーの設定を確認するのも楽かなと思ってこんな風に書いてみました。

なお、配列の末尾の要素の "***END***"は、単に、各行の書式を揃えてコピペし易くする (全行が","で終わるようにする)ためだけに挿入しています。

【ショートカットキーの設定について】

ショートカットキーの設定に用いるキーの定数一覧は、MSDNの
に記載されています。ただ、自分が確認した範囲では、日本語キーボードの場合
  • wdKeySemiColon は、": "(コロン)のキーに
  • wdKeyEquals は、 ";"(セミコロン)のキーに
相当しています。たとえば、Ctrl + ":" にマクロを割り当てたい場合、『wdKeyControl + wdKeySemiColon』を使う必要があります。(英語キーボードを想定して、定数が決め打ちされているのでしょうか…。)

また、複合キーの設定は、BuildKeyCode() メソッドを用いて BuildKeyCode(wdKeyControl, wdKeySemiColon) のように書けるのですが、冗長なだけなので上記コードでは直接加算しています。

標準で組み込まれているコマンド (fixed command)名については、MSDNの
に記載されています。

【どうでもいい話】

過去に、無意識に Ctrl +S を押して、書き損じた文書を上書き保存してしまうという失敗をしたことがあったので、
Ctrl + Sには、「名前をつけて保存」を割り当てて、意図的に、ファイルの保存ダイアログが出るように(一旦、本当に保存していいか確認できるように)しています。

まぁ、自動でバックアップとるなり、差分管理しておけよって感じではあるのですが…。

WordからExcelを操作するサンプルコード(Excelで作った辞書データを用いてWordで一括置換)

【まえがき】

Excelファイルに記載されたデータをもとにWord上で文章を作成するツールを作りたいという動機で、手始めに参考になりそうなプログラムを探していたところ、水野麻子さんの
というblog記事にて紹介されていた、渡辺真さんによる
というマクロが、『WordからExcelを操作する』実例としてコードの分量的にちょうど良かったので、参考に読んでみました。
マクロの概要を簡単に紹介すると、英日翻訳の補助ツールのようなもので、『下図に示すようなExcelに記載した日本語と英語の対訳表(以下では、「辞書ファイル」と呼んでいます)に基づいて、Wordファイル中の日本語を、対応する英語に置換する』といった内容になっています。

辞書ファイルの参考例 (渡辺真さんのマクロに付属のもの)
読んでみて、いくつか気になった点があったので、WordからExcelを操作するコードの動作テストも兼ねて、渡辺真さんが公開されているコードに自分なりに手を加えてみました。
「手を加えた」といいながら、練習もかねて、動作の流れのみオリジナルに合わせ、フルスクラッチで書き直しています。

 【オリジナルの仕様 (個人的に気になった点のみ)】

  • マクロ付きのWordファイルとして配布されている
    • Wordファイルの本文に配置した 「ボタン」からマクロを起動
    • 置換対象のWordファイルをダイアログで選択する必要あり
    • 置換に用いるExcelファイル(辞書ファイル)の配置場所が固定
    • 辞書ファイルのファイル名を、Wordファイル中の所定欄に記入することで指定
  • 利用にあたり「参照設定」が必要
    • ※ 使用中のOfficeが2010以外の場合
  • 辞書ファイルの仕様
    • あらかじめ 、置換に用いる語句を語数順(降順)に並べ替えておく必要あり
  • マクロ実行中にWordの画面が固まる

 【変更点】

  • アドインに変更
    • 現在開いている文章を置換対象に
      • マクロ実行にあたりWordファイルを開く手間を削減
      • 置換対象のWordファイルの選択を不要に
    • 辞書ファイルをダイアログで選択するように
  • 「参照設定」なしで動作するように
  • 辞書ファイルの仕様変更
    • 手作業での単語の並べ替えを不要に
  • マクロ実行中も、適宜、画面の更新を行うように
なお、翻訳を生業としているわけではないので、これらの変更が、実際の翻訳作業における使い勝手を改善するものなのか正直よくわかりません(『一般的には、こうした方がいいんじゃないかなぁ』という程度の曖昧とした感覚で変更を加えています)。

また、一部、オリジナルのマクロに比べ、改悪している(設定の自由度が落ちている)部分があります。具体的には、オリジナルのマクロでは、辞書ファイルの記入方法(置換対象の語句、置換後の語句を何列目に記載するか、どのシートを使うかなど)は、Wordファイル中の所定欄に記入することで変更できたのに対し、今回作成したコードでは、辞書ファイルの記入方法が固定(コード中で指定)されています。

【今回作成したコード】

以下に、メインのモジュール(ModuleReplaceWithExcel.bas) を表示しています。


実際に作成したコードには、他に、
  • 処理時間計測用のクラスモジュール (Stopwatch.cls) 
  • 辞書データ用の構造体を定義したモジュール (TypeReplaceData.bas) 
  • アドインとして機能させるためにドキュメントに直接記載したコード (ThisDocument.dcm)
が含まれています。これらを含む全コードを、GitHubで公開しています。
実際にテンプレートファイルとして使ってみたい場合は、下記の手順でご利用ください。
  1. GitHubを開いて [↓ ZIP]ボタンを押して、全コードをダウンロード
  2. 解凍後、build.bat を実行(ダブルクリック)
  3. binフォルダ内に、テンプレートファイルが作成されるので、適宜インストール
    ※ アドインのインストール方法については、添付のマニュアル(manual.doc)にも記載しています。
なお、ソースコードのライセンスについてですが

  クリエイティブ・コモンズ・ライセンス

余談ながら、オリジナルのものに従ってライセンスにCC(Creative Commons)を適用したのですが、プログラムのソースコードに対してCCを適用することにどの程度の意味があるのか自分自身よくわかっていません。識者の方からのコメントをお待ちしております。CCJapan自身、ソフトウェアへの適用は非推奨としているので、なにか不都合があるような気もするのですが…。閑話休題。

最後に、参考までに、渡辺真さんによるオリジナルのコードと、今回作成したコード(ModuleReplaceWithExcel.bas) との対応関係を下図に示しています。
変数名をはじめ、全面的に書き変えてはいますが、色を塗った範囲で実現している『機能』に関しては基本的に同等です。
同じ機能でも異なる書き方ができるという程度のサンプルになれば幸いです。

左:オリジナルのコード、右:今回作成したコード

2012年8月23日木曜日

Word,Excelのコンテキストメニューを初期化する

【まえがき】

  • VBAでWordのコンテキストメニューを操作していたら、うっかりコンテキストメニューにゴミ(不要なメニュー)を大量生成してしまった。
  • WordやExcelのアドインを色々試していたら、アドインをアンインストールしたのに、種々のコンテキストメニューに必要のないメニュー(ゴミ)が残った
ゲンナリする状況を示す図 (一例)

などなど、WordまたはExcelのコンテキストメニュー周りでゲンナリするような気分を味わったときには、『コンテキストメニューなんてなかった』と開き直り、『この件は水に流そう(綺麗さっぱり初期化しよう)』と思うのが人の常だと思うのです。というわけで、Word, ExcelのコンテキストメニューをVBAで初期化するコードを書いてみました。

【先に結論を書いておく】
検索してみると、Microsoftのサポートサイトに
という、まさに今回の問題解決にぴったりのページがありました(機械語訳のページなので、日本語がおかしい気がしますが…)。解決策を簡単にまとめると、
  • VBAコードを書かない方法
    • 「ユーザー設定」 を開いて、『リセット』ボタンを選択
      • ※ この方法は、Office2003以前のみ可能なように思います。自分の曖昧な記憶に基づけば、2007以降では下記のVBAのコードを書く方法を使う必要があるのではないかと思います。(手元ではOffice2003, 2013Previewでのみ確認)
  • VBAコードを書く方法
    • Excelの場合: 
      • Application.CommandBars("Worksheet Menu Bar").Reset
    • Wordなどの Excel以外のOfficeソフトの場合:
      • Application.CommandBars("Menu Bar").Reset
ボタン1つ、もしくは、コードを書く場合でも一行で完結、とめっちゃ簡単でした(*)。

にも関わらず、以下ではVBAでわざわざコードを書いています(コードを書き終わってから検索したためです)。『また、つまらぬコードを書いてしまった』感がハンパないです。あらかじめご了承ください。

(*) この方法、必要であればVBEのイミディエイトウィンドウで実行できるので、ほんとお手軽です。

【対処法】
コンテキストメニューの実態であるCommandBarオブジェクトには、(アドインなどによりボタンを追加・削除するなどの変更が加わった状態から)初期状態に戻すためのReset()メソッド が用意されています。
というわけで、片っ端からCommandBarのReset()を実行するコードを書いてみました。なお、今回コードを書くにあたり、MSDNのコマンドバーに関する解説ページ(*1)を参考にしました。MSDNに開示されているコードは全体的にすっきりしていたので、お手本にするにはちょうど良いなと感じました。

上記コードの補足説明を加えると、CommandBar.Resetメソッドは、 MSDN(*2)に記載されているように、Officeにデフォルトで組み込まれている(BuiltInプロパティが True の) CommandBarでしか利用できないため、ループ内でBuiltInプロパティをチェックしています。

(*1) VBA コードでコマンド バーとコマンド バー コントロールを操作する
   Programming Microsoft Office Command Bars

(*2) CommandBar.Reset メソッド

【蛇足】
上記コードに限れば、全てのCommandBarについてResetメソッドを呼び出しているだけなので、On Error Resume Next でエラーを握りつぶすのもありかなと思ったりします。エラーを握りつぶすのは個人的には好きくないのですが…、こちらの方が「水に流す」感がアリアリと感じられて、蒸し暑い夏の夜にはちょうど良いかなと思ったりします。

-

Task.Existsが役に立たないときのための代替方法

【まえがき】
VBAで実行中のタスクの情報(存在)を知る方法を検索してみると

に記載されているように、Wordにのみ用意されている TaskオブジェクトのExists()メソッドを用いる方法が紹介されているのを見かけます。
しかしながら、実際に使ってみると『実行中のプロセス全てが列挙されるわけではない(*)』という問題や、当たり前ですが『Excelでは使えない』という問題がありました。

というわけで、Task.Exists()の代替策として Excel含めVBAで汎用的に使えような関数を作ってみました。

(*) 何分、だいぶ前に気付いたことなので、どういう状況下でプロセスの取得がうまくいかないのだったか忘れてしまいました。いまいち役に立たない話ですみません。

【やったこと】
プログラムの二重起動を防止したいといった用途で使いたいという背景があったので
  1. WMI (Windows Management Infomation)を使ってプロセス一覧を取得し、
  2. 引数で指定した実行ファイル名に一致するプロセスが存在するか否かをチェックする
ようにしました。
この動作は、Task.Exists() の『引数で指定した文字列にウィンドウのタイトルが一致するか否かをチェックする動作』とは異なっています。もし、下記コードを利用される場合は、この点ご注意ください。


余談ですが、WMIの使い方に関しては、VBAに限らず、VB6.0やVBSのサンプルコードが参考になります。(大抵は、ほぼそのまま流用可能です。)

2012年8月19日日曜日

Office用アプリとしてテトリスを実装してみた

【最初に】
完全に出落ちです。
「読んで損した!」という気分になること請け合いなので、その辺よろしくお願いします。

【やったこと】
Office用アプリって、つまるところ

 HTML5のsandbox属性がついたIFRAME + Office操作用API (office.js)

なので、単純に『HTML製のアプリを動かすための箱として(IFRAMEの機能だけ)利用したって問題ないよね。』ってことで、HTML5だけで完結してるようなアプリを探してきて移植してみました。「Office操作用のAPIを一切使わない」という清々しいまでにOfficeと全く関係のないOffice用アプリの完成です。

これで仕事中に堂々とテトリスができますね!(できません)



【実装したコード】
コードリーディングに最適!たった200行で作れるHTML5製テトリスのプログラミング学習ムービー
で紹介されているテトリスのコードを使いました。99% そのままです。何のひねりもありません。

実際に動かしてみたい場合は、GitHubからオリジナルのコードをダウンロードして、下記のファイル(HelloTetris.html, HelloTetris.xml)と同階層に、
  • 「style.css」
  • 「js」というフォルダ
をコピーしてください。
また、HelloTetris.xmlの ***Catalog*** の部分は、(Office用アプリ用の)カタログに使うフォルダを指定してください。


【移植する上でつまづいたところ】
HTMLファイルのヘッダ部分の、
  • 1行目: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  • 2行目: <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
  • 4行目: <meta charset="UTF-8" />
  • 5行目: <meta http-equiv="X-UA-Compatible" content="IE=9"/>
あたりは、必須事項…かも。
今回Office用アプリを作るにあたって、適当に省略してみたところ、アプリの読み込みはできるものの、作業ウィンドウ(task pane)に何も表示されないという残念なことになりました。

どんなに探してもカスタムツールバーが見当たらない


【概要】
Office2007以降では、通常、VBAでカスタムツールバーを作成する(CommandsBar.Addを実行する)と、「アドイン」タブ内に「ユーザー設定のツールバー」という名前のグループとして表示されるようになっています。
しかしながら、とある条件下では、
 『カスタムツールバーを作成しても「アドイン」タブが表示されない』
ことがあるのに気づいたので、それについてまとめています。

実験環境は、Office2013(Excel2013) Preview版です。
(未検証ですが、Office2007, 2010でも同様かと思われます。)

【実験環境と内容】

走らせたコードは以下の通り。


【いきなり結論】
こんなとこにあった。


「DATANITRO」っていうタブは、DataNitroアドインをインストールした際に作成されたものです。この「DATANITRO」タブ、どうも実態は「アドイン」タブっぽく、ユーザー設定のツールバーはここに追加されていました。

Commands.Barで追加したカスタムツールバーは、「アドイン」って名前のタブに追加されると思い込んでいたので、まったく気づきませんでした…。

【たぶんこういう原因】
  • DataNitroは、「アドイン」タブのタイトル名を改変してる。
    (「DATANITRO」タブ = 「アドイン」タブ)
→ 「DATANITRO」という名の「アドイン」タブにカスタムツールバーが追加される。

【勝手にこう思う】
そうそうないと思うのですが、
DataNitroに限らず、タブが追加されるタイプのアドインをインストールすることがあれば、
そのタブが「アドイン」タブと同一なのかという点に
気をつけた方が良いのかもしれないなぁと思ったりします。

(※ 汎用の「アドイン」タブとは別に、各アドイン専用のタブを作成するのが一般的じゃないかなと思ったりもするので、
   DataNitroの仕様が特殊なだけかもしれないです。)

Wordファイルに自動的に記録される情報の削除方法

【概要】
Wordファイルには、ファイルの作成者の情報をはじめ、種々の情報が自動的に記録されます。これらの情報は、第3者に渡ることは望ましくない場合があります。このため、以下では、これらの情報の削除の仕方を調べました。
Wordファイルに自動的に記録される情報には、

  • 「個人情報」 
  • 「隠し情報」 
と呼ばれる2種類の情報が含まれています。
このうち「個人情報」は、Wordのオプションで保存しないように設定が可能です。
また、「隠し情報」は、Microsoftが配布しているアドインを使って削除が可能です。

なお、以下ではWord2003での削除方法について記載しています。
(Word2007以降の場合は、手順が異なります。)

【「個人情報」の削除の方法】
  1. Word の上部メニュー[ツール(T)]から[オプション] を選択
  2. [セキュリティ] タブをクリックします。
  3. [保存時にファイルのプロパティから個人情報を削除する]をチェック
上記オプションをチェックすることで、「個人情報」が削除されるようです。
なお、「個人情報」として含まれている情報は、下記のようです。 (*1)
  • ファイルのプロパティに表示される作成者、管理者、会社名
  • コメントに付加されるユーザー名
  • 文書の版に付加されるユーザー名
  • [標準] ツールバーの [電子メール] ボタンをクリックしたときに
    生成される電子メールメッセージのヘッダー
  • 回覧先
【「隠し情報」の削除の方法】
Microsoftが公開しているアドイン(*2) を追加して手動で削除する必要があるようです。
「隠し情報」としては以下の情報が含まれているようです(*3)。
  • 保存された版の内容
  • Word の高速保存オプションで記録された変更情報など
Wordファイルを渡す相手が一般的なユーザであれば、「隠し情報」に関しては見られることはないと思いますが、念には念を入れて、削除しておいた方がいいかなと思います。

【参考情報】
(*1)[WD2003] Word 文書に保存されている個人情報と 個人情報の削除方法について
http://support.microsoft.com/kb/899877/ja

(*2)Microsoft DownloadCenter : Office 2003/XP アドイン: 隠しデータの削除
http://www.microsoft.com/ja-jp/download/details.aspx?id=8446

(*3)[WD2003] Word 文書に保存されている隠し情報と 隠し情報の削除方法について