Windows Live Writerがアップデートしたら動かなくなっていたのは、横着してWLWの内部的なアセンブリを直接参照した時点でまぁ予見出来た話ではあるのですが･･･。今回はちゃんとリフレクションで書き直しております。また、WordPressとのやり取りも、WP-XML-RPCLib2で行うように変更しました。

WPCustomFieldsEditor.zip

ソースコード：WPCustomFieldsEditor.sln.zip

エントリの投稿時に、はてなブックマークに当該エントリを保存する機能を、Windows Live Writerに追加するプラグインです。

ダウンロード

SelkmaPluginSetup.zip

動作環境

• Microsoft Windows XP SP2 以降または Windows Vista（Windows Live Writerに準拠）
• Microsoft .NET Framework 2.0以上
• Windows Live Writer Beta（Build14.0.5025.904)

※現在、Writer Zoneで配布されているTechnical Preview版では、おそらく動作しなくなっています。ご注意ください。

インストール方法

ダウンロードしたファイルを展開してsetup.exeを実行してください。

アンインストール方法

コントロールパネルのプログラムの追加と削除からSelkmaPluginを選択し削除してください。

操作説明

エントリの投稿を行うと、スプラッシュウィンドウに続いてブックマークコメントの編集画面が現れます。[OK]を押せばブックマークされ、[Cancel]を押せばエントリの投稿だけが行われます。

また、初回実行時には、ブックマークする際に使うはてなのアカウントを尋ねるダイアログが表示されます。使いたいアカウントのユーザー名とパスワードを正しく入力してください。設定したはてなのアカウント情報を後で変更したい場合は、WLWのオプションのプラグインの項から編集することが出来ます。

謝辞

はてなブックマークに追加する処理の部分は、JZ5さんのはてブをプログラムから追加するというエントリのコードを参考にさせて頂きました。有難うございました。

ソースコード

SelkmaPluginSln.zip

更新履歴

• 2008-10-04 イニシャルリリース

で、以下が書き直した後のOnPostPublishメソッドのソースコード。

        public override void OnPostPublish(IWin32Window dialogOwner, IProperties properties, IPublishingContext publishingContext, bool publish) {

            PostEditorForm postEditorForm = getPostEditorForm(dialogOwner);
            Blog blog = new Blog(postEditorForm.CurrentBlogId);
            PropertyInfo propInfo = blog.GetType().GetProperty("BlogClient", BindingFlags.NonPublic | BindingFlags.Instance);
            IBlogClient blogClient = (IBlogClient)propInfo.GetValue(blog, null);

            WordPressClient xmlRpcClient = blogClient as WordPressClient;
            if (xmlRpcClient != null && !publishingContext.PostInfo.IsPage) {

                const string userAgent = "WPCustomFieldEditor";

                XmlRpcString postId = new XmlRpcString(publishingContext.PostInfo.Id);
                XmlRpcString userName = new XmlRpcString(xmlRpcClient.Username);
                XmlRpcString password = new XmlRpcString(xmlRpcClient.Password);

                HttpRequestFilter filter = delegate(System.Net.HttpWebRequest request) {
                };
                XmlRpcClient client = new XmlRpcClient(blog.PostApiUrl, userAgent, filter, xmlRpcClient.Options.CharacterSet);
                XmlRpcMethodResponse res = client.CallMethod("metaWeblog.getPost", postId, userName, password);
                if (res.FaultOccurred) {
                    showErrorMessage(dialogOwner, res.FaultString);
                    return;
                }

                XmlNodeList customFieldsNodes = res.Response.SelectNodes("//struct/member[name="custom_fields"]/value/array/data/value/struct");

                CustomField[] customFields = new CustomField[customFieldsNodes.Count];
                for (int i = 0; i < customFieldsNodes.Count; i++) {
                    XmlNode item = customFieldsNodes[i];
                    customFields[i] = new CustomField();
                    customFields[i].Id = item.SelectSingleNode("member[name="id"]/value/string").InnerText;
                    customFields[i].Key = item.SelectSingleNode("member[name="key"]/value/string").InnerText;
                    customFields[i].Value = item.SelectSingleNode("member[name="value"]/value/string").InnerText;
                }

                WPCustomFieldsEditor fieldEditor = new WPCustomFieldsEditor(customFields, this.Options);
                DialogResult result = fieldEditor.ShowDialog(dialogOwner);
                if (result == DialogResult.OK) {

                    Func getRpcMemberValue = delegate(string name) {
                        return res.Response.SelectSingleNode("//struct/member[name="" + name + ""]/value/*").InnerText;
                    };

                    XmlRpcStruct[] cv = new XmlRpcStruct[fieldEditor.CustomFields.Length];
                    for (int i = 0; i < cv.Length; i++) {
                        CustomField sourceItem = fieldEditor.CustomFields[i];
                        List<XmlRpcMember> structMember = new List<XmlRpcMember>();
                        if(!string.IsNullOrEmpty(sourceItem.Id)){
                            structMember.Add(new XmlRpcMember("id", sourceItem.Id));
                        }
                        if(!string.IsNullOrEmpty(sourceItem.Key)){
                            structMember.Add(new XmlRpcMember("key", sourceItem.Key));
                        }
                        structMember.Add(new XmlRpcMember("value", sourceItem.Value));
                        cv[i] = new XmlRpcStruct(structMember.ToArray());
                    }

                    XmlRpcStruct content = new XmlRpcStruct(new XmlRpcMember[]{
                        new XmlRpcMember("title",getRpcMemberValue("title")),
                        new XmlRpcMember("description",getRpcMemberValue("description")),
                        new XmlRpcMember("mt_text_more",getRpcMemberValue("mt_text_more")),
                        new XmlRpcMember("mt_allow_comments",getRpcMemberValue("mt_allow_comments")),
                        new XmlRpcMember("mt_allow_pings",getRpcMemberValue("mt_allow_pings")),
                        new XmlRpcMember("mt_keywords",getRpcMemberValue("mt_keywords")),
                        new XmlRpcMember("wp_slug",getRpcMemberValue("wp_slug")),
                        new XmlRpcMember("wp_password",getRpcMemberValue("wp_password")),
                        new XmlRpcMember("wp_author_id",getRpcMemberValue("wp_author_id")),
                        new XmlRpcMember("mt_excerpt",getRpcMemberValue("mt_excerpt")),
                        new XmlRpcMember("mt_keywords",getRpcMemberValue("mt_keywords")),
                        new XmlRpcMember("custom_fields",new XmlRpcArray(cv))
                        });
                    XmlRpcBoolean isPublish = new XmlRpcBoolean(publish);

                    res = client.CallMethod("metaWeblog.editPost", postId, userName, password, content, isPublish);
                    if (res.FaultOccurred) {
                        showErrorMessage(dialogOwner, res.FaultString);
                        return;
                    }
                }

            }

        }

WLWによるエントリの投稿が終わった後に呼び出され、サーバーからその投稿されたエントリのデータを取得し（20行目付近）、それに基づいてカスタムフィールドのデータを付加したエントリのデータを作成して投げ直すという流れ。

HKEY_LOCAL_MACHINESOFTWAREWindows LiveWriterPluginAssemblies
HKEY_CURRENT_USERSOFTWAREWindows LiveWriterPluginAssemblies

以上の二つのレジストリのいずれかの下にアセンブリの場所を示す文字列値を追加すれば良い、とMSDNでは書かれているのですが、これは間違いで、

HKEY_LOCAL_MACHINESOFTWAREWindows Live　WriterPluginAssemblies
HKEY_CURRENT_USERSOFTWAREWindows Live　WriterPluginAssemblies

でなければならないようです。WPCustomFieldsEditorのバグフィックスの過程で気づきました。MSDN…。

