InfoPath VSTA におけるデータ接続の制限

[今日のみちしるべ 第19回 次の道標] 今日、ゴッド(松崎さん)から連絡を受けたのですが、VS の製品グループの定例会見たいな場で VSTO がめちゃくちゃ熱いというお話をフィードバックいただきました。 ここでいう熱いは VS の売上の貢献度や OBA への認識度向上などを実際のデータから分析したものであると思います。 (実際に今日、VSTO による顧客ニーズの実現で VS と Office 2007の採用が決まる案件もありますが。そのネタは次回あたりにご紹介します。) そこで、松崎さん、小高さん、クリエ・イルミネートさん、山崎愛さん、そして私のブログの貢献度が取り上げられたらしいです。 要は製品を売りにつなげるには、単に技術情報の公開や翻訳ではだめで、技術情報とソリューションや技術要素の間を埋めるための人を介した情報が必要だということだと思います。 この話を聞いて、本当に報われました。 報われるということは、別に会社に評価をされるされないではなくて、自分がやってきたことはやっぱ正しかったということに対してです。 僕は松崎さんや小高さんみたいにブログを書くことを仕事で義務付けられてもおらず、この立場でブログを書くことにいろいろな批判もあり、揶揄もあり、アピールだと言われ続け(むしろ逆効果になっていますよ(爆笑))。 それでも、これは正しいと思ってやってきました。 3年前とは違い、たくさんの人が VSTO のメリットや楽しさを知り、そして、実際に触れるようになってきていると思います。 なので、たぶん、この立場でのVSTO における僕の役割は終わりだと思っています。(少しおおげさですが。。。) というか、たくさんの人が触れるようになってきているので、もう、この立場で僕がやる必要はないのかなと思います。(築き上げてきたものなんて、簡単に捨てれます(笑)) すべて、僕の貢献ではありませんが、一助になったとは思います。(現に今度の VS の製品カタログは OBA メインで僕のスライドからいくつか引用されています。) この一助を支えてくれた周りの皆様、そして、VSTOに対しての感謝は言葉に表すことはできません。 今後も道標は書き続けると思いますが、すでに僕には次の道標が待っているみたいです。   [本題] 今日の本題はかなりくだけてます。 このネタは同僚の隣の席のタッキー(ご存知ないとは思いますが。)と話をしていて再認識したのですが、 VS のデータ接続ウィザードと言えば、ADO.NET を利用してウィザード形式でデータソースを設定するあれ(笑)ですが、 InfoPath の VSTA における制限ってご存知でした?   つまり、SQL だとローカルのサーバーにしか接続できないんです。   これも本当に公開資料がなくて、生けるグーグル Live Searchと呼ばれる私が社外の情報を本当に探したんですよ。…


Office 2007 の閉じるボタンの非表示や無効化について

今回はパートナー様からのご質問でいただいて調査していた件になります。   Office 2007 の閉じるボタンについてですが、  Office 2007 では、アプリケーション ウィンドウの閉じるボタンが Office アプリケーションにより独自で描画されているため リボンXML による編集や VBA Win32 API 等を使用して非表示にすることはできないようです。 Windows API の GetSystemMenu でシステム メニューのハンドルを取得後に DeleteMenu でボタンを無効にする方法や、Before_Close イベントを用いて終了処理をキャンセルする方法しかないようです。    GetSystemMenu http://msdn.microsoft.com/ja-jp/library/cc364748.aspx   DeleteMenu http://msdn.microsoft.com/ja-jp/library/cc410754.aspx   このあたりは Office 2003 まではなんとかなっていたようなのですが、仕様変更になったようです。 こういうのサポート技術情報が欲しいところです。 パートナー様でカスタマイズされて開発されているケースが多いので。 今度、サポート部門に相談しておきます。

1

VSTO (2007 Office systemベース)のドキュメントレベルのカスタマイズをメール添付し送信した場合の問題点

VSTO のドキュメントレベルのカスタマイズをメール添付して相手に送信した場合、たとえ、VSTO のカスタマイズがインストールされていても以下のセキュリティのエラーが表示され開くことはできません。     通常このエラーは「セキュリティセンター」の「信頼できる場所」にカスタマイズアセンブリの場所の登録がない場合に発生いたしますが、Outlook の添付メールを開く一時領域の場所を「信頼できる場所」に登録しても回避できません。   以下、Outlook の添付ファイルの一時領域のパスの例です。 ※パスはドキュメントのプロパティから確認できます。   Windows Vista C:\Users\<Username>\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.Outlook\<GUID名>\2008年10月16日_001_佐藤博_第一営業部.xlsx   Windows XP C:\Documents and Settings\<Username>\ Local Settings\Temporary Internet Files\Content.Outlook\<GUID名>\2008年10月16日_001_佐藤博_第一営業部.xlsx   理由ですが、Outlook の添付ファイルを開く一時領域の場所はセキュリティ強化の面から安全ではないファイルが一時的に置かれる可能性がある場所 (フォルダおよびサブ フォルダ) を安全な場所として [信頼できる場所] に登録することはできないため。ファイルを開いた場合に一時ファイルが作成される可能性がある Temp フォルダ、メールの添付ファイルのキャッシュや Internet Explorer からダウンロードしたコンテンツの一時ファイルが保存される Internet Temporary Files フォルダ、ドライブなどが登録不可対象の場所となるためだそうです。   OBA のシナリオでは SharePoint のメール通知機能などを利用して VSTO のカスタマイズの場所をリンクとして通知することがあります。 同様に添付ファイルとしても利用することはあると思うのですが、どう考えてもこの仕様はセキュリティ設定の競合じゃないかなと。 なんとかなんないものでしょうか。 でも、さすがにこれは難しいかなー。 ちなみに…