Friendly.Windows.NativeStandardControls2.5.0をリリースしました

Win32(MFCも含む)用のNativeStandardControlsに3年ぶりくらいに機能追加です。
メニューのユーティリティを追加しました。

NativeMenuItem

こんな感じで使います。

[TestMethod]
public void SampleWindowMenu()
{
    var app = new WindowsAppFriend(Process.Start(TargetPath.NativeControls));
    var main = WindowControl.FromZTop(app);

    //ウィンドウの持っているメニューから検索
    var b0 = NativeMenuItem.GetMenuItem(main, "B0");
    //クリックエミュレート
    //これは Friendly.Windows.KeyMouse の拡張メソッド
    b0.Click();

    //押すとポップアップが表示されるのでそこから取得
    var b01 = NativeMenuItem.GetPopupMenuItem(app, "B0-1");
    b01.Click();

    //さらにその先
    var b011 = NativeMenuItem.GetPopupMenuItem(app, "B0-1-2");
    b011.Click();
}

[TestMethod]
public void SampleContextMenu()
{
    var app = new WindowsAppFriend(Process.Start(TargetPath.NativeControls));
    var main = WindowControl.FromZTop(app);

    //右クリック
    main.Click(MouseButtonType.Right, 100, 100);

    //コンテキストメニューから
    var a00 = NativeMenuItem.GetPopupMenuItem(app, "A0-0");
    a00.Click();
}

有効無効とIdも取得できます。WM_COMMANDを使ってメッセージを送ることも可能です。

[TestMethod]
public void SampleSendMessage()
{
    var app = new WindowsAppFriend(Process.Start(TargetPath.NativeControls));
    var main = WindowControl.FromZTop(app);
    main.Click(MouseButtonType.Right, 5, 5);
    var p0 = NativeMenuItem.GetPopupMenuItem(app, "A0-0");

    //p0.Click();
    //ほとんどの場合はClickで問題ない
    //内部的に対象プロセスがタイマメッセージを拾えるようになるまで待つので
    //発生するイベントの完了を待ち合わすことができる

    //そのイベント内部で自分でメッセージループ回したりするような場合は、イベントの終了を待てない
    //そのような場合はこちらが同期をとりやすい
    if (p0.Enabled)
    {
        const int WM_COMMAND = 0x111;
        main.SendMessage(WM_COMMAND, new IntPtr(p0.Id), IntPtr.Zero);
    }

    //それからモーダルダイアログが表示される場合は抜けてくるが
    //その場合は表示されるダイアログの完了をまてば問題なく同期がとれる場合が多いが
    //変わった処理がされている場合は上記をasyncを渡して対応するとよい
}

ちなみにFriendlyの提供するSendMessageは特殊で、対象のスレッドでSendMessageを実行させるという方式になっています。別スレッド（プロセス）からSendMessageすると想定外のタイミング（対象スレッドが特定のAPI使っている最中に割り込むとか）で割り込んでトラブルが発生する場合があるからです。ダイアログが出てくる場合などはSendMessageなのに非同期で実行できます。これは対象のプロセスにSendMessageを実行させる箇所を非同期にしています。その処理が完了することはasyncオブジェクトで監視することができます。

var async = new Async();
main.SendMessage(WM_COMMAND, new IntPtr(p0.Id), IntPtr.Zero, async);

var dlg = main.WaitForNextModal();
dlg.Close();

//発生するイベントの完了を確実に待ち合わすことができる
async.WaitForCompletion();

必要？

そうなんですよ。テスト自動化用なんでIDも送信先のウィンドウもわかってるんです。実行するにはなくても良いのです。

なんで作った？

SendMessageでWM_COMMANDを送るのは確実に動作して良いのですが、逆に言えばどんな時でも実行できてしまうというのもあります。メニューが存在してなかったり、無効だったりした場合でも実行できてしまうのです。実はネイティブアプリの場合は、ここは手動でやってもらったり、別口をDLL公開関数で作ってもらったりで対応してました。あと、この方針はキーマウスエミュレートと組み合わせて使うので去年まではあんまり推奨してなかったのですよね。でも、去年キーマウスエミュレートでも同期のとれる方法を思いついて、ちょくちょく使ってるのでこちらも頑張ってみるかという流れです。

おまけ

さっきのSendMessageはこんな感じで書きたいですよね。

//これ相当のことを一発でやりたい
//if (p0.Enabled)
//{
//	main.SendMessage(WM_COMMAND, new IntPtr(p0.Id), IntPtr.Zero);
//}
p0.Execute();