daruyanagiさん、変な使い方してごめんなさい。
でもalt属性も別に編集できるようにしてくれるとありがたいです(ｺﾗ

Windows Live Photo GalleryのPublishing Plug-in（以下Publishing Plug-in）の作成はIPublishPlugin Interfaceを実装したクラスを作成し、そのアセンブリのパスやIPublishPlugin Interfaceを実装したクラスの完全限定名などをPublishing Plug-in Registry Settingsに従ってレジストリに登録すれば出来上がり、という流れです。属性を活用していたWLWに比べると、ちょっとレガシーですね。IPublishPlugin Interfaceを実装するにあたってはPublishing Plug-in Architectureを参照し、どのメソッドがどのタイミングで呼び出されるかを確認するとよいでしょう。メソッドの呼び出しの合間に、Live Photo Galleryが進捗状況を表示するダイアログを挟みこんできたりするので…。また、Publishing Plug-in Platformは、IPublishPluginのメソッドを呼び出す際、IPublishPlugin Interfaceを実装したクラスのインスタンスを使いまわさず、インスタンスを生成し直してくる場合があるので、その点にも注意した方がよいでしょう。

折角なので、BlogThisPluginのソースコードを晒してみます。

using System;
using System.Collections.Generic;
using System.Text;
using System.Xml;
using Microsoft.WindowsLive.PublishPlugins;
using WindowsLive.Writer.Api;

namespace SharpLab.BlogThisPlugin {
    public class PublishPlugin : IPublishPlugin{

        public bool HasPublishResults(System.Xml.XmlDocument sessionXml) {
            throw new NotImplementedException();
        }

        public bool HasSummaryInformation(System.Xml.XmlDocument sessionXml) {
            throw new NotImplementedException();
        }

        public void LaunchPublishResults(System.Xml.XmlDocument sessionXml) {
            throw new NotImplementedException();
        }

        public bool PublishItem(System.Windows.Forms.IWin32Window parentWindow, string mediaObjectId, System.IO.Stream stream, System.Xml.XmlDocument sessionXml, IPublishProperties publishProperties, IPublishProgressCallback callback, System.Threading.EventWaitHandle cancelEvent) {
            throw new NotImplementedException();
        }

        public void ShowSummaryInformation(System.Windows.Forms.IWin32Window parentWindow, System.Xml.XmlDocument sessionXml) {
            throw new NotImplementedException();
        }

        public bool ShowConfigurationSettings(System.Windows.Forms.IWin32Window parentWindow, System.Xml.XmlDocument sessionXml, System.Xml.XmlDocument persistXml, IPublishProperties publishProperties) {
            if(!WriterApplication.IsInstalled){
                System.Windows.Forms.MessageBox.Show(parentWindow, "Windows Live Writer is not Installed.", "BlogThis Plugin",
                    System.Windows.Forms.MessageBoxButtons.OK, System.Windows.Forms.MessageBoxIcon.Error);
            }
            else{
                blogThis(parentWindow, sessionXml);
            }
            return false;
        }

        private void blogThis(System.Windows.Forms.IWin32Window parentWindow, System.Xml.XmlDocument sessionXml) {
                XmlNodeList items = sessionXml.SelectNodes("/PhotoGalleryPublishSession/ItemSet/Item[PerceivedType="image"]/FullFilePath");
            if(items.Count==0){
                System.Windows.Forms.MessageBox.Show(parentWindow, "Please select at least one image.", "BlogThis Plugin",
                    System.Windows.Forms.MessageBoxButtons.OK, System.Windows.Forms.MessageBoxIcon.Warning);
                return;
            }
            string[] fileNames = new string[items.Count];
                for (int i = 0; i < items.Count; i++) {
                    fileNames[i] = items[i].InnerText;
                }
                WriterApplication writer = new WriterApplication();
                writer.BlogThisImageFileList(null, fileNames, null);            

        }
    }
}

うわぁNotImplementedExceptionばっか。。。BlogThisPluginでは、最初に呼び出されるShowConfigurationSettingsメソッドの段階でfalseを返してしまうことにしました。これは、写真のアップロードを直接するわけではないため、Live Photo Galleryの挟みこんでくるダイアログが邪魔だったからです。まぁ、こういうのもありかもね、ということで。そのうちにPublishing Plug-inのアーキテクチャに沿ってWordPressにXMLRPC-APIを使って画像やらを投稿するプラグインも試作してみたいと思います。

ちなみにソリューション全体はこちらにアップしています。

http://depot.sharplab.net/CSharp/WLWPlugin/BlogThisPluginSln.zip

真っ当に実装されたMS謹製のFlickerのプラグインより簡単に弄れるたたき台としてどうぞ。

This is a simple plugin that adds “BlogThis” menu to Windows Live Photo Gallery. You can click this menu and launch Windows Live Writer with a new BlogThis post that contains selected images.

Download

BlogThisPluginSetup.zip

System Requirements

• Microsoft Windows XP SP2 or later, or Windows Vista
• Minimum 512 MB of RAM (based on the profile of Windows Live Photo Gallery)
• Microsoft .NET Framework 2.0 or higher
• Latest version of Windows Live Photo Gallery
• Latest version of Windows Live Writer

How to install

Please unzip BlogThisPluginSetup.zip, and execute setup.exe.

How to uninstall

Please uninstall by “Add or Remove Programs” utility in the Control Panel.

Releases

2008-09-23 Initial version released.

しかし画面のデザインはWave 3に合わせる形で、変更が加えられたようだ。CTP版からGUI要素の位置には変更がないようだが、色遣いや区切り線の入れ方が変わっている。正直なところを言うと、CTP版の頃の方が自分は良かった…。

WLW 自体は書き換えられることを想定してないので、プラグインから書き換えても投稿後にエディタ中の表示は変化しません。

Publish Notification Hook プラグイン 値の書き換え-katamari.wankuma.com

という問題などに行き当たったりしてきました。そこで、今回はエントリのメタ情報を編集するためのGUIコントロールのインスタンスのプロパティを弄ることで画面の書き換えも行ってみました。適用できる部分は限られ、根本的な解とは言い難いですが、参考まで。

今回は例としてタグの設定を行ってみたいと思います。

Textboxのインスタンスの取得方法

さて、操作の対象としたいWLW下部のプロパティパネルにあるタグ設定用のTextBoxですが、これのインスタンスのNameプロパティの値が分かれば、

private static Control findControlByName(Control control, string controlName) {
    foreach (Control cChild in control.Controls) {
        if (cChild.Name == controlName) {
            return cChild;
        }
        if (cChild.HasChildren) {
            Control returned = findControlByName(cChild, controlName);
            if (returned != null) {
                return returned;
            }
        }
    }
    return null;
}

上のようなメソッドを用意することでトップレベルのコントロールから包含関係を伝ってインスタンスを取得することが出来ます。

ではそのNameプロパティの値ですが、今回はWLWのプラグインにアタッチさせたVisual Studioのローカル変数ウィンドウからコントロールのツリー構造を辿って調べる方法ではなく、Managed Spyというツールを使って調べる方法を紹介してみたいと思います。

Managed Spy

ManagedSpy は、別プロセス内のマネージドコントロールのプロパティおよびイベントの表示・編集を行えるツールで、MSDN Magazineの06年4月号の記事（原文、但しツールへのリンク消滅）と共に配布されています。SPY++のマネージド版という説明がよくなされているようですが、自分はSPY++を触ったことがないのでよく分かりません＞＜。

なお、別プロセス内のマネージドコントロールにアクセスする方法はmanaged C++で書かれたManagedSpyLibというライブラリが提供しているようです。ソースコードの提供もされているので、興味があれば覗いてみると良いのではないでしょうか。

話をManaged Spyを使ったWLWのコントロールの調査に戻します。WLWを起動後、Managed Spyを起動すると、 図のようなウィンドウが開きます。左側のツリービューには起動中のマネージドアプリの一覧が表示され、ツリーを展開してゆくことでコントロールのツリー構造を調べてゆくことが出来ます。選択しているツリーのノードがどのコントロールと対応しているかを見たい場合は、メニューから「Show Window」というメニューを実行してやれば、FirefoxのDOM InspectorやFirebugのように、選択されたコントロールを囲む形で矩形を表示させることが出来ます。

さて、そうやって発見したのがこのtextBoxKeywordsという名前のTextBox。コントロールのインスタンスの名前をアタッチさせたVSから調べるのはなかなか骨の折れる作業ですが、Managed Spyを使えば大分楽に出来ました。

なお、右側のVisual Studioのプロパティウィンドウのようなビューは表示だけでなくプロパティの編集も可能なので、WLWに対して色々イタズラをすることも可能です。

例えばエディタ部分を非表示にしてみた例。…だからどうしたって感じですが（笑）

実際に書き換えてみる

後は簡単です。こんな感じのコードでタグの書き換えが出来ます。

public override bool OnPrePublish(System.Windows.Forms.IWin32Window dialogOwner, IProperties properties, IPublishingContext publishingContext, bool publish) {

    PostEditorForm postEditorForm = getPostEditorForm(dialogOwner);
    TextBox textBoxKeywords = (TextBox)findControlByName(postEditorForm, "textBoxKeywords");
    textBoxKeywords.Text = "SampleTag";
    ((BlogPost)publishingContext.PostInfo).Keywords = textBoxKeywords.Text;
    return true;
}

3行目、6行目については、中まで見よう！Windows Live Writer – Sharplab.のエントリを参照してください。

なお、用意したテスト用コード全文は以下の通りです。

using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;
using System.Windows.Forms;
using WindowsLive.Writer.Api;
using WindowsLive.Writer.BlogClient;
using WindowsLive.Writer.BlogClient.Clients;
using WindowsLive.Writer.PostEditor;
using WindowsLive.Writer.Extensibility.BlogClient;

namespace PublishNotificationHooksTestbedPlugin {
    [WriterPlugin("95c3d56c-671a-46a0-8bef-3d064d85867e", "PNHTestbedPlugin", PublisherUrl = "http://www.sharplab.net/")]
    public class PublishNotificationHooksTestbedPlugin : PublishNotificationHook {
        public override bool OnPrePublish(System.Windows.Forms.IWin32Window dialogOwner, IProperties properties, IPublishingContext publishingContext, bool publish) {

            PostEditorForm postEditorForm = getPostEditorForm(dialogOwner);
            TextBox textBoxKeywords = (TextBox)findControlByName(postEditorForm, "textBoxKeywords");
            textBoxKeywords.Text = "SampleTag";
            ((BlogPost)publishingContext.PostInfo).Keywords = textBoxKeywords.Text;
            return true;
        }

        private static PostEditorForm getPostEditorForm(IWin32Window postProgressForm) {
            return (PostEditorForm)((Form)Form.FromHandle(postProgressForm.Handle)).Owner;
        }

        private static Control findControlByName(Control control, string controlName) {
            foreach (Control cChild in control.Controls) {
                if (cChild.Name == controlName) {
                    return cChild;
                }
                if (cChild.HasChildren) {
                    Control returned = findControlByName(cChild, controlName);
                    if (returned != null) {
                        return returned;
                    }
                }
            }
            return null;
        }
    }
}

崩れる原因

さて、WLWの編集画面ではなぜテーマが崩れてしまうのでしょうか？WLWの描画エンジンがアホの子だから？ノー。WLWのエンジンはTridentです。確かにTridentはアホの子ではありますが、少なくともデファクトスタンダードであるIEと同じ表示になるわけですから、ここでは問題になりません。

答は「WLWが編集画面に読み込むページのソースでは記事に関係のない部分、つまりタイトルと本文以外の部分の要素を全て削除してしまうから」です。WLWが取得してきたテーマはC:Users<ユーザー名>AppDataRoamingWindows Live Writerblogtemplates<ブログのGUID？>のどこかに保存されているのですが、それをFirebugでツリー表示したのが左のSSです。 ん～、見事なまでのふたこぶラクダ。タイトルの要素と、本文の要素、そしてそれらを囲む要素だけしか残っていません。ヘッダーやフッター、サイドバーは情け容赦なく消されています。visibility:hiddenが適用されているのではなく、要素自体が残っていません。これにより、その消された要素にレイアウトが依存しているテーマは表示が崩れてしまうのです。このサイトの新デザインも、消された要素によってfloatをclearしていた個所があったので、本文部を囲っているfloat要素の高さがゼロになり、白い背景が伸びずその下の暗色の横ストライプが見えてしまっていました。

対策

では、こんな時どうするか。WLWは諦めてしまうにはあまりに便利で惜しいソフトです。何とか対策を考えてみましょう。

対策1：サイトのテーマを全面的に修正する

ページのHTMLの構造を書き換える、floatは必ずclearfixでクリアする、など八方手を尽くしてWLW上では消えてしまう要素への依存をなくし、WLW Compatibleなテーマに書き換えるという方策です。これはサイトの設計時点で取り組まないと難しいでしょう。確実ですが、サイトの表現力にも影響を与えますし、本末転倒な気がします。

対策2:WLWがテーマをDLする時だけサイトのデザインを差し替える

WLWがテーマをDLする時を見計らって、その時だけstyle属性などでガチガチに固めてWLW対策をしたテーマに差し替えるという方法です。どうせ回り込ませるはずだった要素が消えてしまうなら、その時はfloatも辞めてしまえ、とか対策をします。差し替えはマニュアル操作でもよいですが、WordPressのようにテーマがプログラマブルな場合は、WLWに設定するホームページのURLにwlwcompatiblemode=onなどの適当なgetパラメタを追加し、テーマの側でそのようなパラメタが付加された場合だけWLW対策用のCSSを追加で読み込ませる、といった方法を採ることもできます。（WLWはテーマをWLWの設定でサイトのホームページとして指定したURLの内容から生成するので。）ちなみに自分はこの方法を使っています。

対策3:ダウンロードされたテーマの書き換え

ダウンロードされたテーマはC:Users<ユーザー名>AppDataRoamingWindows Live Writerblogtemplates<BlogのGUID？>に保存されると述べましたが、これを編集することでも対処できるようです。ただ、WLWの想定していない操作なので、副作用もあるかもしてないので、注意して行った方が良いでしょう。また、自動でWLWがテーマをウェブサイトから再読み込みして上書きしてしまう場合もあるらしいので、その点にも注意してバックアップを取るなりの対策が必要でしょう。

テーマのDLに失敗する場合

エントリの本題からは少しずれますが、テーマのDLに失敗する場合の原因とその対策で自分が知っているものを一セット紹介してみます。

前述の通り、WLWはテーマをWLWの設定でサイトのホームページとして指定したURLの内容から生成するようです。このとき、ホームページとして設定されたURLに最新記事が表示されない場合は、WLWはどこがタイトルに置き換えるべきところで、どこが本文に置き換えるべきところか判断がつかず、テーマの生成に失敗してしまいます。例えば、WordPressでホームページに最新記事の代わりに固定ページを表示させるようにした場合などがこれにあたります。前述の対策2を行えばよいでしょう。

おわりに

以上、WLWでデザインが崩れた際の対応策をまとめてみましたが、いかがだったでしょうか？このエントリがWLWの快適な利用に繋がれば幸いです。

しかし…WLWが表示の必要のない要素の扱いを削除からvisibility:hiddenの適用に改めてくれれば多分全て解決するはずなんですけれどねぇ…レイアウトが崩れるリスクを取ってまで要素を削除する理由ってなんなんでしょうかね。

はてなインターンで実装されたというはてなダイアリーのAtom Pub APIを使って、Windows Live Writerからはてダに投稿できないか試してみました。
結論から先に言ってしまうと、登録出来ませんでした。残念…。 とりあえず、どこで失敗しているっぽいか調べた際のレポートを載せておきます。

どこで失敗するかというと、Windows Live Writerに新しいアカウントを追加する際。FiddlerでWLWの通信を覗いてみたところ、アカウントの追加画面でBlogのタイプをAtom Pub APIに設定し、エンドポイントURLを入力してやって次の画面に進もうとすると、WLWはそのエンドポイントURLに対してまず認証無しでGETリクエストを投げるようです。当然はてなのAtom Pub APIはこれを拒否し、401 Unauthorizedを返すのですが、これに対してWLWは今度はちゃんとWSSE認証のためのヘッダを付けてGETリクエストを送るようです。 良い感じですね。ところがこれに対してはてなAtom Pubは403 Forbiddenを返してきます。なんで？

401 Unauthorizedを返してこないので、認証には成功したようなのですが、ちょっとこれは謎仕様。このためWLWは一つ目のSSのようなダイアログが出てこれ以上登録を進めることが出来なくなります。ん～何が悪いんでしょうかね…。

ソースコードをハイライト表示してくれるので非常に便利なSyntaxHighlighter。JZ5さんがSyntaxHighlighter for Windows Live WriterというプラグインでWLW上でスマートコンテントとして管理できるようにしてくれているので、WLW好きの自分としては是非このBlogにも組み込みたいと思い、作業していたのですが、その中でSyntaxHighlighterの表示の不具合にぶつかりました。今回のエントリではその対応策を記します。

SyntaxHighlighterの持つ問題

SyntaxHighlighterは、通常、一行あたりの文字数が多くSyntaxHighlighterの表示部の横幅を超えるようなソースコードの場合、white-space:normal;の指定により、折り返し表示してくれるようになっています。ですが、半角文字列の折り返しは単語毎に行われるというブラウザの仕様のためか、場合によってはソースコードの折り返しが上手く行われず、横スクロールバーが表示されてしまうという問題があります。そうなると、スクロールした部分は背景の塗り分けが上手く行われず、SSのように違和感のある表示になってしまう、という問題があります。

対応策

上手く折り返し表示させる方法がよく分からなかったので、自分の場合、常に折り返し無しで表示することにしました。そして背景の塗り分け自体も廃し、常時横スクロールバーを表示。また、上のツールメニューもあわせて表示の仕方を変更しました。

長々と言葉で説明しても冗長になるだけなので、SyntaxHighlighterのCSSを上書きするのに使用したCSSファイルを示します。

.dp-highlighter{
	overflow-y:visible;
	overflow-x:scroll;
	background-color:#fcfcfc;
	width:100%;
}
.dp-highlighter ol li,.dp-highlighter ol li.alt{
	background-color:#fcfcfc;
	white-space:pre;
}
.dp-highlighter ol li, .dp-highlighter .columns div, .dp-highlighter .tools {
	border-left:3px solid #e26c6c;
}
.dp-highlighter .tools{
	font-size:120%;
	height:2em;
	padding:0px;
	background-color:#fcfcfc;
}
.dp-highlighter .tools a{
	font-size:100%;
	display:block;
	color:#888888;
	float:left;
	height:1.5em;
	margin:0px;
	padding-top:0.4em;
	padding-bottom:0.1em;
	padding-left:0.5em;
	padding-right:0.5em;
	background-image:url("images/shToolsBG.png");
}
.dp-highlighter .tools a:hover{
	background-image:none;
	background-color:#ffffff;
}
.dp-highlighter ol.dp-c{
	clear:both;
	background-color:#fcfcfc;
}

実際に適用するとこんな感じ。

スクロールさせても崩れてません。

今回は不具合修正をきっかけとして既製のライブラリのCSSの上書きに取り組みましたが、今回のツールメニューや左ボーダーの変更のように、単なるデザインの変更にも使えるので、結構ブラックボックス化しがちなライブラリのデザインを、サイトのデザインと調和させる目的でも色々弄ってみてはいかがでしょうか。

追記

このCSSは桁の表示には未対応です。まぁ全角文字が含まれているとどうせズレが生じるし、放置で良いかな･･･。

このエントリではWPCustomFieldsEditorを製作するにあたって蓄えたトリビア（死語？）紹介をしてみます。後半愚痴だか雑記だかよく分からなくなっていますが。 ん？二度ネタが多い？それは仕様です。

ログイン情報の取得方法

WPCustomFieldsEditorではXML-RPCを使ってWordPressを操作しています。WordPressをXML-RPCで操作するには、WordPressのエンドポイントURLとログインするためのユーザー名とパスワードが必要となります。これらは、リフレクションなどを使って、Windows Live Writer（以下WLW）が内部に保持している情報を取得しています。エンドポイントURLはBlogクラスのPostApiUrlプロパティから、ユーザー名とパスワードはXmlRpcBlogClientクラスのUsernameプロパティ、Passwordプロパティからそれぞれ取得できます。これらのクラスのインスタンスの取得方法については、SharpLab. – 中まで見よう！Windows Live Writerというエントリに書きましたのでそちらを参照してください。

WP-XML-RPC APIの情報の集め方

WordPressをXML-RPCで操作していると述べましたが、WordPressにはmetaWeblog APIを拡張したWP-XML-RPC APIがあり、これを使用しています。metaWeblog APIについてはMovableType で使える XML-RPC APIというページが詳しいです。WordPressが独自に拡張した部分についてはXML-RPC wp « WordPress Codexに纏まっています。

ただ、これだけでは残念ながらWordPressのXML-RPCについて網羅しきれていません。最近新しく追加された機能などについて調べる場合はwp-xmlrpc Info PageからMLのアーカイブをさらう必要があります。

それでも良く分からなかったら？幸いWordPressはOSSです。ソースコードを読みましょう。その際、便利なのがこちら、PHPXref 0.7: WordPress (latest release)。PHPXrefというツールで、クロスリファレンス化したWordPressのソースコードが掲載されています。

WP-XML-RPC APIによるカスタムフィールドの扱い方

[wp-xmlrpc] exposing and manipulating custom fieldsに記述があります。大体分かり易い記述ですが、ちょっと躓くところがあったので記しておきます。以下の部分。

If a custom field entry included with a post contains an "id" value then an update is done. If there is no "id" then an add is done. If there is an "id" value and no "key" value then the custom field with that id is deleted.

「なになに…idがなければ新しいカスタムフィールドとして追加され、idはあってもkeyがなければそのカスタムフィールドは削除されるとな？」と理解し、追加したい場合はidに空文字列を持たせる形で実装を進めたのですが、うんともすんとも動かない。カスタムフィールドを削除しようと思ってkeyに空文字列を渡した場合には空文字列をキーにしたカスタムフィールドが出来てしまうという始末。（管理画面からは空文字列をキーにすることは出来ないのでバグでしょう。）

実はno idという状態とはidの値を空にしろ、という意味ではなく、idというメンバ自体を持たせるな、ということでした。今振り返ってみて素直に読めば確かにその方が読んでいて通りが良いですが、なんだかなー、もーちょっとわかりやすくしてくれよ、と思いました、はい。

アンダーバーで始まるフィールド

SharpLab. – WPCustomFieldsEditor制作中というエントリにも書いたのものですが。

WordPressの管理画面からは見えないのですが、WP-XML-RPC API経由だと_edit_last、_edit_lockや、_encloseme、_pingmeなどの謎のカスタムフィールドが見える場合があります。これらアンダーバーでキー名が始まるカスタムフィールドですが、結局ググってもよくわからなかったので、WPCustomFieldsEditorでは一律無視することにしています。従って、ユーザーがアンダーバーでキー名が始まるカスタムフィールドを作成した場合も巻き添えで無視されてしまうので、運用には十分注意してください。

Windows Live WriterにWordPressのカスタムフィールド編集機能を追加するプラグインです。カスタムフィールドはエントリに独自のメタデータを付加したい場合のために確保されたフィールドで、WordPressをCMSとして多少手の込んだサイト管理に使用する場合には非常に重宝する機能です。このプラグインでは、エントリに付加するカスタムフィールドを、投稿時に編集する機能をWindows Live Writerに提供します。

ダウンロード

WPCustomFieldsEditor.zip

動作環境

• Microsoft Windows XP SP2 以降または Windows Vista（Windows Live Writerに準拠）
• Microsoft .NET Framework 2.0以上
• Windows Live Writer Beta（Build14.0.5025.904)
• WordPress 2.5以上

