概要‎ > ‎

例外メッセージ

Friendly関連のライブラリ使用時に発生する例外の一覧です。
この情報で足りない場合は以下のメールアドレスにメールにて問い合わせお願いします。
Friendly*Codeer.co.jp(*を@に変更して送信してください。)



1.
メッセージ
アプリケーションとの接続に失敗しました。

発生理由
WindowsAppFriendでアタッチするときに、対象のプロセスが既に終了していた場合、発生します。

//呼び出した時に、processは終了していたら例外発生。
WindowsAppFriend app = new WindowsAppFriend(process, "4.0");



2.
メッセージ
指定のプロセスとの接続に失敗しました。
CLRのバージョンの指定が不正な可能性があります。
CLRのバージョンは.NetFrameworkのバージョンと異なる場合があるのでご注意願います。
サポートされているバージョンはCodeerのWebサイトを参照お願いします。

発生理由
WindowsAppFriendでアタッチ時に対象のプロセスのCLRのバージョンを不正なもので、指定した場合に発生します。
よくありがちなのは、.NetFrameworkのバージョンと間違えることです。

間違い
//CLRには3.0というバージョンは存在しません。.NetFrameworkの3.0を使っている場合、CRLのバージョンは2.0となります。
WindowsAppFriend app = new WindowsAppFriend(process, "3.0");

修正
WindowsAppFriend app = new WindowsAppFriend(process, "2.0");

現在のサポートバージョン
"2.0"
.NetFrameworkの2.0、3.0、3.5の場合、これを使います。
"4.0"
.NetFrameworkの4.0、4.5の場合、これを使います。



3.
メッセージ
指定のプロセスとの接続に失敗しました。
インストールに失敗している可能性があります。

発生理由
WindowsAppFriendで対象プロセスにアタッチする場合に、重要なdll、アセンブリの操作に失敗した時に発生します。
何らかのインストールトラブルが考えられます。



4.
メッセージ
対象プロセスの操作に失敗しました。対象プロセスを操作する権限が足りていないか、接続中に終了した可能性があります。

発生理由
WindowsAppFriendでアタッチする場合に、テストプロセスよりプロダクトプロセスの方が権限が高い場合に発生します。
例えば、プロダクトプロセスが管理者権限で、テストプロセスがユーザ権限の場合です。
この場合、テストプロセスも管理者権限にすることで解決します。
また、接続中に対象アプリが不正終了した場合にも発生します。



5.
メッセージ
プラットフォームターゲットがテスト対象とテストプロセスで異なります。合わせてください。

発生理由
プロダクトプロセスとテストプロセスで対象CPUが異なる場合に発生します。
64bitOSでプロダクトプロセスが64bitで動作しているのに、テストプロセスが32bitで動作している場合などです。
VisualStudioのテストプロジェクトを使用する場合、実行環境はデフォルトではx86になっています。これはビルドの設定ではなく、テストホストの設定を変更する必要があります。詳細はこちら参照お願いします。



6.
メッセージ
不正なstatic呼び出しです。操作情報には型が必要です。

発生理由
AppFriendのFriendlyOperationはstaticメソッドを呼び出すためのものなので、型情報が必要となります。
間違えて、メソッド名称のみを指定した場合はこの例外が発生します。

//正常な呼び出し。
app["System.Windows.Forms.Control.FromHandle"](handle);

//不正な呼び出し。(例外発生。)
app["FromHandle"](handle);



7.
メッセージ
対象アプリケーション内部で例外が発生しました。
[メッセージ]
{0}
[例外タイプ]
{1}
[エラーの原因]
{2}
[スタックトレース]
{3}
[ヘルプ]
{4}

発生理由
FriendlyOperationで実行する操作によって、対象アプリケーション内部で例外が発生した場合、それをテストプロセスの方に転送します。
例えば、以下のようなコードを書いた場合です。

コード
AppVar dic = app.Dim(new NewInfo<Dictionary<int, string>>());
dic["Add"](1, "1");
dic["[]"](2); //dicの中には2をキーとするデータが入っていないので、KeyNotFoundExceptionが発生。