それでこれをやるためにはメニューハンドルから送信先のウィンドウハンドルを引っ張ってくる必要があるのですが、(もちろん p0.Execute(main) とか引数付けたらいいんですけど、それはイマイチなのでやりたくない）でもちょっと調べた感じではメニューハンドルから送信先のウィンドウハンドルを逆引きするAPIはないようです。
それでも、@Tocchannさんに聞いたところフックしてWM_INITMENUPOPUPを見張ればいいんじゃない？とのご意見をいただいたのでやってみました。（その他ご意見いただいた@HappyLuckyAkiraさん、@yoshiomsさん、@Fujiwoさんもありがとうございます！）
Friendlyを使うとフックもこんなに簡単に書けちゃうんですよー。

[TestMethod]
public void GetLastPopupOwnerSample()
{
    //dllインジェクション
    app.LoadAssembly(GetType().Assembly);
    //フックするクラスを対象プロセス内部に生成
    var hooker = app.Type<Hooker>()();

    //ポップアップ表示
    main.Click(MouseButtonType.Right, 5, 5);

    //送信先ウィンドウハンドル取得
    IntPtr sendWnd = hooker.LastPopupOwner;
}

public class Hooker
{
    const int WM_INITMENUPOPUP = 0x0117;
    const int WH_CALLWNDPROC = 4;

    delegate IntPtr HookProc(int code, IntPtr wParam, IntPtr lParam);

    [DllImport("user32.dll")]
    static extern IntPtr SetWindowsHookEx(int hookType, HookProc lpfn, IntPtr hMod, int dwThreadId);

    [DllImport("user32.dll")]
    static extern IntPtr CallNextHookEx(IntPtr hookHandle, int nCode, IntPtr wParam, IntPtr lParam);

    [DllImport("kernel32.dll")]
    static extern int GetCurrentThreadId();

    [StructLayout(LayoutKind.Sequential)]
    struct CWPSTRUCT
    {
        public IntPtr wparam;
        public IntPtr lparam;
        public int message;
        public IntPtr hwnd;
    }

    HookProc _traceProc;
    IntPtr _idHook;

    public IntPtr LastPopupOwner { get; set; }

    public Hooker()
    {
        var threadId = GetCurrentThreadId();
        _traceProc = WindowProcHook;
        _idHook = SetWindowsHookEx(WH_CALLWNDPROC, _traceProc, IntPtr.Zero, threadId);
    }

    ~Hooker() => GC.KeepAlive(_traceProc);

    IntPtr WindowProcHook(int hookCode, IntPtr wParam, IntPtr lParam)
    {
        if (hookCode < 0)
        {
            return CallNextHookEx(_idHook, hookCode, wParam, lParam);
        }

        var msg = (CWPSTRUCT)Marshal.PtrToStructure(lParam, typeof(CWPSTRUCT));
        if (msg.message == WM_INITMENUPOPUP)
        {
            LastPopupOwner = msg.hwnd;
        }
        return CallNextHookEx(_idHook, hookCode, wParam, lParam);
    }
}

で取ることには成功したのですが、フック開始をユーザーに明示的にやらせるのかとか、あとやりたいことの割に仕掛けが大げさなので一旦ライブラリにはいれないことにしました。（やりたい人はこのコードを使ってね）もっとサクッとメニューハンドルから送信先のウィンドウハンドル取れたらいいんですけどねー。内部的には知ってるはずだよなー。なんかないかなー。

Friendly.Windows.KeyMouseを公開しました

Friendly.Windows.KeyMouseを作成しました！
github.com
あれだけ、キーマウスエミュレートをディスっておきながら、やるんかいってことなんですが・・・

繰り返しますが、最後の手段です。

もっと確実に簡単に操作できる手段があるならそちらを使ってください。どうしてもキー、マウスをエミュレートするテストがしたい場合や、他に手段がない場合にご利用ください。テスト中に全く触らなければ確実に（おそらく）動作しますが、処理中に机が揺れたりしてマウスが少し動いただけで失敗したりしますし。

確実に動作するキーマウスエミュレートなのです。（おそらく

半年ほど前にキーエミュレートに関する記事を書きました。
実はその時から、恐らく確実に動作するだろうキーマウスエミュレートは作れるだろうとは思っていたのですが、全面に押し出すものではないしなーと二の足を踏んでいました。
とは言え、要望はかなりあったので、一丁試しにやってみるかとの運びです。その辺の迷いが、Friendly.Windowsとかに実装するのではなく、新しいライブラリを追加しているとこにも表れています。

やっていることは単純

実装内容はいたって簡単で、旧来のキーマウスエミュレートAPIとFriendlyを組み合わせただけです。Friendlyでやっていることは

• 座標の取得
• 画面のアクティブ化（一部KeyのAPI）
• タイミングの調整

何故確実に動作させられるのか？

ポイントはタイミングの取り方なのです。
その辺は、前にこちらに長々と書いたのでご興味あれば参照お願いします。
Windowsアプリテスト自動化でのキーエミュレートはありなのか？ - ささいなことですが。

マウスも実はこれでタイミングが取れます。
ビジーなタイミングを避ければ、キーマウスは失敗しない（はず）もちろんアプリ内で別スレッドでの非同期処理を実装している場合は、別途待ち処理が必要です。

意外とネックになるクリック、ダブルクリック問題にも対応

なんでかというと、クリック→クリックってやったときに、ダブルクリックになるという問題があります。「え、そんなのダブルクリック時間見ればいいんじゃない？」って思うでしょ？そうなんですけど、これではダメなんですよ。

//クリック送信
SendInput(inputArray.Length, inputArray, Marshal.SizeOf(inputArray[0]));

//ダブルクリック時間待ち
Thread.Sleep(SystemInformation.DoubleClickTime);

//クリック送信
SendInput(inputArray.Length, inputArray, Marshal.SizeOf(inputArray[0]));

//あれ？タイミングによってダブルクリックになる。

なぜかというと、ダブルクリックかどうかを判定するときに使う時間はあくまで対象のアプリが決めるからです。送信した時間から計測を始めても不正確なのです。相手が受信したタイミングから数えないといけない。それって相手の処理状態が分からないと無理なんですね。今回はタイマーメッセージを使うことにより、相手が受信したという状態を取得できるようにしています。実際のコードとは異なりますが、イメージ的には以下のようになるようにしています。

//クリック送信
SendInput(inputArray.Length, inputArray, Marshal.SizeOf(inputArray[0]));

//タイマーメッセージが通るのを待つ
//(相手に前に送ったマウスエミュレートが届いている)
WaitForTimerMessage(_app);

//ダブルクリック時間待ち
Thread.Sleep(SystemInformation.DoubleClickTime);

//クリック送信
SendInput(inputArray.Length, inputArray, Marshal.SizeOf(inputArray[0]));

サンプルコード

GitHubの方にも書きましたが、こっちにもサンプル書いておきます。
拡張メソッドなので、最初にusingおねがいします。

using Codeer.Friendly.Windows.KeyMouse;

キーエミュレート

var window = WindowControl.FromZTop(app);
var target = new FormsTextBox(window.Dynamic()._keyTest);

//引数はSystem.Windows.Forms.SendKeysと同じ仕様です。
target.SendKeys("aBc");

//CONTROL + Q
target.SendControlAndKey(Keys.Q);

//SHIFT + Q
target.SendShiftAndKey(Keys.A);

//ALT + Q
target.SendAltAndKey(Keys.Q);

//CONTROL + SHIFT + ALT + Q
target.SendModifyAndKey(true, true, true, Keys.Q);

マウスエミュレート

var window = WindowControl.FromZTop(app);
var target = new WindowControl(window.Dynamic()._mouseTest);

//左クリック 座標はコントロールの中央です。
target.Click();

//ボタンと座標指定
target.Click(MouseButtonType.Middle, new Point(4, 5));

//ダブルクリックも同様
target.DoubleClick();
target.DoubleClick(MouseButtonType.Middle, new Point(4, 5));

//Drag & Drop.
var dropTarget = new WindowControl(window.Dynamic()._dropTest);
target.MouseDown(MouseButtonType.Left, new Point(0, 0));
dropTarget.MouseUp(MouseButtonType.Left, new Point(2, 3));

キーとマウスを同時に操作

var window = WindowControl.FromZTop(app);
var target = new WindowControl(window.Dynamic()._keyMouseTest);

//ALT + MouseClick;
app.KeyDown(Keys.Menu);
target.Click():
app.KeyUp(Keys.Menu);

ご意見お待ちしております！

まだβ版という位置づけにしているのでご意見あれば言ってください。反映していきます。

Quick Shot を公開しました

Quick Shot っていう VisualStudio拡張を作成しました。
VisualStuido Marketplace からダウンロードできます。
marketplace.visualstudio.com

関数を単体で実行、デバッグできます。

ざっくりいうと、そんな感じです。
右クリックした関数を実行、デバッグできます。

対応環境

現在の対応状況です。
余裕ができたら増やして行きます。
.NetCoreと.NetStandardはちょっと遅いので（特に一回目）、何とか早くしたいと思ってます。（何とかならんかも）

【VisualStuido】

• 2015
• 2017

【言語】

• C#

【.net】

• .NetFramework
• PortableLibraly
• .NetCore(project.jsonのないタイプ)
• .NetStandard(project.jsonのないタイプ)
• Sharedはソリューション内で上記から参照されている場合のみ

実行結果の表示

Enumerable以外

Enumerable

もともとLambdicSql用に作っていて、SQLの実行結果をいい感じに見れるような仕様にしました。

static以外で引数がある場合

こんな感じのモーダレスウィンドウが出てくるので、値を設定して Execute を押してください。

一回設定したら、VisualStudioを起動している間はキャッシュされて、それが使われます。
変えたい場合は、その関数内で右クリックして、Edit setup codes を選んでください。

共通初期化

各プロジェクトごとで、共通で最初に実行したい処理があれば、Edit setup codes で __CommonInitializer.Initializeに実装しておけます。

それから、先ほどの引数設定の時もそうでしたが、ヘルパーメソッドが使えます。

public abstract dynamic New(string name, params object[] args);

関数が属するアセンブリのinternalなクラスを生成できます。
dynamicで返ってきて、internalなプロパティやメソッドの操作ができます。

public abstract void WriteLine(string line);

ログ出力できます。

public abstract __DefaultValues DefaultValues { get; }

次に説明するデフォルト値が使えます。

デフォルト値

引数でよく使うものはデフォルト値を設定しておくと、それがデフォルト値として使われるようになります。（もちろん変えたらそちらが優先されます。）コネクションとかDbContextとか。
EntityFrameworkで使うと結構便利です。

こう書いておくと、Sample.TestModelを引数に取るメソッドを実行するときはデフォルトで、これを使ってくれます。もちろん手動でも使えます。

実行すると、SQLのログまで出力できて超便利！

みんな使ってね。

フィードバックお待ちしております！

LambdicSql - 続 String interpolation 対応しました。

neueさんからご意見いただいたので、改善しました。

Expressionで受ける必要ないのでは？

確かに。
シンプルなものは受ける必要がないですね・・・。
書き味悪いし、Expressionは軽い処理ではないので必要ないなら使わない方がいい。
なので、FormattableString で受けるバージョンを追加しました。

public partial class Db
{
    public static Sql InterpolateSql(FormattableString formattableString);
    public static Sql<TResult> InterpolateSql<TResult>(FormattableString formattableString);
}

シンプルに使いたい場合はこっちの方がいいですね。

static void Sample0(IDbConnection cnn)
{
    var city = "London";
    var contactTitle = "Sales Representative";

    var sql = Db.InterpolateSql<Customers>(
$@"SELECT *
FROM Customers
WHERE City = {city}
AND ContactTitle = {contactTitle}"
       );

    //実行時にコンソールに出力する設定
    DapperAdapter.Log = x => Console.WriteLine(x);

    //Dapperで実行
    var datas = cnn.Query(sql).ToList();
}

Expression版は必要ないか？

とは言え、これはこれで便利なところもあるので残します。
式を入れれたり

var sql = Db<DB>.InterpolateSql<Customers>(db =>
$@"SELECT *
FROM Customers
WHERE {(db.Customers.City == city && db.Customers.ContactTitle == contactTitle)}"
   );

LambdicSqlのオブジェクトを入れたりできます。

var sub = Db<DB>.Sql(db =>
    Select(Sum(db.tbl_remuneration.money)).
    From(db.tbl_remuneration)
    );
var sql = Db.InterpolateSql<Customers>(() =>$@"SELECT Total = ({sub})");

上手く改行できなくてちょっと残念。

LambdicSql - String interpolation 対応しました。

String interpolation を使えるようにしました！
github.com

きっかけは

TLにあったneueさんのツイート

String interpolation/FormattableStringを使ったSQL整形、最高に良いアイディア。うちでも展開していきたい。 / “Announcing EF Core 2.0 Preview 2 | .NE…” https://t.co/FjpytbLQKu

— neuecc (@neuecc) 2017年7月13日

どうやら、EFで以下のような書き方ができるようになったとのこと。

var city = "London";
var contactTitle = "Sales Representative";

using (var context = CreateContext())
{
    context.Customers
       .FromSql($@"
           SELECT *
           FROM Customers
           WHERE City = {city}
               AND ContactTitle = {contactTitle}")
       .ToArray();
}

@p0='London' (Size = 4000)
@p1='Sales Representative' (Size = 4000)

SELECT *
FROM Customers
WHERE City = @p0
    AND ContactTitle = @p1

えええ！？
なんで、そんなことできるの？

って思ってたら、ブログの下の方に、
FormattableString で受けたらいいんだよ。
って書いてありました。
なるほどねー。
これは、LambdicSqlにも是非取り込まねばってことでやってみました。

InterpolateSql

新たに、InterpolateSqlって関数を追加しました。

static void Sample1(IDbConnection cnn)
{
    var city = "London";
    var contactTitle = "Sales Representative";

    var sql = Db.InterpolateSql<Customers>(() =>
$@"SELECT *
FROM Customers
WHERE City = {city}
AND ContactTitle = {contactTitle}"
       );

    //変換
    var info = sql.Build(cnn.GetType());

    //文字列とパラメータをコンソールに出力
    Console.WriteLine(info.Text);
    Console.WriteLine("\r\n------Params------");
    foreach (var e in info.GetParams()) Console.WriteLine($"{e.Key} = {e.Value.Value}");

    //実行するときはこんな感じ
    var datas = cnn.Query(sql).ToList();
}

出力はこうなります。

なんと式を埋め込むことも可能です！

LambdicSqlはもともとExpression解析するライブラリなんで、もっと色々な情報が取れます。例えば上のでも変数名が取れてたり。なので、{}内にはLambdicSqlで使えるものは全部れることができるんです。
式を埋め込むこともOKです。

var sql = Db<DB>.InterpolateSql<Customers>(db =>
$@"SELECT *
FROM Customers
WHERE {(db.Customers.City == city && db.Customers.ContactTitle == contactTitle)}"
);

SELECT *
FROM Customers
WHERE ((Customers.City) = (@city)) AND ((Customers.ContactTitle) = (@contactTitle))

.NetFramework4.6以降で使えます。

FormattableString が4.6以降でないと使えないようですね。PCLとか.NetStandardとか今回対応できませんでした。（使えんことはないよな？、そのうち調べて対応します。）

え？文字列使わずに書けるようにするって・・・

はい。SQL全網羅に向けて頑張ってますよー。でもまだ先は長い（長すぎる）。SQLServerは半分くらいはいったかなー。ほとんどのは書けるんですけど、定義してないの使うことあったら、これ使ってください的な。引き続きメンバー募集中です！

サンプルコード全文

DapperとLambdicSql.SqlServerをNugetから入れて、接続文字書いてもらったら動きます。使ってみてくださいねー。

using System;
using System.Linq;

//LambdicSql
using LambdicSql;

//for SqlServer and Dapper.
//Of course, other connections are OK.
//OracleConnection, SQLiteConnection, NpgsqlConnection, MySqlConnection, DB2Connection
using System.Data;
using System.Data.SqlClient;
using static LambdicSql.SqlServer.Symbol;
using LambdicSql.feat.Dapper;

namespace FormattableStringSample
{
    class Program
    {
        class Customers
        {
            public string City { get; set; }
            public string ContactTitle { get; set; }
        }

        class DB
        {
            public Customers Customers { get; set; }
        }

        static void Main(string[] args)
        {
            //initialize dapper.
            DapperAdapter.Assembly = typeof(Dapper.SqlMapper).Assembly;

            //test.
            using (var cnn = new SqlConnection("your connection string")) Sample1(cnn);
            {
                Sample1(cnn);
                Sample2(cnn);
                Sample3(cnn);
            }
        }

        static void Sample1(IDbConnection cnn)
        {
            var city = "London";
            var contactTitle = "Sales Representative";

            var sql = Db.InterpolateSql<Customers>(() =>
$@"SELECT *
FROM Customers
WHERE City = {city}
    AND ContactTitle = {contactTitle}"
               );

            //to string and params.
            var info = sql.Build(cnn.GetType());

            //print.
            Console.WriteLine(info.Text);
            Console.WriteLine("\r\n------Params------");
            foreach (var e in info.GetParams()) Console.WriteLine($"{e.Key} = {e.Value.Value}");

            //execute query by dapper or sql-net-pcl.
            var datas = cnn.Query(sql).ToList();
        }

        static void Sample2(IDbConnection cnn)
        {
            var city = "London";
            var contactTitle = "Sales Representative";

            var sql = Db<DB>.InterpolateSql<Customers>(db =>
$@"SELECT *
FROM Customers
WHERE {(db.Customers.City == city && db.Customers.ContactTitle == contactTitle)}"
           );

            //to string and params.
            var info = sql.Build(cnn.GetType());

            //print.
            Console.WriteLine(info.Text);
            Console.WriteLine("\r\n------Params------");
            foreach (var e in info.GetParams()) Console.WriteLine($"{e.Key} = {e.Value.Value}");

            //execute query by dapper or sql-net-pcl.
            var datas = cnn.Query(sql).ToList();
        }

        static void Sample3(IDbConnection cnn)
        {
            var city = "London";
            var contactTitle = "Sales Representative";
            
            var sql = Db<DB>.InterpolateSql<Customers>(db =>
$@"SELECT *
FROM Customers
{Where(new Condition(!string.IsNullOrEmpty(city), db.Customers.City == city) && new Condition(!string.IsNullOrEmpty(contactTitle), db.Customers.ContactTitle == contactTitle))}"
           );

            //to string and params.
            var info = sql.Build(cnn.GetType());

            //print.
            Console.WriteLine(info.Text);
            Console.WriteLine("\r\n------Params------");
            foreach (var e in info.GetParams()) Console.WriteLine($"{e.Key} = {e.Value.Value}");

            //execute query by dapper or sql-net-pcl.
            var datas = cnn.Query(sql).ToList();
        }
    }
}

2017 MVP アワードを受賞いたしました！

今年も、Microsoft MVP を受賞することができました！
カテゴリは Visual Studio and Development Technologies です。

これも支えていただいている皆さんのおかげです。
ありがとうございます！

今期の目標は

• LambdicSqlの正式版リリース（まだやったんかい・・・）
• Friendly勉強会の定期開催

Friendly勉強会に関しては、連載物ではなくて
その都度お題を決めて実践的なケースを解決していくスタンスで行こうと思います。
とは言え、最初は簡単なケースからやると思います。

少しでも技術コミュニティに貢献できるように、突っ走っていきます！
あと、ブログも最近さぼり気味だったんで書いていこうっと。

今期もよろしくお願いします。

まだまだ、未熟者。
今期も皆さんにお世話になるとおもいますが、
よろしくお願いします！

Windowsアプリテスト自動化でのキーエミュレートはありなのか？

最近お客様から「Friendlyではキー操作は使えないの？」って聞かれることが何回かありました。キーエミュレートねー。Friendly作る前はやってたけど不安定だったんですよねー。MSDNにもタイミング問題あるって書いてるし。でもFriendlyと組み合わせたらなんとかなるんじゃないか？ってことで色々考えてみました。
なお、このエントリを書くにあたりとっちゃんさんから色々教えていただきました。ありがとうございました！

結論から言うとアリ

タイミング依存の失敗はあると言われています。が、今回考えてみるとテストというコンテキストではFriendlyを使うことによってタイミングをコントロールしきれると思います。
で、コード書いてみました。もしかするとライブラリに組み込むかもしれませんが、ちょっと先になるので必要な方はコピって使ってください。DLLインジェクションやってますので定義するDLLの.Netのバージョンは対象のアプリのもの以下でお願いします。対象がネイティブアプリならバージョンは何でもOKです。

WinForms

using Codeer.Friendly;
using Codeer.Friendly.Dynamic;
using Codeer.Friendly.Windows;
using System.Windows.Forms;

namespace SendKeyEx
{
    public static class WinFormsImplement
    {
        public static void FormsSendKeys(this WindowsAppFriend app, string keys)
            => app.Type<SendKeys>().SendWait(keys);

        public static void FormsSendKeys(this WindowsAppFriend app, string keys, Async async)
        {
            Initializer.Init(app);
            app.Type<SendKeys>().SendWait(keys, async);
            TimerMessageWaiter.Wait(app);
        }
    }
}

WPF

using Codeer.Friendly;
using Codeer.Friendly.Dynamic;
using Codeer.Friendly.Windows;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Threading;

namespace SendKeyEx
{
    public static class WPFImplement
    {
        public static void WPFSendKeys(this WindowsAppFriend app, string keys)
        {
            Initializer.Init(app);
            app.Type(typeof(WPFSendKey)).SendWait(keys);
        }

        public static void WPFSendKeys(this WindowsAppFriend app, string keys, Async async)
        {
            Initializer.Init(app);
            app.Type(typeof(WPFSendKey)).SendWait(keys, async);
            TimerMessageWaiter.Wait(app);
        }
        
        static void SendWait(string keys)
        {
            //キー送信
            bool sent = false;
            Task.Factory.StartNew(() => 
            {
                System.Windows.Forms.SendKeys.SendWait(keys);
                sent = true;
            });

            //送信が完了するのを待つ
            while (!sent) Thread.Sleep(0);

            //キー処理
            DoEvents();
        }

        static void DoEvents()
        {
            DispatcherFrame frame = new DispatcherFrame();
            Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background,
                new DispatcherOperationCallback(ExitFrames), frame);
            Dispatcher.PushFrame(frame);
        }

        static object ExitFrames(object f)
        {
            ((DispatcherFrame)f).Continue = false;
            return null;
        }
    }
}

Native

using Codeer.Friendly.Windows;

namespace SendKeyEx
{
    public static class NativeImplement
    {
        public static void SendKeys(this WindowsAppFriend app, string keys)
        {
            Initializer.Init(app);
            System.Windows.Forms.SendKeys.SendWait(keys);
            TimerMessageWaiter.Wait(app);
        }
    }
}

共通で使うコード

using Codeer.Friendly.Windows;

namespace SendKeyEx
{
    static class Initializer
    {
        internal static void Init(WindowsAppFriend app)
        {
            var asm = typeof(Initializer).Assembly;
            object isInit;
            if (app.TryGetAppControlInfo(asm.FullName, out isInit)) return;

            WindowsAppExpander.LoadAssembly(app, asm);
            app.AddAppControlInfo(asm.FullName, true);
        }
    }
}

using System.Windows.Forms;
using Codeer.Friendly.Windows;
using Codeer.Friendly.Dynamic;

namespace SendKeyEx
{
    class TimerMessageWaiter
    {
        public bool Arrived { get; set; }
        public TimerMessageWaiter()
        {
            var timer = new Timer { Interval = 1 };
            timer.Tick += (_, __) =>
            {
                timer.Stop();
                Arrived = true;
            };
            timer.Start();
        }

        internal static void Wait(WindowsAppFriend app)
        {
            var waiter = app.Type<TimerMessageWaiter>()();
            while (!(bool)waiter.Arrived) System.Threading.Thread.Sleep(0);
        }
    }
}

そもそものSendKeysの動作

この辺参考に
About Messages and Message Queues (Windows)
GetMessage 関数
Reference Source

SendInput実行からUIスレッドで実行するまでの流れはこんな感じです。

1. SendInput関数実行によりキーボードストリームに入力データが入る（MSDN）
2. 割り込み処理により（※注）アクティブなUIスレッドのシステムメッセージキューに入力メッセージを配置（MSDN）
3. UIスレッドがそれを取り出し、変換しながら、さらに自分のスレッドにメッセージをポストしながら実行

※注の部分に関しては正規のドキュメントは未発見ですが、以下の理由から割り込みで実行されると考えています。なぜそれにこだわっているかというと、ここでやっている同期の取り方はSendKeysを呼び終わった段階でアクティブなUIスレッドのシステムメッセージキューに入力メッセージが届いているという考えに依存してるからです。

• もともとの処理がドライバで行われている。キードライバの場合はIRQ割り込み。
• とっちゃん談
• SendKeysに大量に文字列を渡したときに重い（単にバッファに入れるだけならもっと早いはず）
• そうでなければ.NetのSendKeysの実装が説明つかない（どう見てもこの考えに依存した実装になっている）

SendKeysが失敗する理由

これを踏まえて、SendKeysが目的のキー処理を失敗する理由を考えます
①キーボードの種類や言語によって失敗する可能性がある
②対象のアプリがアクティブでない
③対象のコントロールにフォーカスが当たっていない
④UIスレッドのシステムキューのバッファ、およびアプリ部分の何かのバッファが溢れた
⑤野良メッセージループが回っている

加えて、テストという観点で考えると
⑥同期がとれていないので結果取得のタイミングで処理が終わっていない可能性がある

①はまあ仕方がない。制限事項として受け入れるしかないですね。Friendlyなどの別の操作ライブラリと合わせて使うことにより、その制限の範囲内でも十分な成果は上がられると思います。（しかもこれは失敗するときは絶対失敗するしタイミング依存の失敗にはならない）②③はFriendlyを使うと容易に解決できます。④⑤⑥ですがこれは同期が取れれば全部解決できそうです。⑤に関しては最後に別途解説します。④に関しては同期がとれればあふれるほどは送信しないですよね？同期が取れてもあふれるならそれはタイミング依存の失敗ではなく、送信データが悪いということで毎回失敗するはずです。

同期をとる

SendKeysにはSendWaitというものがあります。しかし、Vista以降ではUACの制限があり別プロセスがキーを受け取る場合、その終了を待つことができないようになっています。
SendKeys.SendWait メソッド (String) (System.Windows.Forms)
以前はジャーナルフックという手法を使っていて、別プロセスでもキーが送信されたことを確認できていたようです。コードを見ると努力の跡が見られます。
Reference Source
結局現在では、このSendWaitで待てるのはWinFormsでアクティブなUIスレッドで実行した場合のみです。今回はFriendlyを使って同期をとるコードを考えてみました。

WinForms

相手プロセスでSendKeysを実行するだけでOKです。処理が終わるまで待ってくれます。Asyncバージョンには最後に怪しい処理が入っています。Nativeの解説のところで解説します。

WPF

SendKeys.SendWait メソッド (String) (System.Windows.Forms)の待ち処理を見ると単にDoEvents()しているだけですね。これをWPF用に取り換えてやります。それで自分のスレッドへの投げ込みが上手く行かないので投げ込みは別スレッドからやってやります。WPFではSendKeysではなくInputManagerを使うのが良いとも言われてますのでそれで作ってもよいですが、SendKeysの方が圧倒的に使い勝手が良いので私はこれで実装しました。
で、そもそもの問題としてSendInput送って、その後メッセージ処理の前にUIスレッドのキューにそれが入っていることが保証されているの？という話ですが、そこは※注で書いている話です。オリジナルのSendKeysがそうやってるんだから多分この考えはあっていると思います。正式なドキュメント見つけたい・・・。

Native

今回作ったネイティブ版の実装は実は上の二つ（WinForm版、WPF版）とは待ちが終了するタイミングが異なります。上の二つが処理が完全に終わる（キーイベントを受けて実行する関数を抜ける）のを待ち切るのに対して、こちらはTimerメッセージが通るくらいメッセージ処理に余裕ができれば抜けます。具体例としてショートカットキーを実行した後モーダルダイアログが出る場合、WinForms版とWPF版はダイアログが閉じるまで固まっています。そのためAsync版があります。対してネイティブ版はダイアログが出てメッセージループが回り始めれば抜けます。とは言えどちらも入力キーの処理が残っていれば制御は返しませんし、ダイアログが出たら抜けてくれるならこっちの方が使い勝手いいんじゃないの？って思うかもしれません。多くの場合はその通りでこれで問題なく処理を進めることができます。後述しますが、欠点はキーイベントから呼び出された関数の中で独自ループを回している場合に同期が取りづらくなるというものです。
それでTimerメッセージ待ちってなんやねん！ということなんですが根拠はこちらのドキュメントです。
GetMessage 関数
Windowsのメッセージには処理される優先順位があります。

1. 送信済みメッセージ
2. ポスト済みメッセージ
3. 入力（ハードウェア）メッセージとシステムの内部イベント
4. 送信済みメッセージ（再度）
5. WM_PAINT メッセージ
6. WM_TIMER メッセージ

特にSendMessageは強力でGetMessageせずともSendMessageしている最中とか、いくつかのWin32APIを呼び出している最中に割り込んできたりします。ポストメッセージが入力よりもプライオリティが高いのですねー。入力メッセージを受けて自分に対してポストメッセージするからかな？それで、Timerメッセージは優先順位が一番低くなっています。つまり入力メッセージや、それから送られたポストメッセージがキューに残っているとメッセージが処理されません。このメッセージが到着した（タイマのTickが飛んできた）ということはその前に送ったキー処理はすべて終わっているといえます。それでWPFとWinFormsの非同期版にこれが入っている理由は、実はFriendlyの処理が内部的にSendMessageとPostMessageを使っているからです。ともに入力メッセージの処理よりプライオリティが高いんですね。普通にFriendlyの処理ばかりを使っていると非同期を使っても、後の処理が追い越すことはないのですが（もちろん前の処理中にダイアログなど表示されると別です）今回は入力メッセージが絡むので嫌な感じのところで前の処理に割り込むことがあります。それを防ぐためにここでも入力メッセージの処理の終了待ちをいれています。

⑤野良メッセージループが回って失敗する

思い返してみれば、タイミング依存の失敗のほとんどはこれじゃないかなー。簡単な例を書くと、ALT+Aでテキストボックスがあるダイアログを表示するアプリがあるとします。（入力結果はラベルに反映）

public partial class MainForm : Form
{
    public MainForm()
    {
        InitializeComponent();
    }

    void ButtonTextDialogClick(object sender, EventArgs e)
    {
        using (var dlg = new TextForm())
        {
            dlg.ShowDialog();
            _label.Text = _label.Text + dlg.InputText;
        }
    }
}
public partial class TextForm : Form
{
    public string InputText => _textBox.Text;
    
    public TextForm()
    {
        InitializeComponent();
    }

    protected override void OnClosing(CancelEventArgs e)
    {
        base.OnClosing(e);
    }
}

これにキーメッセージを送ります。

for (int i = 0; i < 2; i++)
{
    SendKeys.SendWait("%a");
    SendKeys.SendWait("abc");
    SendKeys.SendWait("{TAB}");
    SendKeys.SendWait("{ENTER}");
}

これは上手く行きます。ダイアログ起動→テキスト入力を二回繰り返してもキーの取りこぼしは発生しません。
しかし、以下のようにDoEventsを入れると途端に動作しなくなります。両方入れる必要はなく、どちらかでも失敗します。

public partial class TextForm : Form
{
    public string InputText => _textBox.Text;
    
    public TextForm()
    {
        InitializeComponent();
        Application.DoEvents();
    }

    protected override void OnClosing(CancelEventArgs e)
    {
        base.OnClosing(e);
        Application.DoEvents();
    }
}

このDoEventsで処理されると、どちらも期待のコントロールがまだ生成されてなかったり、Disable状態になってたりでキーが無視されてしまいます。
で、これは場合によればうまく行くこともあります。そのためSleepとかでなんちゃって対応される場合があり状況が悪化したりします。
これは極端な例ですが、DoEvents的メッセージ処理呼んでいる箇所はちょっと大きめのアプリならそれなりにありますよね。ましてやネイティブアプリなんてやりたい放題だし、WPFでもDispatcherFrameを使ったイベント処理もやるときはあるでしょう。（直接書いたつもりはなくても外部のGUIライブラリ使ったら内部的に使われてたとか）こういうコードは人間が操作する限りには問題は発生しません。むしろ体感をよくするために仕込まれたりします。

WinFormsとWPFのものはこれに対応できている

Friendlyは同期呼び出しなので、例えばイベント内でメッセージループを勝手に回したとしても、そのイベントが終わるまで待つので影響を受けません。モーダルダイアログを表示するときのみ非同期にしますが元々の処理の終了を待つことができるのとモーダルダイアログ起動待ちができるのとで野良メッセージループにハマらないように実装できます。もともとFriendlyの設計は、この野良メッセージループの対応を考えたものになっています（昔苦労したから
こんな感じで書きます。

using (var app = new WindowsAppFriend(process))
{
    var main = WindowControl.FromZTop(app);
    for (int i = 0; i < 2; i++)
    {
        var a = new Async();
        SendKeys.WPFSendKeys("%a", a);
        main.WaitForNextModal();
        SendKeys.WPFSendKeys("abc");
        SendKeys.WPFSendKeys("{TAB}");
        SendKeys.WPFSendKeys("{ENTER}");
        a.WaitForCompletion();
    }
}

同期なのに非同期にするんかい！なのですが、Friendlyではそういうものですw。
main.WaitForNextModal();で最初の野良ループはスキップできます。
最後の野良ループはa.WaitForCompletion();でスキップできます。ALT+Aで実行された関数の終了を完全に待つわけです。

ネイティブのSendKeysはここが弱い

今回のネイティブの実装ではこの問題は解決できていません。モーダルダイアログや野良ループがあったら待ち合わせは終了し、かつその関数が終わったことを確認するすべはありません。まあ、そこまでの同期は取れているので（キー処理が終わったことまでは確認できるので）アプリの設計をよく確認して他の手段で野良ループをよけるしかないですね。それにさんざん脅しましたが、全部が全部野良ループ回しているわけではないし、全体からするとやっぱり少数です。（どっちやねん

using (var app = new WindowsAppFriend(process))
{
    var main = WindowControl.FromZTop(app);
    for (int i = 0; i < 2; i++)
    {
        SendKeys.SendKeys("%a");
        var dlg = main.WaitForNextModal();
        SendKeys.SendKeys("abc");
        SendKeys.SendKeys("{TAB}");
        SendKeys.SendKeys("{ENTER}");
        //Enterの入力までは同期がとれている。
        //でもALT+Aが完全に終わったかはわからない
        //この場合だとモーダルダイアログの破棄を待つと同等のことができる
        //しかし、破棄後に野良ループを回すようなコードではそれを回避できない
        //別途そのアプリの特性を活かした待ち合わせを考える必要がある
        dlg.WaitForDestroy();
    }
}

実用可能ですが

より正確な操作手段があるならそちらを優先してつかうのが良いでしょう。あえてキーエミュレートをしたい場合や他に手段がない場合などにご利用ください。