※現在、Writer Zoneで配布されているTechnical Preview版では、おそらく動作しなくなっています。ご注意ください。

インストール方法

ダウンロードしたファイルを展開してsetup.exeを実行してください。

アンインストール方法

コントロールパネルのプログラムの追加と削除からWPCustomFieldsEditorを選択し削除してください。

操作説明

エントリの投稿を行うと、スプラッシュウィンドウに続いてカスタムフィールドの編集画面が現れます。この画面からカスタムフィールドの追加・削除・編集を行うことが出来ます。

更新履歴

• 2008-10-01 ver.1.03に差し替え。内部動作を変更。
• 2008-09-20 ver.1.02に差し替え。WLW Beta(Build14.0.5025.904)に対応。
• 2008-08-13 Blogシステムの判別ミスがあったのでver.1.01に差し替え
• 2008-08-13 イニシャルリリース

WordPressのカスタムフィールドをWindowsLiveWriterから編集するためのプラグインを製作中。プラグインの形式はpublish notification hooksプラグイン。とりあえずXML-RPCを使って記事に付加されたカスタムフィールドの一覧を取得するところまで漕ぎ着けた。ちなみにXML-RPCでWordPressを操作する際に必要となるID、PasswordにはSharpLab. – 中まで見よう！Windows Live Writerというエントリで紹介した方法を使用してWLWが内部に保持している情報を取得して使っています。エンドポイントURLも確かBlogクラスあたりのメンバにあったのを使用。

