を参考にさせて頂き勉強になりました。
さらなるご意見を頂きたいです。どうぞよろしくお願いいたします。
例えば、ウィンドウアプリケーションの編集画面があって、
その画面をアタッチしてアタッチの中（Doの中）で編集処理をしています。
更新ボタンを押すと、小さいポップアップ画面が表示されます。
このポップアップ画面の[OK]ボタンを押す為に、
アタッチでポップアップ画面を設定
Doの中でクリックアクティビティで[OK]ボタンを押す
方法と
クリックアクティビティで[OK]ボタンを押す
のとどちらが良いのでしょうか？
ウインドウアタッチはアクティベートするものではなく、
単にトップレベルのセレクターをコンテナとして提供する機能
という事であれば、１回きりのポップアップ画面に、アタッチする必要はないと考えています。
しかし初心者ですのでご意見いただきたく、よろしくお願いいたします。
【補足】質問には関係ないので省略しましたが、小さいポップアップの[OK]ボタンの出現を、要素を探す（UiPath.Core.Activities.WaitUiElementAppear）でまち、要素が出てきたら・・
このあと、[アタッチしてOKボタンおすか？] or [OKボタンおすか？]
の質問になります。
こんにちは
まず一回きりの動作であるなら、基本的にはアタッチは不要です。
一つのアクティビティに完全セレクターで記述すれば良いと思います。
上述のケースですが、要素を探すがあるので、実質２つではないでしょうか？また一般的にコンテナの多重化は避けた方が無難なので、ウインドウにアタッチを使う場合は、ウインドウにアタッチの中でさらにウインドウにアタッチは避けた方が良いです。
あと小さいポップアップがどのような構成（仕組み）で出現しているかによって、対応が異なります。
例えばブラウザが出力するダイアログでしたら、トップレベルセレクターが異なると思いますので、このような議論が必要になりますが、元のHTMLの一部として表示されている場合は、大元でアタッチしているトップレベルセレクターと同じと思いますので、そのままで（別のアタッチや新たにトップレベルセレクターを設定せずとも）動作するのではないかと思います。
このあたりは実際にセレクターを取ってみれば判断できると思います。
Yoichi様
まず一回きりの動作であるなら、基本的にはアタッチは不要です。
ありがとうございます。そのように設定してみます。
ウインドウにアタッチの中でさらにウインドウにアタッチは避けた方が良いです。
今回の所では、アタッチの中でアタッチしている箇所はないと思っているのですが、念のため下記のように書いています。
シーケンスで書いているのですが
編集画面アタッチ
｜－編集処理など・・
｜－【更新】ボタンを押す
小さいポップアップ画面の【OK】ボタンの要素（Element）を探す ※完全セレクター※ ←ここで編集画面のアタッチからは抜けている
条件分岐（Not Element is Nothing）
THEN ／ELSE （ELSEにはエラー処理）
（今回やらないパターン）
｜-アタッチでポップアップ画面を設定
｜-クリックアクティビティで[OK]ボタンを押す
（今回やるパターン）
｜-クリックアクティビティで[OK]ボタンを押す ※完全セレクター※
大丈夫そうでしょうか？
あと小さいポップアップがどのような構成（仕組み）で出現しているかによって、対応が異なります。
小さいポップアップのトップレベルのセレクターと
編集画面のトップレベルのセレクターと、別のものでした
ただ、逆に
お客様編集のトップレベルセレクターと、支払い編集のトップレベルセレクターが全く同じ
とかありました。
工夫が必要な事がわかりました。
こんにちは
文字だけですとわかりにくいので、可能でしたらワークフローファイルを共有いただけると
良いかもしれません。ご検討ください。
こんにちは
上記でも概ね問題ないかと思いますが、せっかく事前に要素を検出しているので、そのトップレベルウインドウを維持したままボタンクリック等をした方がベターと思います。（今ですと、要素を探すの後のアタッチウインドウで、要素の再検索が行われます。パフォーマンスの面と、極端な例では同名のウインドウがあった場合等に別のウインドウを見に行ってしまう可能性もあります。）
以下２例ほど掲載します。
このサンプルの場合、要素を探す、クリックとも同じウインドウ上のボタンが対象かと思いますので、このように全体をアタッチウインドウで囲むこともできます。
また別の方法として、最初の要素を探すでアッタッチウインドウを行い、その出力を後のアタッチウインドウで再利用する方法があります。下記では最初のアタッチウインドウでwndというwindow形変数を出力し、２つめのアタッチウインドウでこれを入力としています。こうすることにより、仮に同じトップレベルセレクターを持つウインドウが他にあったとしても、かならず同じウインドウを対象とすることができます。
Yoichi様
ご教授ありがとうございます。
要素を探すをアタッチで囲むと、まだ要素（ポップアップ）が出てないので、アタッチできないエラーになってしまい。お送りしたようなソースになっていました。
試してはないのですが、「エラー発生時に実行を継続」をTRUEにすれば出来ると思います。
要素を探すでもタイムアウトがあって、アタッチでもタイムアウトがあって
プロパティの設定もう少し詳しくなりたいと思いました。
True／False 以外に黒いボックスの時はどうなるのか？
xamlを眺めると、“True” “False” “{x:Null}” とかなので、黒いボックスだけが、ブラックボックスですｗ
こんにちは
これはアプリケーション側の作りにも依存すると思うのですが、
タイミングにより要素が見つかったりあるいは見つからなかったりするケースは、
本来見に行ってほしくない別のウインドウ等を見に行ってしまい、結果見つからないと
なるケースが多いのではと思います。
そのため、トップレベルセレクター等の指定の仕方を、より厳密にすることにより
回避できる場合がありますので、一度UiExplorerなどを活用して、ご確認いただければと思います。
(アプリケーションによっては全く同じセレクターとなってしまう場合もあるので、その場合は困難かもしれませんが．．．)
少なくともWindowsネイティブだと、ポップアップウィンドウはあくまで別ウィンドウなので、親ウィンドウの子要素というわけではないところが、悩ましいと思います。
要件的に、複数の類似プロセスがある中、特定のプロセスに紐づいたポップアップを、というのであれば。対象要素をしらみつぶしに見て行ってProcess IDで判定する、とか、そういう力業しかないかもしれません。
トップレベルセレクター等の指定の仕方を、より厳密にすること
●●編集画面と、▲▲編集画面が、同じトップレベルのセレクター
<wnd app='sample*.exe' ctrlname='frmHogeHoge' />
となってしまっていて、作りに苦戦し、つねに、各編集画面にしかない、要素が出現したか？
確認してからアタッチしていました。
しかし、ご教授いただいた、「トップレベルセレクター等の指定の仕方を、より厳密にすること」で
なんと、●●編集画面と、▲▲編集画は、面別々のトップセレクターで設定できました。
<wnd app='sample*.exe' ctrlname='frmHogeHoge' />
<wnd ctrlname='frm●●編集画面' />
視界がひろがりました！ありがとうございます。
Honoka様
少なくともWindowsネイティブだと、ポップアップウィンドウはあくまで別ウィンドウなので、親ウィンドウの子要素というわけではないところが、悩ましいと思います。
まさにその通りで、子要素でなく、悩ましい感じになりました。
いろいろな画面があるのですが、画面サイズが同じだと、トップセレクターが同じ（初心者だったので、トップセレクターを細かく指定できる事をしらず）なのに、
更新ボタン押した後のポップアップは別のトップセレクターになるという状況にかなり戸惑ってしまいました。
ご教授ありがとうございます。
Anil_G
arjunshenoy
Yoichi
gibl.rpa
Hazem_Saleh
adishjain
yikwen.goo
trajkoskisara
Parvathy
DanRagh