» VisualStudioのブログ記事

VB.NETにおいて、文字列を整数型の数値に変換する関数として、Cint，Clng，Valといったものがあるが、
Val関数とClng関数は同じ結果になると思いこんでいた。

実際は、Clng関数は、Long型の数値に変換される。
一方、Val関数は、17桁まで有効なLong型の数値に変換されるようだ。

ex)
Dim v as String = “120002112365008889” ’18桁の数字文字列
dim lngV as Long = Clng(v) ‘120002112365008889
dim valV as Long =Val(v) ‘120002112365008880　←　18桁目が0になる

Excel2010に含まれるCommandBarを調べてみた。
Word版はこちら。

認識できないコンテキストメニュー(*2)

只今、確認中！

*1,*2) 確認した項目のみ記載，VSTO(v4)とExcel2010環境にて確認。

のバージョンアップ版を現在作成している。
EasyPrint for Word 2007/2010の公開後に開発をスタートしたので、かれこれ2ヶ月が経過しているが、未だに完成に至っていない。

現在のバージョンは、開発に約30人工（＝8Hour×30日×1人）かかっているが、今回は既に60人工は超えている。
バージョンアップだから…と高をくくっていたが、思いの外時間がかかる。
なぜ、こんなに時間がかかるかというと、機能を増やし過ぎたことが原因だ。

現在のバージョンは、選択範囲を1枚に印刷する機能しかない。

今回のバージョンは、

・選択範囲を1枚に印刷する。
・印刷対象を1枚に印刷する。
・ページ設定を管理できる。
・印刷履歴を管理できる。

昨今のエコ印刷を目的とした、
白黒印刷やドラフト印刷が簡単にできます。

予定では…＾＾；

VisualStudioでVSTOを使ったプロジェクトを開いていて、PCが強制終了された場合、あるいは、休止状態から復帰した場合に、リボンインターフェースでエラーがよく出ます。
無視して続けると、問題なく表示されますが、上書き保存しても、次回以降プロジェクトを開いた時に毎回同じ状態になります。
何とかならないか？

追記（2011/08/19）

ちなみに、リボンインターフェースのファイルには悪いところはありません。
新たな編集を加えると治るようです。（知らないうちにこのエラー出なくなっていた。）

追記（2011/08/20）

無視して続行すると、オブジェクトイベントの関連づけが全て消えてしまうことが発覚しました。

Private Sub Button1_Click(～省略～) Handles Button1.Click
　　～　中略　～
End Sub

上記のイベントプロシージャのHandles の部分が消えます。

とにかく毎回Handles 句を記述し直すのもアホらしいので、どこに原因があるのかを調べてみました。
結論からいうと、リボンインターフェースの記述自体には特に問題はありません。

小生の行った作業は次の通り。
(1)リボンインターフェースのプロシージャを全て削除する
　Imports句とPublic Class HogeHoge　～　End Classの宣言は残します。
　自分が追加したプロシージャのみ削除します。
　なお、実際には削除ではなく、メモ帳などにコピーを残しておきます。

(2)削除したプロシージャを一つずつ復活させていく。
　プロシージャを復活させる都度、リボンインターフェースにエラーが表示されないことを確認します。

(3)エラーが確認された場合は、問題のプロシージャを精査します。
　小生の場合は、プログラム記述時に、処理内容別に#region句で区切るので、#region句毎に復活させていったところ、右クリックメニューを生成するプロシージャを復活させた時にエラーがでました。
　このプロシージャには、リボンインターフェースとは関係なく自分でオブジェクトを生成し、WithEvents句で宣言したオブジェクトのイベントをHandles句で記述していました。
　これが原因なのかと考え、今度は、#Region句単位ではなく、プロシージャ単位でコードを復活させたら、何事もなかったかのようにエラーは出なくなりました。

結局のところ、原因はわかりません。

VS2008とOffice2007で作成したアドインをmsi形式で配布するためにWindowsインストーラーでセットアップファイルを作成してみた。

基本的には、松崎　剛さんのBlogに記載されている通りでOKなので補足を書きます。
http://blogs.msdn.com/b/tsmatsuz/archive/2008/03/31/vsto-v3-windows-installer.aspx

(1)VS2008を起動し、新規プロジェクトとして、VBでWord2007アドインを作成する。
.Net Framework3.5が作成するのが無難です。

(2)上記のアドイン（ソリューション）に新規プロジェクトとしてセットアッププロジェクトを追加する。
セットアッププロジェクトで設定する項目は次の通り。

(2.1)セットアッププロジェクトのプロパティ
InstallAllUsersの項目はFalseにする。
Office2007のアドインは、AllUser（LOCAL_MACHINE）にインストールすることができないので

(2.2)ファイルシステム
アプリケーションフォルダにアドインプロジェクトのプライマリ出力を追加する。
また、アドインを一度ビルドした後、*.dll.manifestと*.vstoファイルを手動で追加する。

(2.3)レジストリ
HKEY_CURRENT_USER\Software\Microsoft\Office\Word\AddIns\macroya.easyprintwに次の値を登録する
ちなみに、「macroya.easyprintw」は、アドイン識別名で、重複しなければ何でもよいようだ。
「easyprintw」だけだと、万が一他の人が同じ名前をつけたときに、アドインが正常に動かなくなるため、自分を識別する「macroya」をつけている。

(a)Description　：　EasyPrint for Word2007
(b)FriendlyName　：　EasyPrint for Word2007
(c)Manifest　：　[TARGETDIR]easyprintw.vsto|vstolocal
(d)LoadBehavior　：　3

(a)から(c)は、文字列の値
(d)は、DWORD値

(a),(b)は、Wordに表示されるアドインの名前
(c)は、配置先。「[TARGETDIR]」は、通常は、c:\ProgramFiles\製造者名\製品名\　となるようだ。
(d)は、3を入力すると、起動時に読み込まれる。

(2.4)ユーザーインターフェース
インストールフォルダのInstallAllUserVisibleプロパティをFalseにする。
これは、上記(2.1)と同様の理由。

(2.5)起動条件
小生の環境では、セットアッププロジェクトの必須コンポーネントで、.Net Frameworkや、VSTO Runtimeを選択してもアドインのインストール時には、これらのコンポーネントはインストールされませんでした。
該当するWebページにも移動しませんでした。
なので、起動時にRuntimeの確認とWord2007の確認を行うように設定します。

ここまでで、セットアッププロジェクトをビルドすると、アドインがただしくインストールされ、使用できることが確認できました。

松崎さんのブログでは、これだけでは、対象となるアプリを起動した場合に、Inclusion List 絡みの確認メッセージが出現すると記述されています。

小生の環境では、最初にアドインをインストールしたときは、この確認メッセージは表示されませんでしたが、VSTO Runtimeなどすべて削除した状態で、再度、アドインのインストールを試みたら、英文表記で確認メッセージが表示されました。
というわけで、この確認メッセージの回避はやはり必要なようです。

この回避方法としては、回避プロジェクトをソリューションに追加すればよいと書かれており、C#でのコードも記述されています。
手動で、このプロジェクトを新規に作成し、このC#のコードをVBに変換したものをしようして、クラスに追加すると、エラーがいっぱいでて上手くいきません。
松崎さんのブログをよくよく読むと、サンプルのダウンロードサイトを案内してくれています。

http://code.msdn.microsoft.com/VSTO3MSI/Release/ProjectReleases.aspx?ReleaseId=729

このサイトでダウンロードしたファイルには、VBで記述されたサンプルも収録されています。
これを利用すればOKです。