さて、ここまででカスタムフィールドの仕様に関して気づいたことが何点か。

• _edit_last、_edit_lockや、_encloseme、_pingmeなどの謎のカスタムフィールドがWordPressによって勝手に追加されている。アンダーバーが付いているカスタムフィールドはWordPressによって自動的に追加されたもの？ちなみにこれらはWordPressの管理画面からは不可視。
• カスタムフィールドのキーは一意である必要はない。キーとは別にidが振られており、それで管理が行われている。（参考：[wp-xmlrpc] exposing and manipulating custom fields）

来週暇なんで作業が進むといいなー。

「SharpLab. – publish notification hooksでpost内容を安全に書き換えるには」のコメント欄を受けて、「サーバーに修正後のエントリをアップ、そのアップされたエントリをWLWでDLして再読み込み」という方法を試してみた。

        public override bool OnPrePublish(System.Windows.Forms.IWin32Window dialogOwner, IProperties properties, IPublishingContext publishingContext, bool publish) {

            PostEditorForm postEditorForm = getPostEditorForm(dialogOwner);
            Blog blog = new Blog(postEditorForm.CurrentBlogId);

            //publishingContextからリフレクションでBlogPostEditingManagerを取得
            FieldInfo editingContextFieldInfo = publishingContext.GetType().GetField("_editingContext", BindingFlags.NonPublic | BindingFlags.Instance);
            BlogPostEditingManager manager = (BlogPostEditingManager)editingContextFieldInfo.GetValue(publishingContext);

            PropertyInfo localFilePropertyInfo = manager.GetType().GetProperty("LocalFile", BindingFlags.NonPublic | BindingFlags.Instance);
            PostEditorFile postEditorFile = (PostEditorFile)localFilePropertyInfo.GetValue(manager,null);

            BlogPost blogPost = (BlogPost)publishingContext.PostInfo; ;
            blogPost.Title = "test";
            return true;
        }