表示されるメッセージ
対象アプリケーション内部で例外が発生しました。
[メッセージ]
指定されたキーはディレクトリ内に存在しませんでした。
[例外タイプ]
System.Collections.Generic.KeyNotFoundException
[エラーの原因]
mscorlib
[スタックトレース]
   場所 System.Collections.Generic.Dictionary`2.get_Item(TKey key)
[ヘルプ]



8.
メッセージ
アプリケーションとの通信に失敗しました。
対象アプリケーションが通信不能な状態になったか、
シリアライズ不可能な型のデータを転送しようとした可能性があります。

発生理由
原因は2つあるのですが、内部実装の都合上区別がつかない場合があるので、
同じメッセージにまとめています。

①対象アプリケーションが不正終了した。
テスト対象のアプリケーションが操作中に不正終了した場合に発生します。
また、不正でなくても、FriendlyOpeartionでアプリケーションの終了処理を同期で呼び出した場合にも発生します。
意図的に終了させる場合は、非同期で実行するか、例外は発生するものとして、キャッチして放置するかで対応できます。

WindowControl mainForm = WindowControl.FromZTop(app);
mainForm["Close"]();//メソッド呼び出しの終了を待ち中にアプリが終了するため、例外が発生する。

②シリアライズ不可能な型のデータを転送(送信、もしくは受信)しようとした。
Friendlyオペレーションの引数に渡せる変数はAppVarかシリアライズ可能なオブジェクトです。
また、AppVarのCoreプロパティーでやり取りできるのも、シリアライズ可能なオブジェクトのみです。
以下のような場合に発生します。

WindowControl mainForm = WindowControl.FromZTop(app);
Form f = (Form)mainForm.AppVar.Core;//Formクラスはシリアライズ不可能なので、例外発生。


9.
メッセージ
同時通信数の上限に達しました。

発生理由
Friendlyオペレーションは特殊な方法を使うと、入れ子で実施できるのですが、その入れ子の総数がuintの最大を超えた場合に発生します。
通常は発生しません。



10.
メッセージ
[型 : {0}][操作 : {1}({2})]
同名の操作が見つかりましたが、操作を実行できませんでした。
引数指定が間違っている可能性があります。
数値型、Enumも厳密に判定されるのでご注意お願いします。
(例として、long型の引数にint型を渡しても別の型と判断され、解決に失敗します。)
また、params付きの配列の場合は、その型の配列に格納して渡してください。

発生理由
FriendlyOperationを実行したとき、指定のメソッド(もしくはプロパティー、フィールド)は存在するのに、引数が解決できず、呼び出しに失敗した場合に発生します。直観に反して失敗するケースがあるので、例示しておきます。

①longを引数にとるメソッドに直値を渡したのに、解決できない。
例えば、対象アプリに以下の関数が定義されていて、
void func(long value)
 
FriendlyOperationで次のように呼び出した場合、
appVar["func"](3);

この直値の3はint値として解釈されます。
そのため、対象アプリケーション内でintを引数にとるfuncを探して検索に失敗します。
次のように修正すると、正しく動作します。

appVar["func"]((long)3);


②params付きの引数の場合
例えば、対象アプリに以下の関数が定義されていて、
void func(params int[] value)

FriendlyOperationで次のように呼び出した場合、
appVar["func"](1, 2, 3);

対象アプリケーション内でintを3つ引数にとるfuncを探して検索に失敗します。
次のように修正すると、正しく動作します。
appVar["func"](new int[]{1, 2, 3});

③Enumの場合
プロダクトコード内に定義されたenumの場合、どうやって渡すか迷うかもしれません。
まずは、プロダクトのアセンブリを参照する方法が一番シンプルです。
internalな定義の場合はフレンドアセンブリにする方法で解決できます。
参照したくない場合は、次のようにすれば、enumをAppVarとして変数を確保し、使うことが出来ます。

例えばプロダクトコードに次のようなenumとそれを引数にとる関数が定義されていたとします。
namespace Product {
    enum MyEnum{
        A,
        B,
    }
}

void func(MyEnum value)

その場合、テストプロセスでは次のように書くことでAppVarとしてenumをプロダクトプロセス内に変数確保し使うことが出来ます。
AppVar a = app["Product.MyEnum.A"]();
appVar["func"](a);


11.
メッセージ
[型 : {0}][操作 : {1}({2})]
同名の操作が見つかりましたが、操作を実行できませんでした。
引数指定が間違っている可能性があります。
params付きの配列の場合は、その型の配列に格納して渡してください。
また、object[] の場合 params object[]と区別がつかず、分解されて引数に渡されます。
そのため、object[]の要素にobject[]を入れて引き渡してください。
object[] arg;//引き渡したいobject[]
object[] tmpArg = new object[0];
tmpArg[0] = arg;//これを引き渡してください。

発生理由
FriendlyOperationを実行したとき、指定のメソッド(もしくはプロパティー、フィールド)は存在するのに、引数が解決できず、呼び出しに失敗した場合に発生します。直観に反して失敗するケースがあるので、例示しておきます。

①params付きの引数の場合
例えば、対象アプリに以下の関数が定義されていて、
void func(params int[] value)

FriendlyOperationで次のように呼び出した場合、
appVar["func"](1, 2, 3);

対象アプリケーション内でintを3つ引数にとるfuncを探して検索に失敗します。
次のように修正すると、正しく動作します。
appVar["func"](new int[]{1, 2, 3});

②object[]型の場合
FriendlyOperation自体は引数がparams object[]です。
そのため、object[]を渡すと、それが分解され、意図がわからなくなってしまいます。
ですので、使う側で、object[]だということを明示していただく必要があります。
方法としては、object[]をもう一つobject[]で包んで渡してもらうことになります。

例えば、対象アプリに以下の関数が定義されていて、
void func(object[] objs)

FriendlyOperationで次のように呼び出した場合
appVar["func"](new object[]{1, 3, 3});

対象アプリケーション内でintを3つ引数にとるfuncを探して検索に失敗します。
次のように修正すると、正しく動作します。
appVar["func"](new object[] { new object[]{1, 2, 3} });

これを仕様にするのは心苦しかったのですが、対応が大変だったのでそのままとなっています。
ご了承お願いします。



12.
メッセージ
[new {0}({1})]
指定の引数で実行できる可能性のあるコンストラクタが複数発見されました。
引数に引き渡す型を明確にするか、もしくはOperationTypeInfoを使用してください。

発生理由
オーバーロードされたコンストラクタに渡す引数で、どちらとも取れる場合に、この例外が発生します。
例えば、対象アプリケーション内に次のようなクラスが定義されている場合、
namespace Product {
    class MyClass {
        internal MyClass(Control c){}
        internal MyClass(string s){}
    }
}

FriendlyOperationで次のように呼び出すと、どちらか分からず、失敗します。
app.Dim(new NewInfo("Product.MyClass", null)); //どちらのコンストラクタを呼び出すべきか判断がつかず、例外発生。

OperationTypeInfoを使用することで解決できます。
//stringクラスを引数にとるコンストラクタを呼び出せる
app.Dim(new NewInfo("Product.MyClass", null), new OperationTypeInfo("Product.MyClass", "System.String")); 



13.
メッセージ
[型 : {0}][操作 : {1}({2})]
指定の引数で実行できる可能性のある操作が複数発見されました。
引数に引き渡す型を明確にするか、もしくはOperationTypeInfoを使用してください。

発生理由
オーバーロードされたメソッドに渡す引数で、どちらとも取れる場合に、この例外が発生します。
例えば、対象アプリケーション内に次のようなメソッドが定義されている場合、
namespace Product {
    class MyClass {
        internal void func(Control c){}
        internal void func(string s){}
    }
}

FriendlyOperationで次のように呼び出すと、どちらか分からず、失敗します。
appVar["func"](null); //どちらのfuncを呼び出すべきか判断がつかず、例外発生。

OperationTypeInfoを使用することで解決できます。
//stringクラスを引数にとるfuncを呼び出せる。
appVar["func", new OperationTypeInfo("Product.MyClass", "System.String")](null); 


14.
メッセージ
[new {0}({1})]
コンストラクタが見つかりませんでした。
引数指定が間違っている可能性があります。
数値型、Enumも厳密に判定されるのでご注意お願いします。
(例として、long型の引数にint型を渡しても別の型と判断され、解決に失敗します。)
また、params付きの配列の場合は、その型の配列に格納して渡してください。

発生理由
NewInfoを使って、対象アプリにインスタンスを生成しようとした場合、指定のコンストラクタは存在するのに、引数が解決できず、呼び出しに失敗した場合に発生します。直観に反して失敗するケースがあるので、例示しておきます。

①longを引数にとるメソッドに直値を渡したのに、解決できない。
例えば、対象アプリに以下のコンストラクタが定義されていて、
namespace Product {
    class MyClass {
        internal MyClass(long value){}
    }
}

Dimで次のように呼び出した場合、
app.Dim(new NewInfo("Product.MyClass", 3));

この直値の3はint値として解釈されます。
そのため、対象アプリケーション内でintを引数にとるコンストラクタを探して検索に失敗します。
次のように修正すると、正しく動作します。

app.Dim(new NewInfo("Product.MyClass", (long)3));

②params付きの引数の場合
例えば、対象アプリに以下のコンストラクタが定義されていて、
namespace Product {
    class MyClass {
        internal MyClass(params int[] value){}    }
}

Dimで次のように呼び出した場合、
app.Dim(new NewInfo("Product.MyClass", 1, 2, 3));

対象アプリケーション内でintを3つ引数にとるコンストラクタを探して検索に失敗します。
次のように修正すると、正しく動作します。
app.Dim(new NewInfo("Product.MyClass", new int[]{1, 2, 3}));


③Enumの場合
プロダクトコード内に定義されたenumの場合、どうやって渡すか迷うかもしれません。
まずは、プロダクトのアセンブリを参照する方法が一番シンプルです。
internalな定義の場合はフレンドアセンブリにする方法で解決できます。
参照したくない場合は、次のようにすれば、enumをAppVarとして変数を確保し、使うことが出来ます。

例えばプロダクトコードに次のようなenumとそれを引数にとる関数が定義されていたとします。
namespace Product {
    enum MyEnum{
        A,
        B,
    }

    class MyClass {
        internal MyClass(MyEnum value){}    }
}

その場合、テストプロセスでは次のように書くことでAppVarとしてenumをプロダクトプロセス内に変数確保し使うことが出来ます。
AppVar a = app["Product.MyEnum.A"]();
app.Dim(new NewInfo("Product.MyClass", a));



15.
メッセージ
[new {0}({1})]
コンストラクタが見つかりませんでした。
引数指定が間違っている可能性があります。
params付きの配列の場合は、その型の配列に格納して渡してください。
また、object[] の場合 params object[]と区別がつかず、分解されて引数に渡されます。
そのため、object[]の要素にobject[]を入れて引き渡してください。
object[] arg;//引き渡したいobject[]
object[] tmpArg = new object[0];
tmpArg[0] = arg;//これを引き渡してください。

発生理由
NewInfoを使って、対象アプリにインスタンスを生成しようとした場合、指定のコンストラクタは存在するのに、引数が解決できず、呼び出しに失敗した場合に発生します。直観に反して失敗するケースがあるので、例示しておきます。

①params付きの引数の場合
例えば、対象アプリに以下のコンストラクタが定義されていて、
namespace Product {
    class MyClass {
        internal MyClass(params int[] value){}
    }
}

Dimで次のように呼び出した場合、
app.Dim(new NewInfo("Product.MyClass", 1, 2, 3));

対象アプリケーション内でintを3つ引数にとるコンストラクタを探して検索に失敗します。
次のように修正すると、正しく動作します。
app.Dim(new NewInfo("Product.MyClass", new int[]{1, 2, 3}));

②object[]型の場合
NewInfoでのコンストラクタ引数の指定の引数はparams object[]です。
そのため、object[]を渡すと、それが分解され、意図がわからなくなってしまいます。
ですので、使う側で、object[]だということを明示していただく必要があります。
方法としては、object[]をもう一つobject[]で包んで渡してもらうことになります。

例えば、対象アプリに以下のコンストラクタが定義されていて、
namespace Product {
    class MyClass {
        internal MyClass(object[] value){}    }
}

Dimで次のように呼び出した場合、
app.Dim(new NewInfo("Product.MyClass", new object[]{1, 2, 3}));

対象アプリケーション内でintを3つ引数にとるコンストラクタを探して検索に失敗します。
次のように修正すると、正しく動作します。
app.Dim(new NewInfo("Product.MyClass", new object[] { new object[]{1, 2, 3} }));

これを仕様にするのは心苦しかったのですが、対応が大変だったのでそのままとなっています。
ご了承お願いします。



16.
メッセージ
[型 : {0}][操作 : {1}({2})]
指定の操作が見つかりませんでした。

発生理由
FriendlyOperationで対象アプリ内のメソッド、プロパティー、フィールドを呼び出そうとした場合に、その操作が見つからなかった時に発生します。
スペルミスか、もしくは対象アプリ内でまだ指定の型の定義されたアセンブリがロードされていない可能性があります。
.Netは遅延ロードなので実際に、そのアセンブリに含まれている型を使わなければアセンブリはロードされません。
その状態で、FriendlyOperationでその操作を呼び出そうとしても失敗してしまいます。

解決方法としては、対象アプリに、その型が読み込まれるような操作をするか、もしくはWindowsAppExpanderで先に、そのアセンブリを読み込ませるかで解決できます。



17.
メッセージ
[OperationTypeInfo.Arguments : ({0})][引数 : ({1})]
操作型情報の引数指定が不正です。実際に引き渡している引数の数と型指定の数が一致しません。
params付きの配列の場合は、その型の配列に格納して渡してください。

発生理由
FriendlyOperationもしくはNewInfoで引き渡した引数の数とOperationTypeInfoで指定した引数の数が異なる場合に発生します。
単純に間違えた場合の他に、引数がparams付きの引数の場合があります。
params付きの引数の場合はそれを、その型の配列に格納して渡すことで解決できます。

例えば、対象アプリに以下の関数が定義されていて、
namespace Product {
    class MyClass {
        internal void func(params int[] value){}
    }
}

FriendlyOperationで次のように呼び出した場合、
appVar["func", new OperationTypeInfo("Product.MyClass", "System.Int32[]")](1, 2, 3);

OperationTypeInfoで指定した引数の数は1でFriendlyOperationに引き渡している引数の数は3なので例外が発生します。
次のように修正すると、正しく動作します。
appVar["func", new OperationTypeInfo("Product.MyClass", "System.Int32[]")](new int[]{1, 2, 3});



18.
メッセージ
[OperationTypeInfo.Arguments : ({0})][引数 : ({1})]
操作型情報の引数指定が不正です。実際に引き渡している引数の数と型指定の数が一致しません。
params付きの配列の場合は、その型の配列に格納して渡してください。
また、object[] の場合 params object[]と区別がつかず、分解されて引数に渡されます。
そのため、object[]の要素にobject[]を入れて引き渡してください。
object[] arg;//引き渡したいobject[]
object[] tmpArg = new object[0];
tmpArg[0] = arg;//これを引き渡してください。

発生理由
FriendlyOperationもしくはNewInfoで引き渡した引数の数とOperationTypeInfoで指定した引数の数が異なる場合に発生します。
単純に間違えた場合の他に、引数がparams付きの引数の場合があります。
params付きの引数の場合はそれを、その型の配列に格納して渡すことで解決できます。

①params付き引数の場合
例えば、対象アプリに以下の関数が定義されていて、
namespace Product {
    class MyClass {
        internal void func(params int[] value){}
    }
}

FriendlyOperationで次のように呼び出した場合、
appVar["func", new OperationTypeInfo("Product.MyClass", "System.Int32[]")](1, 2, 3);

OperationTypeInfoで指定した引数の数は1でFriendlyOperationに引き渡している引数の数は3なので例外が発生します。
次のように修正すると、正しく動作します。
appVar["func", new OperationTypeInfo("Product.MyClass", "System.Int32[]")](new int[]{1, 2, 3});

②object[]型の場合
例えば、対象アプリに以下の関数が定義されていて、
namespace Product {
    class MyClass {
        internal func(object[] value){}    }
}

FriendlyOperationで次のように呼び出した場合、
appVar["func", new OperationTypeInfo("Product.MyClass", "System.Object[]")](1, 2, 3);

OperationTypeInfoで指定した引数の数は1でFriendlyOperationに引き渡している引数の数は3なので例外が発生します。
また、object[]の場合は、FriendlyOperationに引き渡した時点で分解されてしまうため、二重にobject[]で囲む必要があります。
次のように修正すると、正しく動作します。
appVar["func", new OperationTypeInfo("Product.MyClass", "System.Object[]")](new object[]{ new object[]{1, 2, 3} });



19.
メッセージ
指定の変数はIEnumerableを実装していません。

発生理由
Enumerateクラスを使うと、コンストラクタで渡したAppVarの指すオブジェクトに対してforeachでループを回すことが出来ます。

//配列などIEnumerableを実装しているオブジェクトに対しては有効。
//しかし、要素を取得するたびにアプリケーション間通信が実行されるので遅い。
//多くの要素を扱う場合は、WindowsAppExpanderを使って、対象アプリケーション内部にプログラムを送り込み、
//そちらのプロセスで実行させる方が良い。
AppVar appVar = app.Dim(new int[]{1, 2, 3});
foreach(AppVar element in new Enumerate(appVar))
{
//...
}

もちろん、これが可能なのはEnumerateのコンストラクタに渡すAppVarに格納されているオブジェクトがIEnumerableを実装している場合のみです。
それ以外の場合に使用すると、この例外が発生します。

//IEnumerableを実装していないオブジェクト(int値など)に対して実行したので例外発生。
AppVar appVar = app.Dim(1);

foreach(AppVar element in new Enumerate(appVar))
{
//...
}



20.
メッセージ
AppVarの中身がnullのオブジェクトに対して操作を呼び出しました。

発生理由
AppVarの指す対象アプリ内のオブジェクトがnullの場合に、FriendlyOperationを使用するとこの例外が発生します。

AppVar appVar = app.Dim();//空で宣言。この時点ではnull。
appVar["func"](); //nullの状態でFriendlyOperationを呼び出したので例外発生。



21.
メッセージ
アプリケーション内部で使用できる変数領域を使い切りました。

発生理由
同時にuintの最大以上のAppVarを使用すると発生します。
通常発生しません。



22.
メッセージ
[{0}]
指定の型が見つかりません。
型フルネームが間違っているか、指定の型を含むモジュールが、まだロードされていない可能性があります。

発生理由
対象アプリケーションに存在しない型を使った操作を実施した場合に発生します。
具体的には、AppFriendのFriendlyOperationでのstatic操作の呼び出しと、NewInfoを使ったインスタンスの生成時に間違った型を指定すると発生します。
スペルミスか、もしくは対象アプリ内でまだ指定の型の定義されたアセンブリがロードされていない可能性があります。
.Netは遅延ロードなので実際に、そのアセンブリに含まれている型を使わなければアセンブリはロードされません。
その状態で、FriendlyOperationでその操作を呼び出そうとしても失敗してしまいます。


23.
メッセージ
すでに実行されています。Asyncクラスの実行は一度だけです。複数回呼び出す場合は、再度Asyncクラスを生成してください。

発生理由
同一のAsyncクラスのインスタンスを複数回使用したことが原因です。
例えば、次のコードで発生します。
Async async = new Async();
button1.EmulateClick(async);
button2.EmulateClick(async);

別々のインスタンスにすることで解決できます。
Async async1 = new Async();
button1.EmulateClick(async1);
Async async2 = new Async();
button2.EmulateClick(async2);



24.
メッセージ
引数に使用されたAppVarの中に、異なるAppFriendの管理する変数プールに属するAppVarがあります。

発生理由
AppVarは最終的には、AppFriendで管理されます。
そのため、同一のAppFriendで管理されたAppVarは呼び出しの引数で使うことが可能です。
しかし、同一のプロセスを対象としても、複数のAppFriendでアタッチし、それぞれで管理するAppVarでは、お互いに引数にとることはできません。

WindowsAppFriend app = new WindowsAppFriend(process, "4.0");
AppVar dic = app.Dim(new NewInfo<Dictionary<int, string>>());
dic["Add"](1, "1");
AppVar checkValue = app.Dim();
AppVar isSuccess = dic["TryGetValue"](1, checkValue); //このようにAppVarを引数にとることが可能。

//同一のプロセスを対象として、もう一つアタッチ。これは可能。
WindowsAppFriend app2 = new WindowsAppFriend(process, "4.0");
//変数を宣言。
AppVar checkValue2 = app.Dim();
//しかし、同時に使うことはできない。
dic["TryGetValue"](1, checkValue2); //例外発生 



25.
メッセージ
不正な終了指定です。通常このメソッドは使用しません。

発生理由
Asyncクラスのインスタンスで、既に操作完了したインスタンスに対して、SetCompletedメソッドを呼び出した場合に発生します。
また、このメソッドはライブラリ開発時に使うもので、一般的には使用しません。



26.
メッセージ
アプリケーションとの通信に失敗しました。
指定の実行対象スレッドに含まれるウィンドウは存在しません。
もしくは既に破棄されました。
スプラッシュウィンドウを表示するアプリケーションの場合は、起動直後にメインウィンドウがスプラッシュウィンドウになっている場合があります。
明示的に期待のウィンドウのハンドルを指定してください。

発生理由
対象プロセスで操作を実行する、スレッド指定する場合に、そのスレッドで動作するウィンドウのハンドルを指定するのですが、そのウィンドウハンドルが無効な場合に発生します。
スレッドの指定は、ExecuteContextクラスを使うか、WindowsAppFriendでのアタッチ時に行われます。
WindowsAppFriendでアタッチする時には、プロセスを指定した場合、そのメインウィンドウが実行スレッドになります。
よくあるケースでは、スプラッシュウィンドウを表示するアプリケーションの場合、起動時に、スプラッシュウィンドウがメインウィンドウになっていて、それを使ってのアタッチ処理中に、スプラッシュウィンドウが消えて、接続に失敗するというものです。
対応方法としては、メインのウィンドウが表れるのを、別の方法で確認してから、そのウィンドウハンドルを使って、アタッチするなどがあります。



27.
メッセージ
予期せぬスレッドからの呼び出しがありました。
起点となるWindowsAppFriendを生成したスレッドからのみ、呼び出し可能です。
必要であれば、スレッドごとにWindowsAppFriendを生成してください。

発生理由
AppFriendと、それが管理するAppVarは最初にAppFriendを生成したスレッドでしか使えません。
別スレッドから操作しようとすると、この例外が発生します。
しかし、Friendlyには非同期処理をする方法が提供していますので、テストシナリオをマルチスレッドで書く必要はほとんどありません。
Asyncクラスを使う方向で検討お願いします。



28.
メッセージ
同一階層に指定のダイアログIDを持つウィンドウが複数存在するため、
ウィンドウを特定することができませんでした。

発生理由
WindowControlクラスのIdentifyFromDialogIdメソッドを使った場合、同階層に指定のダイアログIDを持つウィンドウが複数存在する場合に発生します。例えば、子ダイアログを貼り付けた画面の場合、ダイアログIDが指定されておらず、重複することがあります。
その場合は、その階層のウィンドウの取得は別の方法でおこない、そのウィンドウを元に以下の階層のウィンドウをダイアログIDで取得することで回避できます。



29.
メッセージ
指定のGUI要素はWindowハンドルを持たないため、指定のメソッド、もしくはコンストラクタは使用できません。
他の取得方法を使用してください。

発生理由
WindowControlのコンストラクタにウィンドウハンドルを持たないAppVarを渡した場合に発生します。
WindowControlで操作できるウィンドウはウィンドウハンドルを持っているものだけです。
よくあるケースは、WPFのコントロールを渡した場合です。.Netのコントロールの場合はWindowControlを使わずともFriendlyOpeartionで十分操作できますので、そちらを使用してください。
WPFのウィンドウでもトップレベルウィンドウはウィンドウハンドルを持っているので操作できます。



30.
メッセージ
指定の操作はトップレベルのウィンドウにのみ実行可能です。
以下の情報を持つウィンドウに対して操作を実施しました。
意図したウィンドウですか?
WindowText [{0}]
TypeFullName(.Net) [{1}]
WindowClass [{2}]

発生理由
トップレベルウィンドウ以外のウィンドウに割り当てたWindowControlクラスでWaitForNextZTop、もしくはWaitForNextModalメソッドを使った場合に発生します。これらのメソッドは、対象のトップレベルウィンドウ以外が最前面に来たとき、あるいはモーダルになるまで待つためのメソッドです。
テストシーケンスでSleepなどを使わず、確実に同期をとるための方法です。
そのため、トップレベルウィンドウ以外に使用することはできません。



31.
メッセージ
指定のウィンドウはAppVarによるアクセスが不可能です。
以下の情報を持つウィンドウに対して操作を実施しました。
意図したウィンドウですか?
WindowText [{0}]
TypeFullName(.Net) [{1}]
WindowClass [{2}]

発生理由
WindowControlに割り当てたウィンドウがネイティブのウィンドウで、.Netのオブジェクトを持たない場合にこの例外が発生します。
また、.Netのウィンドウでも、WindowsAppFriendで接続する際に、コンストラクタの引数で間違ったCLRのバージョンを渡してしまうと、.Netのオブジェクトを取得することができず、この例外が発生します。



32.
メッセージ
指定のウィンドウが複数発見され、特定できませんでした。
以下の情報を持つウィンドウに対して操作を実施しました。
意図したウィンドウですか?
WindowText [{0}]
TypeFullName(.Net) [{1}]
WindowClass [{2}]

発生理由
WindowControlクラスのIdentify---メソッドを呼び出した時、条件にあてはまるウィンドウが複数発見された場合に発生します。
Identify---は厳密にウィンドウを特定できるケースで使います。
テストシナリオは厳密なものであるので、Identify---のメソッドを使うのが望ましいです。
対応としては、同様の検索条件で複数枚取得できるGet---メソッドを使用してください。



33.
メッセージ
指定のウィンドウが見つかりませんでした。
以下の情報を持つウィンドウに対して操作を実施しました。
意図したウィンドウですか?
WindowText [{0}]
TypeFullName(.Net) [{1}]
WindowClass [{2}]

発生理由
WindowControlクラスのIdentify---メソッドを呼び出した時、条件にあてはまるウィンドウが発見されなかった場合に発生します。
トップレベルウィンドウでタイミング依存で、取れたり取れなかったりする場合は、同様の検索条件のWaitForIdentify---を使用してください。



34.
メッセージ
指定のチェック状態はサポートされていません。
ラジオボタンの場合、チェックをOFFにすることはできません。
他のラジオボタンのチェックをONにすることで指定のラジオボタンをOFFにしてください。

発生理由
原因のクラスとメソッド
Codeer.Friendly.Windows.NativeStandardControls.NativeButton.EmulateClick
問題の操作
対象のボタンに、設定することができない状態を指定した場合に発生します。
確認事項
・NativeButtonに指定したウィンドウは目的のウィンドウであるか。(取得方法を間違えていないか。)
・引数のCheckStateに指定した値は正しいか。



35.
メッセージ
対応するエディットが存在しません。


発生理由
原因のクラスとプロパティー
Codeer.Friendly.Windows.NativeStandardControls.NativeSpinButton.Pos
問題の操作
対象のスピンボタンにから、値を取得することができず、かつ対応するエディットボックスが存在しない場合に発生します。
確認事項
・NativeSpinButtonに指定したウィンドウは目的のウィンドウであるか。(取得方法を間違えていないか。)
・NativeSpinButtonに対応したエディットボックスウィンドウが存在するか。