このようにOnPrePublishメソッド内では投稿内容の書き換えだけを行って、

        public override void OnPostPublish(IWin32Window dialogOwner, IProperties properties, IPublishingContext publishingContext, bool publish) {

            PostEditorForm postEditorForm = getPostEditorForm(dialogOwner);
            Blog blog = new Blog(postEditorForm.CurrentBlogId);

            //publishingContextからリフレクションでBlogPostEditingManagerを取得
            FieldInfo editingContextFieldInfo = publishingContext.GetType().GetField("_editingContext", BindingFlags.NonPublic | BindingFlags.Instance);
            BlogPostEditingManager manager = (BlogPostEditingManager)editingContextFieldInfo.GetValue(publishingContext);
            BlogPost blogPost = blog.GetPost(publishingContext.PostInfo.Id, publishingContext.PostInfo.IsPage);
            manager.EditPost(new BlogPostEditingContext(postEditorForm.CurrentBlogId, blogPost));
        }

OnPostPublishメソッド内で記事の再読み込みを行うというやり方でテスト。

YATTA!この場合だと、画像が消えてしまうことなく、書き換え内容を投稿画面に反映することが出来た。だが一方で、「Smart Content」部を選択しても、右のように"Selected item cannot be edited."というメッセージが出て、編集出来なくなるという問題が。また、画像も良く見てみると、ローカル画像という扱いではなく、Web画像という扱いになってしまっている。つまりこの方法ではWindows Live Writerがローカルに保存した記事についての情報（.wpost拡張子でMy Weblog Posts以下に保存されている奴）を利用出来ていないようだ。なかなか難しいな…。このやり方でのOnPrePublishメソッド部のみ実行し、その後手動でサイドバーのRecently Postedの一覧の中から投稿したエントリを選択するというやり方なら、上手くマージされた状態で読み込め、「Smart Content」部も再編集可能なので、どこかに方法はあるはずだとは思うのだが…。

ひとつ前のエントリ（中まで知ろう！Windows Live Writer）で、Windows Live Writerの、SDKには載っていないクラスを色々と紹介しました。その内容をうけて、このエントリではPublish Notification Hook プラグインで、投稿前に記事内容を書き換える方法を紹介したいと思います。以前にも、SharpLab. – publish notification hooksでpost内容を書き換えるにはというエントリでpublish notification hooksプラグインで投稿内容を書き換える方法を紹介したことがありました。ですが、

WLW 自体は書き換えられることを想定してないので、プラグインから書き換えても投稿後にエディタ中の表示は変化しません。

Publish Notification Hook プラグイン 値の書き換え-katamari.wankuma.com

というJZ5さんの検証エントリの通り、投稿後の画面がおかしくなる問題がありました。今回の方法ではその回避を図っています。

とりあえずソースコードを示します。

using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;
using System.Windows.Forms;
using WindowsLive.Writer.Api;
using WindowsLive.Writer.BlogClient;
using WindowsLive.Writer.BlogClient.Clients;
using WindowsLive.Writer.PostEditor;
using WindowsLive.Writer.Extensibility.BlogClient;

using WriterMshtml = WindowsLive.Writer.Mshtml;

namespace SharpLab.WPCustomFieldsEditor {
    [WriterPlugin("0aaad6ce-da8b-4f78-a73c-c73f3c6c163d", "WPCustomFieldsEditor", PublisherUrl = "http://www.sharplab.net/")]
    public class PublishObserver : PublishNotificationHook {
        public override bool OnPrePublish(System.Windows.Forms.IWin32Window dialogOwner, IProperties properties, IPublishingContext publishingContext, bool publish) {

            PostEditorForm postEditorForm = getPostEditorForm(dialogOwner);
            Blog blog = new Blog(postEditorForm.CurrentBlogId);

            //publishingContextからリフレクションでBlogPostEditingManagerを取得
            FieldInfo fieldInfo = publishingContext.GetType().GetField("_editingContext", BindingFlags.NonPublic | BindingFlags.Instance);
            BlogPostEditingManager manager = (BlogPostEditingManager)fieldInfo.GetValue(publishingContext);
            BlogPost blogPost = (BlogPost)publishingContext.PostInfo;

            blogPost.Title = "test";//エントリ内容への操作

            manager.EditPost(new BlogPostEditingContext(postEditorForm.CurrentBlogId, blogPost));

            return true;
        }

        private PostEditorForm getPostEditorForm(IWin32Window postProgressForm) {
            return (PostEditorForm)((Form)Form.FromHandle(postProgressForm.Handle)).Owner;
        }
    }
}

細かく見ていきましょう。

            PostEditorForm postEditorForm = getPostEditorForm(dialogOwner);

この行ではPostEditorFormクラスのインスタンスを取得しています。前エントリ参照。

           Blog blog = new Blog(postEditorForm.CurrentBlogId);

この行ではBlogクラスのインスタンスを取得しています。前エントリ参照。

            FieldInfo fieldInfo = publishingContext.GetType().GetField("_editingContext", BindingFlags.NonPublic | BindingFlags.Instance);
            BlogPostEditingManager manager = (BlogPostEditingManager)fieldInfo.GetValue(publishingContext);

ここでは、BlogPostEditingManagerクラスのインスタンスを取得してます。OnPrePublishメソッドの引数として渡されたpublishingContextにはBlogPostHtmlEditorクラス（WindowsLive.Writer.PostEditor.PostHtmlEditing名前空間に所属）のインスタンスが格納されており、その_editingContextというパブリックでないフィールドにBlogPostEditingManagerが格納されています。BlogPostHtmlEditorクラス自体もパブリックなクラスではないので、ここではリフレクションで取得しています。なお、BlogPostEditingManagerクラスはエントリを編集画面に読み込んだり、削除したりできるクラスです。正直、自分も良く分かっていません(笑)。

            BlogPost blogPost = (BlogPost)publishingContext.PostInfo;

ここでは編集対象のエントリを表すBlogPostクラスのインスタンスを取得しています。前エントリ参照。

            blogPost.Title = "test";//エントリ内容への操作

エントリ内容への書き換えをここで行うことが出来ます。この例ではタイトルの書き換えをしています。試したわけではありませんが、カテゴリや概要に対して変更を加えることもできる筈です。

            manager.EditPost(new BlogPostEditingContext(postEditorForm.CurrentBlogId, blogPost));

そして、書き換えた後の大事な後始末、書き換えたエントリのPostEditorEormへの再読み込みをここで行っております。BlogPostEditingManagerクラスのEditPostメソッドに、それっぽい引数を与えて呼び出せば読み込んでくれるようです。

で、このエントリでは、ここ数日オブジェクトブラウザを通じてWindows Live WriterのDLL群とにらめっこした結果わかった、SDKに載っていない本体の内部構造の話をしてみようかと。Windows Live Writerの中にどんなクラスがあるかや、どうやってそのインスタンスをプラグイン側から取得するかのお話。

Windows Live WriterのメインFormの取得方法

何はなくとも、記事編集画面が無ければ始まらない。Windows Live Writerの記事編集画面のFormのインスタンスをプラグインから取得する方法から説明を始めます。プラグインが呼び出された時に呼ばれるメソッドのうちいくつかは、dialogOwnerという、System.Windows.Forms.IWin32Window型の引数を持っています。このdialogOwnerという引数が今回のカギとなります。読んでの通り、dialogOwnerは親Formを示しており、SmartContentSource.CreateContentメソッドなら、記事編集画面のForm、PublishNotificationHook.OnPrePublishメソッドやOnPostPublishメソッドなら投稿中のプログレス表示を行うFormとなります。

        private PostEditorForm getPostEditorForm(IWin32Window postProgressForm) {
            return (PostEditorForm)((Form)Form.FromHandle(postProgressForm.Handle)).Owner;
        }

PublishNotificationHookの方から取得できるdialogOwnerからメインFormのインスタンスを取得したいならば、上記のようなメソッドを用意して取得すればOK。見ての通り、メインFormのクラス名はPostEditorFormで、WindowsLive.Writer.PostEditor名前空間に所属しているクラスです。今後は記事編集画面のFormのことはPostEditorFormと呼ぶことにします。

Blogクラスのインスタンスの取得

さて、前の項で取得できたPostEditorFormクラスには、CurrentBlogIdというプロパティがあります。このプロパティには、Windows Live Writerで管理しているBlogを識別するためのGUIDが入っており、これを基に現在編集対象としているBlogを表すBlogクラスのインスタンスを取得可能です。こんな感じに。↓

            Blog blog = new Blog(postEditorForm.CurrentBlogId);

BlogクラスはWindowsLive.Writer.BlogClient名前空間に所属しているクラスで、メンバには記事の取得や投稿に関するメソッドなど、Blogに関する様々な操作を実現するメソッドやプロパティが含まれています。Blogクラスをオブジェクトブラウザで表示したもののSSを示しましたが、サイズの関係でSSに写っていないものもたくさんあるので、是非自分で確かめてみてください。

BlogClientクラスのインスタンスの取得

ところでBlogクラスには、パブリックではないプロパティとしてBlogClientというプロパティがあります。このプロパティには、IBlogClient（WindowsLive.Writer.Extensibility.BlogClient名前空間に所属）というインターフェイスを実装したクラスのインスタンスが含まれています。一例を挙げると、WordPressClientクラスや、MovableTypeClientクラス、WindowsLiveSpacesClientクラス（全てWindowsLive.Writer.BlogClient.Clients名前空間に所属）などです。これらにはUsernameや、Passwordというプロパティが含まれており、自前でXML-RPCを使ってサーバーとやり取りしたい場合などに活用できます。（WordPressはMetaWeblobAPIの拡張に熱心であるので、Windows Live Writerが対応していない機能もあり、意外と使いたくなる場面があるものです）

publishingContext.PostInfoの実体

PublishNotificationHook.OnPrePublishメソッドやOnPostPublishメソッドのpublishingContextという引数には、PostInfoというIPostInfo型のプロパティがあるのは御存知だと思います。以前自分はこのプロパティに格納されているインスタンスの、IPostInfoインターフェイスでは読み取り専用になっているプロパティに対してリフレクションで値をセットするコードがなぜ動くのかが分からないとかぼやいていました。

調べてみたところ、リフレクションでアクセスするのは、参照するのに使われたインターフェイスのメンバではなく、インスタンスのメンバだから、ということのようです。用語法をあまり理解できていないので、おかしな説明になっているかもしれません。要するに、PostInfoに対してリフレクションでアクセスできるのは、IPostInfoインターフェイスのメンバだけではなく、BlogPostクラスのメンバなのだ、ということです。これなら前のエントリのpi.CanWriteの部分がtrueを返すのも納得できます。

まぁとりあえずpublishingContext.PostInfoにはBlogPostクラスのインスタンスが入っているということです。そこで、こんな感じにキャストしてやると、

            BlogPost blogPost = (BlogPost)publishingContext.PostInfo;

よりエントリの情報を詳細に得ることができるようになります。投稿スラッグや概要（Excerpt）、投稿日時を表すっぽいプロパティもあるので、チェックしてみてはいかがでしょうか。

次のエントリでは、これらを利用して、Publish Notification Hook プラグインで、投稿前に記事内容を書き換える方法を紹介したいと思います。プラグインからの書き換え後、エディタ中の表示が変化しない問題を解決するために、エントリを管理しているクラスの説明も少しだけします。

表示モードを「HTMLコード」としていた場合、HTMLDocumentに対してプラグインから操作後に表示モードを「標準」に戻すと、HTMLDocumentに対する操作内容が飛んでしまう

という問題で躓いていたが、HTMLDocumentに対して操作を行う前に表示モードを「標準」にしておくことで対処できた。

こんな感じ。HTMLDocumentを直接操作できるようになって、うはー 夢が広がりんぐ

なお、表示モードの切り替えがタブ式になったTechnology Preview版限定。

using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;
using System.Windows.Forms;
using WindowsLive.Writer.Api;
using WindowsLive.Writer.BlogClient;
using WindowsLive.Writer.BlogClient.Clients;
using WindowsLive.Writer.PostEditor;
using WindowsLive.Writer.Extensibility.BlogClient;

using WriterMshtml = WindowsLive.Writer.Mshtml;

namespace SharpLab.WPCustomFieldsEditor {
    [WriterPlugin("0aaad6ce-da8b-4f78-a73c-c73f3c6c163d", "WPCustomFieldsEditor", PublisherUrl = "http://www.sharplab.net/")]
    public class PublishObserver : PublishNotificationHook {
        public override bool OnPrePublish(System.Windows.Forms.IWin32Window dialogOwner, IProperties properties, IPublishingContext publishingContext, bool publish) {

            PostEditorForm postEditorForm = getPostEditorForm(dialogOwner);

            WindowsLive.Writer.Controls.MiniTabsControl MiniTabsControl = (WindowsLive.Writer.Controls.MiniTabsControl)findControlByName(postEditorForm, "MiniTabsControl", "WindowsLive.Writer.Controls");
            MiniTabsControl.SelectTab(0);

            WriterMshtml.MshtmlEditor mshtmlEditor = (WriterMshtml.MshtmlEditor)findControlByName(postEditorForm, "MshtmlEditor", "WindowsLive.Writer.Mshtml");
            mshtml.IHTMLDocument2 doc = mshtmlEditor.HTMLDocument;
            //あとは煮るなり焼くなり。
        }

        private PostEditorForm getPostEditorForm(IWin32Window postProgressForm) {
            return (PostEditorForm)((Form)Form.FromHandle(postProgressForm.Handle)).Owner;
        }

        private Control findControlByName(Control control, string controlName, string controlNamespace) {

            foreach (Control cChild in control.Controls) {

                Type t = cChild.GetType();

                if (t.Name == controlName && t.Namespace == controlNamespace) {
                    return cChild;
                }

                if (cChild.HasChildren) {
                    Control returned = findControlByName(cChild, controlName, controlNamespace);
                    if (returned != null) {
                        return returned;
                    }
                }
            }

            return null;
        }
    }
}

XML-RPC is disabled by default for new installs of WordPress. Upgrading will NOT disable XML-RPC (ticket 7157)

WordPress 2.6 – XML-RPC & AtomPub Changes – Joseph Scott’s Blog

このエントリには他にもXML-RPC APIのver.2.51からの変更点（ページテンプレートの取得、Blogオプションの取得/設定が出来るようになった、等）が列挙されているので、このエントリは一見の価値有り。

また、このBlogにはこんな記事もあった。

Custom fields for posts and pages are now exposed and manageable from metaWeblog.getPost/newPost/editPost, wp.getPage/newPage/editPage via the custom_fields field. I was really happy to get this in, I think there is a lot of potential in being able to manage custom fields externally.

WordPresss 2.5 – Joseph Scott’s Blog

WordPress 2.5からはカスタムフィールドのデータをXML-RPC APIから扱えるようになっていたらしい。知らんかった。憶えておこう。

こんな感じに比較が出来る。うん、良い感じ。

次に、WindowsLiveWriterを使用して投稿をした場合を試してみた。

これもうまくいく。

だが、WordPressの投稿フォームとWindowsLiveWriterを併用して編集した場合はうまく比較が行われない。

WordPressで編集した版はpタグで括られた段落毎にブロックに分けられているのだが、WLWで編集した版は全体が一つのブロックとして纏められてしまっており、それが原因で比較に失敗しているようだ。

一人でBlogを書く際には過去の版に戻す位しかリビジョン管理機能を使うことはないだろうから、あまり影響はないだろうけど、ビジネスブログなどで複数人で記事を推敲する場合はリビジョン比較機能を使う場面も出てくるだろう。そういう場合は投稿クライアントを使うか使わないか統一した方がよさそうだ。（まぁ大した問題じゃないが…。）

さて、その紹介頂いたInsertableContentSource: New Writer Plugins Using The New SDKというエントリは、CTP版の新SDKを使って作られたプラグインを紹介するエントリなのだが、その中で参考になるのは「ScottIsAFool.WriterUtilities」というセクション。エントリの中で紹介されているプラグインを実装するのに使われた、エントリ内容書き換え用のユーティリティクラス（WriterUtilsクラス）の使い方を紹介している。このクラスのソースコードもCodePlexにあげられていたので、以下に抜粋して引用する。

namespace ScottIsAFool
{
    public static class WriterUtils
    {
        public static bool ReplaceText(IPostInfo postInfo, string value, PostItems item)
        {
            PropertyInfo[] propInfos = postInfo.GetType().GetProperties(BindingFlags.Public | BindingFlags.Instance);
            foreach (PropertyInfo pi in propInfos)
            {
                if (pi.Name == item.ToString() && pi.CanWrite)
                {
                    pi.SetValue(postInfo, value, null);
                    return true;
                }
            }
            return false;
        }
    }
}

New Live Writer Plugins (SDK: 1.1)

…何と反応していいのか分からない素敵なnamespace名は措いておくとして。

要するに渡されたIPostInfo型の引数に対して、リフレクションで無理矢理プロパティに値をセットしているようだ。しかし、リフレクションについてよくわかっていないのだが、何で読み取り専用プロパティであるIPostInfoのメンバに値をセットするようなことが出来るのだろう？読み取り専用プロパティである限り、pi.CanWriteの部分は常にfalseを返すのではないのか？ようわからん。

さて、現在のInvalidSourceModifierは以下のようなソースになっている。

extern alias MicrosoftMshtml;
extern alias WriterInteropMshtml;

using System;
using WindowsLive.Writer.Api;
using System.Windows.Forms;
using MicrosoftMshtml.mshtml;
using WindowsLive.Writer.PostEditor;

using WriterMshtml = WindowsLive.Writer.Mshtml;

namespace InvalidSourceModifier {
    //TODO:ImagePathの設定！
    [WriterPlugin("9388e56b-c684-4e04-b7f6-b8cc224d70b2", "InvalidSourceModifier", PublisherUrl = "http://www.sharplab.net/")]
    public class InvalidSourceModifier : PublishNotificationHook {
        public override bool OnPrePublish(System.Windows.Forms.IWin32Window dialogOwner, IProperties properties, IPublishingContext publishingContext, bool publish) {

            PostEditorForm postEditorForm = getPostEditorForm(dialogOwner);
            WriterMshtml.MshtmlControl mshtmlControl = (WriterMshtml.MshtmlControl)findControlByName(postEditorForm, "MshtmlControl", "WindowsLive.Writer.Mshtml");

            IHTMLDocument3 doc = (IHTMLDocument3)mshtmlControl.HTMLDocument;

            IHTMLElementCollection allElement = doc.getElementsByTagName("*");
            foreach (IHTMLElement elem in allElement) {
                object align = elem.getAttribute("align", 0);
                object border = elem.getAttribute("border", 0);
                if (!(align == null || align is DBNull)) {
                    elem.removeAttribute("align", 0);
                    elem.style.styleFloat = (string)align;
                }
                if (!(border == null || border is DBNull)) {
                    elem.removeAttribute("border", 0);
                    elem.style.borderWidth = (string)border;
                }
            }

            updateTextEditorControl(postEditorForm);

            return true;
        }

        private void updateTextEditorControl(PostEditorForm postEditorForm) {

            WriterMshtml.MshtmlEditor mshtmlEditor = (WriterMshtml.MshtmlEditor)findControlByName(postEditorForm, "MshtmlEditor", "WindowsLive.Writer.Mshtml");
            mshtmlEditor.Focus();

            Control test = findControlByName(postEditorForm, "PostEditorMainControl", "WindowsLive.Writer.PostEditor");

        }

        private PostEditorForm getPostEditorForm(IWin32Window postProgressForm) {
            return (PostEditorForm)((Form)Form.FromHandle(postProgressForm.Handle)).Owner;
        }

        private Control findControlByName(Control control, string controlName, string controlNamespace) {

            foreach (Control cChild in control.Controls) {

                Type t = cChild.GetType();

                if (t.Name == controlName && t.Namespace == controlNamespace) {
                    return cChild;
                }

                if (cChild.HasChildren) {
                    Control returned = findControlByName(cChild, controlName, controlNamespace);
                    if (returned != null) {
                        return returned;
                    }
                }
            }

            return null;
        }

    }

}

まず、getPostEditorFormメソッドで投稿の進捗状況を表すプログレスバーを載せたFormを基に、親のPostEditorFormを取得、その後、findControlByNameメソッドを使い、PostEditorForm内から、nameとnamespaceを頼りにMshtmlControlコントロールを探し、そのHTMLDocumentプロパティから取得する、というやり方。

これでめでたく「標準」モードや、「Webプレビュー」モードのHTMLDocumentオブジェクトが習得できるのだけれども、HTMLDocumentオブジェクトに対して操作を加えると、「HTMLコード」画面での内容と、HTMLDocumentの不整合が起きてしまう。特に、表示モードを「HTMLコード」としていた場合、HTMLDocumentに対してプラグインから操作後に表示モードを「標準」に戻すと、HTMLDocumentに対する操作内容が飛んでしまう。

む～。なんとかならんものか。誰か知恵をお貸しくださいませ。

一方、publish notification hooksプラグインの中で、OnPrePublishメソッドに渡されるdialogOwnerを使ってFindTridentFromLWParentメソッドを呼び出す場合は工夫が必要。OnPrePublishメソッドで渡されるdialogOwnerは、Live Writerのメインウィンドウではなく、投稿中に表示されるプログレスウィンドウなので、_FindTridentFromLWParentメソッドの代わりに、

        private IHTMLDocument2 _FindTridentFromProgressForm(IWin32Window progressForm) {
            Form writerMainForm = ((Form)Form.FromHandle(progressForm.Handle)).Owner;
            return _FindTridentFromControl(writerMainForm);
        }

以上のようなメソッドを作って、FindTridentFromControlメソッドを呼び出す必要がある。

これまでWindowsLive.Writer.Api.IPostInfo.Contentsプロパティに収められている投稿内容を正規表現で書き換えようとしてきたのだが、IHTMLDocument2オブジェクトが扱えるならば、ずっとスマートに色々なことが出来るようになりそうだ。

publish notification hooksを使ったプラグインを作ってみようということで、LiveWriterの出力するソースを投稿時に書き換えるプラグイン（InvalidSourceModifier）をつくることにした。

とか言って実際に作っていたのだけれども、いざ形になってきてコンパイルしてみると、

エラー    1    プロパティまたはインデクサ ‘WindowsLive.Writer.Api.IPostInfo.Contents’ は読み取り専用なので、割り当てることはできません。

というオチ。OnPrePublishメソッドをオーバーライドすれば投稿前にコンテンツの中身を書き換えられるという訳じゃなかったんかい！勘違いでした…。

どーするかなー。後はhookする対象をOnPostPublishメソッドに変更したうえで、投稿後直ぐXML-RPCで直接WordPress上のコンテンツを書きかえる位しかやりようがないかな･･･。つうかそれならWordPressのプラグインをPHPで書いた方が早いか(笑)

using System;
using System.Collections.Generic;
using System.Text;
using WindowsLive.Writer.Api;

namespace InvalidSourceModifier {
    //TODO:ImagePathの設定！
    [WriterPlugin("9388e56b-c684-4e04-b7f6-b8cc224d70b2", "InvalidSourceModifier", PublisherUrl = "http://www.sharplab.net/")]
    public class InvalidSourceModifier : PublishNotificationHook {
        public override bool OnPrePublish(System.Windows.Forms.IWin32Window dialogOwner, IProperties properties, IPublishingContext publishingContext, bool publish) {
            //publishingContext.PostInfo.Contents
            System.Windows.Forms.MessageBox.Show("test");
           return true;
        }
    }
}

…まだこれだけだけど。

さて、実際にコンパイルしてLiveWriterに登録してみると、SDKに付属していたNew SDK Features.docの以下の記述通り、

Unlike content source plugins, publish notification hooks can be enabled or disabled by the user on a per-blog basis. The first time a publish operation occurs for a particular blog since a publish notification hook was installed, the user will be asked if the hook should be enabled or disabled for that blog.

New SDK Features.doc

Blog別にプラグインの有効/無効が管理されているのが確認できた。上手く出来てるなー。ちょっとしたことだけど、これは便利だ。

Windows Live Writer Technical Preview をインストールしてみた。UIなどをちょくちょく改良されている。でも生成されるソースは相変わらず綺麗じゃないなー。様々なBlogサービスに対応するためとはいえ、もう少しなんとかならないのか。トリミングは便利そうだ。でも英語ではTrimではなくcropという語を使うんだね…。Trimは文字列を切り詰める場合などに限られるのかな？

さぁて、publish notification hooksを使ったプラグインを作ってみるか。

また、Windows Live Writer SDKもver.1.1に。ヘッダ・フッタを付加するプラグインが出たそうだけれども、WordPressを使っている自分にはあまり関係がなさそうか。投稿の前後に起動させられるプラグインは色々使い道がありそうだ。

さて読んでいて気づいた機能として、HtmlScreenCapture Classを使ったSSの取得機能と、Making Content Resizableで解説されているSmart Contentにリサイズ機能がある。この二つの機能はgihyo.jpでの記事で紹介されていないので、目を通しておくとよいかと思われる。ちなみに、HtmlScreenCapture Classについては、タイトルからは想像が行かないが、Embedding a Media Playerというドキュメントの中で活用法が紹介されている。

さて、ここまでエントリを書きあげたところで気づいたのだが、

「Windows Live」APIのマニュアルを日本語化-ITmedia News

というニュースが。なんですとー！？折角英語で読んだのに、丁度今日翻訳記事が公開されたそうな。何だったんだ自分の努力は…。

追記：
と思いきやLive Writer APIのドキュメントは翻訳されていなかった。良かった良か…ねえよ。どうせなら翻訳してほしいものだ。

結構簡単そうだなー。IEのツールバーをC#で作るよりはずっと。Content Source Plugin APIというものを使えばいいらしい。@itにGoogle Deskbarのマネージドプラグインを作成する方法の記事があったけど、それと同じ感覚で出来そう。このBlogもWordPress+WindowsLiveWriterで運用しているし、今度試してみよう。

ところでこの記事はContent Source Plugin APIを利用したプラグインについての解説だけれども、WLWには他にもWindows Live Writer Application APIや、Windows Live Writer Provider Customization APIというAPIも用意されているらしい。その機能はリンク先のMSDNによれば、以下の通り。

Windows Live Writer includes an application API that external applications can use to launch Writer in order to create new posts, to open existing posts, and to support "Blog This" operations for various content types including links, snippets, images, and feed items.

application APIは外部プログラムから記事を投稿したり編集したり、"Blog This" operations？なるものをサポートするためにWLWを使用するためのAPIということか。Windows Live ToolbarはIEで表示中のページから引用文として取り込みながらWLWを立ち上げられると聞くが、このAPIを使用しているのだろう。

Beta Two of Windows Live Writer introduces a set of APIs which can be used by weblog providers to customize both the capabilities of Writer as well as add new capabilities to the Writer user-interface. Available customizations include:

• Defining the subset of weblog features supported by the weblog. This allows providers to implement any subset of the core XML-RPC based weblog APIs (Metaweblog, Movable Type, or Wordpress) and have Writer’s UI correctly respect this subset.
• Provide the correct URL entry points for viewing and managing the weblog as well as editing posts online.
• Define a custom icon and watermark image that appears in the Writer Sidebar
• Define custom buttons that can link to web-pages, display content in a drop-down, and notify the users of new content and other online activity.
• Define WYSIWYG editing templates for the active weblog theme.

んー、Provider Customization APIは、Blogサービス提供者が自分の提供するサービスと適合するようにWLWをカスタマイズするためのAPIということなのかな？このAPIをうまく使ってやれば、アカウントセットアップ時に右図のように表示されるサービスの一覧に自分のサービスを追加できるのだろう。多分。

ということで、Content Source Plugin APIとApplication APIは大分使えそうな印象。あー、Sleipnirがプラグイン作成用SDKを公開してくれていれば、すぐにでもApplication APIを使用して引用記事を書くプラグインを作るのに。