[過去ﾛｸﾞ] C#, C♯, C＃相談室 Part95 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
818: (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/16(日)00:28 ID:lYNu13iwM(1/2) AAS
>>816
それより前の問題としてプログラマの意図がまず間違ってんだよ
魚をさばくのにノコギリでやろうとしてる状態
そこを正してからじゃないと話にならない
正さずにむりやり進めようとしてるからボタンクリックエミュレートなどという頭の悪い発想に固執する
挙げ句の果に画面上で見えてないと処理が走らない（涙）なんてバカバカしい罠にどハマリしちゃってるわけだ
はっきり言ってリフレクションはハマりやすいからダメだなんて言ってる場合じゃないよ
819(2): (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/16(日)00:38 ID:lYNu13iwM(2/2) AAS
だいたいクライアントのやりたいことは自社アプケーションのオートメーションサポートだろうよ
それを素人の思いつきレベルの発想でUIのオートメーションに目的をすり替えたのが運の尽きだわな
レイヤの考え方が全くわかってないアマチュアの設計だからすんなりうまく行くはずがないんだ
見えてないと発火しないこと以外にいったいどんな罠が潜んでるかわかったもんじゃない
俺が提案した方法ならUIインフラに依存しなくなるから実行時の安定性と罠が少ないぶん高い生産性が期待できる
820(1): (ﾜｯﾁｮｲ d201-b83C) 2020/02/16(日)01:57 ID:iNVxJNOu0(1) AAS
アセンブリが自分や所属チーム/組織のコントロール下にないんじゃないのかな
違う理由かもしれないがそれと同じような制約下での話だと思われる
821: (ﾜｯﾁｮｲ 8361-IGGe) 2020/02/16(日)03:27 ID:QSu9wuIh0(1) AAS
>>796
>GUIの画面をバッチ処理しようとしていて
UiPathとかAutoIt使いな。
822: (ﾜｯﾁｮｲ c602-ZgUM) 2020/02/16(日)09:58 ID:as0AlWv60(1/2) AAS
>>820
そういうときはUIAutomationかWinAppDriverを使うといいよ
どうせこのあと要求がどんどん増えてボタンクリックだけじゃ済まなくなるんでしょ
あとで苦労するハックはやめてマイクロソフトが整備してる道具を使おう
823(2): (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/16(日)11:26 ID:j/dbz9ZG0(1/8) AAS
>>819
まあその「俺のプログラムが一番だ」という姿勢は俺は嫌いではないし、
むしろプログラマは全員持つべきだとも思うけども、
動的結合の価値（意味）が分からないのなら、まずはそこを理解した方がいい。
現在、Clickイベントをエミュレーション出来ないGUIフレームワークなんて、存在してない。
リフレクションも割と一般的になりつつある。(常用するのはどうかとも思うが)
だから、使いどころはあるんだよ。
省14
824: (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/16(日)11:28 ID:j/dbz9ZG0(2/8) AAS
>>816
俺も「仕様バグ」に近いものだとは思うが、おそらくMSはそう認識してないと思う。
理由は、.NETは比較的「仕様バグ」は少ない環境であり、これは、
・MSがガッツリ保守している
・バイナリ側がランタイムのバージョンを指定出来るので、改訂しやすい
為、「仕様バグ」を後方互換性の為に残す必然性がほぼ無いからだ。
少なくともobsolete(非推奨)にすることは簡単に出来るのだが、してない。
省10
825: (ﾜｯﾁｮｲ 1ede-sep5) 2020/02/16(日)11:51 ID:4ZDOKfwJ0(1) AAS
>>823
なにこの
メソッドにすりゃいーじゃん
以上の意味を見いだせない機能
826(1): (ﾌﾞｰｲﾓ MM32-BzDP) 2020/02/16(日)12:09 ID:qmeSH89zM(1) AAS
>>823
そのリンクの先はかなりクソコードだから鵜呑みにしないほうがいいぞ
まあ2005年の錆びついたものだしもともと低スキル向けの記事だからしょうがないけど
この記事の悪しき前提はViewに処理をベタ書きしちゃってることな
本来ならViewとModelを分離してView上のメニューとボタンからModelの同じメソッドをコールするのが正しい設計な
ViewとModelを分離してModelがViewに依存しなくなればModelをUIインフラから切り離して独立させることができる
そうすればオレオレスクリプトでオートメーションをサポートするといった要求にも容易に応えることができるようになる
省1
827(2): (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/16(日)13:03 ID:j/dbz9ZG0(3/8) AAS
>>826
このページのコードと用例が糞なのは事実として、エミュレーションが適切な場合もあるってことだよ。
だから現在の全てのGUIフレームワークはエミュレーション出来るようになってるし、
リフレクションも装備しつつある。
MとVを厳密に分離してVはMのラッパ扱いに留めろ、というのは現在の思想としては正しいとして、
2005頃には今ほど言われていなかった、というより、そのころの失敗を経て現在の思想があるわけだから、
このページに対してそれを言ってもしょうがない。
省5
828: (ﾜｯﾁｮｲ 37de-sep5) 2020/02/16(日)13:23 ID:If0Pwz/d0(1/2) AAS
>>827
ウンコをいじる正当性を探すな
829(1): (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/16(日)14:00 ID:j/dbz9ZG0(4/8) AAS
エミュレーションの有用性が分からないのは根本的に経験が足りない。
何故現在の全てのGUIフレームワークがその機能を持っているのか、その意味をよく考えた方がいい。
そしてそのレベルの奴がコードの善し悪しを議論するのは5年早い。
ただ、このレベルの初心者と話をしても意味がないから俺はやる気無い。
お前らが正しいのなら、MSは数年以内に.NETからエミュレーション機能、
つまりPerformClick/OnClick/リフレクション等を全削除することになるが、
俺はこれはあり得ないとしか思えない。
省2
830: (ﾜｯﾁｮｲ 37de-sep5) 2020/02/16(日)14:16 ID:If0Pwz/d0(2/2) AAS
こんなクダンネーモン作ってる暇があるならメッセージボックスが後ろに回らないように修正しろ
831: (ｽﾌｯ Sd32-yBe4) 2020/02/16(日)14:20 ID:WhOeRDRvd(1) AAS
>>807
nugetにあるよ。
832(2): (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/16(日)14:36 ID:t/nUwzcTM(1) AAS
>>827>>829
UI操作をエミュレートする需要があることは間違いではない
がしかしそれはUIコンポーネント実装のためだったりテストフレームワークのためだったりソースにアクセスできないGUIアプリケーションのオートメーションのためだったりであって
自社アプリにオートメーションサポートを実装するための基盤ではない
それをサポートを実現するまっとうな設計はUI層に依存しないAPIやCLIの提供であってUI操作とは全く逆の考え方だ
お前はノコギリにだって役目と需要があると言ってる
しかしノコギリは魚をさばくのには適さない
省1
833: (ﾜｯﾁｮｲ af97-hMlH) 2020/02/16(日)15:56 ID:4YtH0n6X0(1) AAS
年末年始年始に非同期処理で騒いでた人かな
834(2): (ｱｳｱｳｳｰ Sac3-+wK4) 2020/02/16(日)18:17 ID:vSVyAtifa(1) AAS
>>832
あんたも相当しつこいねw
俺は質問者さんと別人だけど、ボタンやメニューのクリックをシミュレートしたい
場面というのは実際問題しばしば存在するよ
例えばクリックすると何か処理が走るボタンが複数あるとする。
この時、これを全部クリックしたのと同じ機能を果たすボタンが欲しい、
なんていうのは割とありがちな話。
省3
835: (ﾜｯﾁｮｲ 1ede-sep5) 2020/02/16(日)18:27 ID:Oyf7AnZI0(1) AAS
>>834
えー、それにこれ使っちゃうのはキチガイだろ
チェック関連全部走ってから
本処理行くだろ
836(1): (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/16(日)18:32 ID:j/dbz9ZG0(5/8) AAS
>>832
「UIに依存する」のではなく、「UIの代替を提供する」のであって、
UIが変更された場合にはUIと同じく変更されるのが正しいんだよ。この点が違う。
そしてソース変更無しで自動追従させる手法がエミュレーションになる。
「UIに依存する」というのは、UIとは本来関係ない事をUIを通してやってしまっていることにより、
UIが変更された場合に動かなくなって困る（動作が変わってしまう）ことを言ってるだろ。
そうじゃない。今回はそこは動作が変わるのが正しいんだよ。
省10
837(1): (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/16(日)19:25 ID:tfQsIfqsM(1/3) AAS
>>834
どちらもボタンクリックをエミュレートする必要はない
上の例はクリックで実行される処理を順に実行するだけ
下の例はメニューとボタンから同じ処理を呼ぶだけ
838(1): (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/16(日)19:46 ID:tfQsIfqsM(2/3) AAS
>>836
つまりお前が言いたいのは
スクリプティング機能の定石に反する糞仕様こそを求めているので今回に限り馬鹿なことをするのが正しい
ということか
PowerShellは流行ってるというかWindowsのシステム管理ではほぼ必須
OSにプレインストールされてるから開発環境用意するまでもないちょっとしたツールを作るのにも便利
今まさに話してるDSLを手軽に実装するための基盤としてもしばしば使われる
省1
839: (ﾜｯﾁｮｲ 9261-OxJ8) 2020/02/16(日)20:13 ID:lt2wlhEH0(1) AAS
>>796
おいもうそろそろこの話題締めて他所にいってくれや。
840: (ﾜｯﾁｮｲ 167b-4wVb) 2020/02/16(日)20:16 ID:ZkXecQUS0(1) AAS
ふらっと荒らしてこっち荒らして、いつも同じメンバーだろこれ
841: (ｵｯﾍﾟｹ Src7-oFCC) 2020/02/16(日)20:22 ID:+zL5Le7jr(1) AAS
もともと完全にちゃんとＧＵＩ操作したいなんて書いてないだろさ
途中から見てる人が勝手に条件を足してるだけで本来あるべき姿とかい離してる
途中で無駄にリフレクションが出てくるあたり初心者の匂いが出てる
ボタン押すにはタブを切り替えなくてはならないのに
画面が変わらないままでボタン押したいって言ってるから別にＧＵＩ操作自体を再現したいわけじゃない
842(2): (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/16(日)20:24 ID:j/dbz9ZG0(6/8) AAS
>>838
違う。定石に反しているのは君の方で、つまりはカッコイイソリューションを目指しすぎている。
馬鹿みたいなソリューションの方が、現実的に使いやすいことは多々ある。
多分、ちょっと若すぎて元気がありすぎるのだと思う。
これ自体は悪いことではなく、むしろ上達には必須の性格で、良いことだとは思うが、
世の中のアプリがどうなっているか、もう少し周りを見た方がいい。
GUIの自動化で一番簡単なソリューションは、GUIを記録してしまうことだ。…(A)
省17
843: (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/16(日)20:25 ID:j/dbz9ZG0(7/8) AAS
例えば上記アプリ(A)方式だと、ループ機能すらないのだから、
アプリ(A)だけで100個のファイルに同じ処理を適用しようとすると困る。
そこでループ機能を、とか言い出すと色々他が必要になって結局PowerShell、という思想もありだが、
そうではなく、Perl等でファイル名だけ変更するスクリプトを作り、
それでループを回して作ったドベタに展開された糞長いバッチファイルをアプリ(A)に流し込む、
というのもありなんだよ。
全ての処理を自アプリでやろうとするから無理が発生する。
省8
844(1): (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/16(日)20:55 ID:tfQsIfqsM(3/3) AAS
>>842
無知すぎて呆れる
世の中のサービスやアプリをちゃんと見てみろ
APIやCLIをサポートすることは多々あってもGUI操作をサポートしてるものなどごく少数派だ
UIとは読んで字のごとくユーザーのためのインターフェースであって自動化のためのインターフェースではない
APIとはアプリケーションプログラムのためのインターフェースであり自動化をサポートするならこちらを提供するのが当然の選択だ
APIやCLIのサポートが定石であってGUI操作は邪教徒の好む黒魔術でしかない
省2
845(1): (ﾜｯﾁｮｲ c602-ZgUM) 2020/02/16(日)21:13 ID:as0AlWv60(2/2) AAS
>GUIの自動化で一番簡単なソリューションは、GUIを記録してしまうことだ。…(A)
>俺が昔使ったアプリだと、「ログ画面」にGUI操作と等価のコマンドが一々流れる、というのがあった。
>そして自動化したい場合は、このログ画面内の該当部分をコピペしたファイルを読ませるだけ、というものだ。
>当然、見れば分かる程度であり、例えばファイルを読み込んだらそのファイルパスがまんま表示されている。
>なら、そこを変更するだけで同じ処理を他ファイルに適用出来るよね、というわけだ。
これ、昔作ったことが有るけど、最も上手くいった方法はMVCを徹底して、Cの入り口でコマンドオブジェクトをシリアライズして記録するパターンだったな
やってみればわかると思うけど、画面コントロールの操作ログを正確に記録するのも、再生するのも、一筋縄ではいかない
846: (ﾜｯﾁｮｲ 639e-oFCC) 2020/02/16(日)21:16 ID:yo/bSae/0(1) AAS
COMで解決された問題を20年以上経って議論してる・・・
847: (ﾜｯﾁｮｲ 126a-OxJ8) 2020/02/16(日)21:58 ID:5ncsgUM20(1) AAS
この話題をすり替えつつ自分の正当性をゴリ押しするスタイル、最近見ましたよね
明後日くらいには全然違う話題になってるぞきっとｗ
848: (ﾜｯﾁｮｲ 7317-OxJ8) 2020/02/16(日)22:11 ID:x7wMnJYb0(1) AAS
荒らしてるの毎回同じ人だよね
書き方に癖があるからすぐわかる
849(2): (ｱｳｱｳｳｰ Sac3-+wK4) 2020/02/16(日)22:21 ID:Z1hWCcVDa(1) AAS
>>837
繰り返しになるけどね、そういう「プログラマの意図と実際のコードに乖離がある」
ことをやると別の仕事が増えるでしょ。
ボタンABCDEが全部クリックされたのと確実に同じことが起るって誰が確認して保証するの？
ボタンABCDEのクリックイベントの処理を後で変更した時、またそれをやりなおすの？
その確認作業を忘れたらどうするの？
こういう後の保守のことを考えないプログラマは愚鈍で無能。
省4
850(5): (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/16(日)22:40 ID:q02FpFyRM(1) AAS
>>849
プログラマの真の意図は
ボタンを押したら複数の一連の処理をまとめて実行したい
メニューとボタンで同じ処理を実行したい
だろ
君が好きなボタンをエミュレートする方法は上記のプログラマの意図を実現する遠回りなやり方の1つだ
誰が確認するの？確認忘れたらどうすんの？なんて質問は自分は仕事でコード書いたことありませんと言っているようなものだから控えたほうがいい
省7
851: (ﾜｯﾁｮｲ 122c-LiuO) 2020/02/16(日)22:47 ID:5EL9p8ON0(1) AAS
Seleniumデザインパターン&ベストプラクティス、2015、オライリー
この本は、Ruby, Selenium WebDriver でのテスト手法を書いた本
例えば、Ruby, Selenium WebDriverで、
Yahoo への自動ログインするスクリプトは、下を参照
【VBScript】WSHについて話し合うスレ【JScript】
2chｽﾚ:tech
852: (ﾜｯﾁｮｲ 630c-OxJ8) 2020/02/16(日)22:59 ID:jBsklMHb0(1) AAS
そしてさも当然ように混じり込むいつものRubyキチ
853(1): (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/16(日)23:43 ID:j/dbz9ZG0(8/8) AAS
>>844
だから君は意識が高すぎるんだよ。
誰もAPIを欲してないし、スクリプトを書きたいとも思ってない。
GUIを自動化したいだけ。
そして君だって、1つや2つのファイル名の変更は、普通にエクスプローラで行うだろ。
勿論APIは整備されていて、コマンドプロンプトでren fileA fileB と打つだけなのに。
GUIの方が簡単だから、GUIで済む場合はGUIを選択する、これが普通だ。
省15
854: (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/17(月)00:04 ID:afVseoTo0(1/7) AAS
>>845
それがすんなり行くかどうかはアプリの作りによる。
例えば、VSのコンパイル機能は csc.exe へのフロントエンドでしか無く、コマンドラインオプションを作るだけの物ではあるだろ。
こういう場合は至って簡単で、そのまま吐くだけで済む。
上手く行かなかったとしたら、前回の内部状態と混線したのだろうけど、ぱっとは思いつかないね。
普通にアプリを作ってしまえば当然再現性はあり、
どのボタンを押したかをそのまま記録/再生すれば当然同じ結果は生成される。
省7
855(1): (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/17(月)00:55 ID:b+8cPYAUM(1) AAS
>>853
いやいや誰もUI操作を自動化したいとは思ってない
UI操作の背後で行われてる処理を使ってマクロを組みたいんだよ
ユーザーは無知だからUI操作をエミュレートする方法しか思いつかないんだろうけど開発者はそれじゃいけない
俺は名前変えるときでもコマンド打つけどねgit mv a bってさ
つうかそういう話じゃないよ
普段GUIで作業してようがなにしようがオートメーションしたいならGUI操作じゃなくAPIが整備されてたほうが嬉しい
省16
856: (ﾜｯﾁｮｲ b7a7-sep5) 2020/02/17(月)01:21 ID:HQMlSi3n0(1/2) AAS
処理の冒頭だけで途中でメッセージボックスが表示されてさらにユーザの追加入力が必要な処理はこれ使えねぇだろ
まさにゴミだろキングオブゴミだろ
857(1): (ﾜｯﾁｮｲ 634b-cV5V) 2020/02/17(月)11:36 ID:7RiN2OZY0(1) AAS
ThreadPool を使って、非同期に処理を実行しています。
特定のタイミングで ThreadPool に溜まっている処理を全て削除したいのですが、どのようにすればよいでしょうか。
// Threadの登録
ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadMethod));
// ThreadMethod の処理が終わる前に abort させたい
スレ違いなら、誘導してもらえると助かります。
858: (ﾜｯﾁｮｲ f2cf-OxJ8) 2020/02/17(月)12:34 ID:7ui4xGiq0(1) AAS
古すぎるコード
859: (ﾜｯﾁｮｲ ded6-dJav) 2020/02/17(月)13:00 ID:uup53KRg0(1) AAS
>>857
CancellationToken(CancellationTokenSource.Token)
860(3): (ｱｳｱｳｳｰ Sac3-+wK4) 2020/02/17(月)13:25 ID:YCC5nnQ0a(1/2) AAS
>>850
なんか話が噛み合ってないね。
ボタンABCDEを全部クリックしたのと同じことが起るボタンが欲しい、という要件が発生した時、
その責務をモデルに持たせるべきか、むしろUIレベルでやってしまった方がよいかは微妙で
ケースバイケースだと思う。
俺は後者の場合の話をしています。
これまでの流れからそれは自明だと思うけど。
省4
861(1): (ｱｳｱｳｳｰ Sac3-+wK4) 2020/02/17(月)13:37 ID:YCC5nnQ0a(2/2) AAS
まああれだ、ボタンクリックをシミュレートするなんてなんかダサい、という
中二病的な発想は（同意はできないけど）理解はできないでもない
そういう人は「プログラマの意図と実際のコードに乖離がある」 ことの方には気持ち悪さを感じないんだねw
っていうか理解できないのか。>>850の人もそうだと思うけど。
だから、プログラマの意図というか要件は「ボタンABCDE全部が押されたのと同じことを起こすボタンが欲しい」
なんだけど。
862: (ﾜｯﾁｮｲ 1242-OxJ8) 2020/02/17(月)14:03 ID:/fXse39B0(1) AAS
俺なら「ボタンが同時に押されないように作る若しくは押されても一つだけ有効にする」で組む方を優先するわ
863(2): (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/17(月)18:09 ID:qOh2XpnLM(1) AAS
>>860
微妙、ではなくモデルに持たせるのが正解
>>861
中2とか意味わからん理由ではなく実益をとっただけ
理解しやすさ、テスタビリティ、変更への耐久性、等を考えればボタンクリックは、無い
プログラマ意図をコードに反映することは良い習慣だが
判断を誤ったプログラマの意図をコードに反映させることを正当化してはいけない
省1
864(1): (ﾜｯﾁｮｲ ef7b-sg8N) 2020/02/17(月)18:50 ID:q0kZWH/L0(1) AAS
ﾜｯﾁｮｲ 477b-yNzz
ﾌﾞｰｲﾓ MM0e-BzDP
ｱｳｱｳｳｰ Sac3-+wK4
いつまで続ける気だよ役立たずどころかクソ迷惑
865: (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/17(月)19:14 ID:vEzx9LASM(1) AAS
>>864
C#のスレでFormsについて話し合うことの何が問題なんだ？
もともとはVC++だったけどこの話題はC#でも通じる話だからここで話してもなんの問題もないはずだ
866(1): (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/17(月)19:45 ID:afVseoTo0(2/7) AAS
>>855
まあ君がどうしてもPowerShell推しなのはわかった。
> UI操作するオレオレDSLなんてまあバグだらけだろうな
それはオレオレDSLに無理に高度な機能を持たせすぎてるから。
つるんと書かれたDSLをただ上から順番に実行するだけ、しかもエミュレーションの時に、
何行のコードを追加し、何行の既存コードを変更する必要があると思ってるんだ？
面倒だから答えを言ってしまうが、追加が30-50行程度、既存変更は0行、つまり変更無しだ。
省9
867: (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/17(月)19:46 ID:afVseoTo0(3/7) AAS
あと、PowerShellにこだわりすぎて、強力なDSLなんてPowerShellでしか得られないと思ってないか？
気づいていないんだろうけど、「テキストファイルで操作する」というのはUnixのAPIであって、
そこに揃えるだけでUnix周りのツールが全て使えるようになるんだよ。
具体的に言うと、DSLソースをファイルではなく標準入力とすれば、
(一応言っておくがC#等GUIアプリもコマンドラインから起動すれば普通にパイプできる)
その前段のツールが標準出力に「CONTROL Button instancename Click」と吐きさえすれば自動化できるのだから、
PowerShellみたいな糞文法につき合う必要もなく、言語も選べる。当然、C#やPythonも使える。
省7
868(1): (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/17(月)19:47 ID:afVseoTo0(4/7) AAS
>>860
一応調べてみたが、この場合は微妙だし、どっちでも良いと思う。
> 外部ﾘﾝｸ:hinative.com
> 外部ﾘﾝｸ:xcelgo.com
要は、中身まで模倣するのがemulationで、外面だけ合わせるのがsimulation。
よって実行速度は通常simulator>>>emulatorになる。
void Button_Clicked(Object^ sender, EventArgs^ e) {
省21
869(1): (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/17(月)19:49 ID:afVseoTo0(5/7) AAS
余談だが>>850のUIテストが安定しないのはこの辺が大きい。
要は、GUIなんて所詮人間相手前提で組んであるのであって、
CPUの速度でイベントを積まれた場合にも正しく動くレベルまでのテストは為されていない事も多い。
技術的に見ればアプリが糞で組み方が悪いだけだが、そこまで保証する意味もないのも事実。
結果、「人間がやると動くが、CPUでやると動かない」なんてのは割とよく遭遇することになる。
だからまあ、「UIテストは安定しないから出来るだけ回避」も一つの戦術だが、
「UIテストも安定するようにちゃんと設計する」も一つの戦術なんだけどね。
省7
870(1): (ﾜｯﾁｮｲ 1fad-z23p) 2020/02/17(月)19:55 ID:Nkb49BjE0(1) AAS
議論が発散しててよくわかんないな。
何が何なの？全員、アブストを書いたらどうだ？
871(1): (ﾌﾞｰｲﾓ MM32-BzDP) 2020/02/17(月)19:56 ID:iNM+ZupGM(1) AAS
>>866
論点をずらそうとしてるね
クソみたいなUI操作オレオレマクロよりUI非依存のPSのが低コストで品質がいいねというだけの話だろ
例としてPSを出したが別になんだっていいよ
最も大きな問題はインタプリタの方ではなくUI操作でオートメーションサポートするというバカバカしい発想の方な
オートメーションをサポートするならUI非依存のAPIを整備しろ
それが正しい道だ
872: (ｽｯｯﾌﾟ Sd32-3blX) 2020/02/17(月)20:21 ID:YeNwIpPfd(1) AAS
話がまとまってないのに余談とか言っちゃって相手もそれに乗っかちゃって…
これを繰り返すからいつまで経っても収束しないし元の議題が何だったかわかりづらくなる
873: (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/17(月)20:24 ID:afVseoTo0(6/7) AAS
>>860
>>868訂正、結果的に>>869は間違いなのでよろしく
俺の見解では全部simulationになる。
確認してみたら、PerformClickは同期イベントだった。
呼び出し履歴見る限り、Button.PerformClick->Button.Onclick->Control.OnClick->イベントハンドラ なので、
OnClickもほぼ確実に同期だと思われる。
だから呼称は全て simulation の方が妥当となる。
省4
874(1): (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/17(月)20:40 ID:afVseoTo0(7/7) AAS
>>871
> 論点をずらそうとしてるね
お前がだろ。
> UI操作でオートメーションサポートするというバカバカしい発想の方な
GUIの自動化ならGUIのエミュレーションが俺的に第一選択肢だ。
これについては既に>>842で言ったとおり、君が気に入らないのはどうぞご自由にだが、
最近話題のSeleniumでも同様なのだから、君が思うほど糞でもないんだよ。
省3
875(1): (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/17(月)21:41 ID:zVw4OscHM(1/5) AAS
>>874
Selenium系はAPIを提供してないサイトのオートメーションをユーザーが苦労して泣く泣く自動化したい場合やテスト自動化で使うツールな
俺らが今議論してるのはユーザー目線じゃなくて提供者側なんだよ
提供者側がAPI実装を放棄してGUI操作をサポートするなど馬鹿なことだ
ユーザーに苦労を押しつけてはいけない
876(2): (ｱｳｱｳｳｰ Sac3-+wK4) 2020/02/17(月)21:45 ID:HH3Dtgxka(1/5) AAS
>>863
複数のボタンを全部クリックした時の動作、なんていう下らない機能を
モデルに持たせることが正当化されるケースってむしろあんまりないと思うよw
ぱっと思いつくのは、ボタンABCDEをクリックした時の処理に共通する部分
（例えばファイルのopen/closeのような前処理後処理）があって、まとめてやる場合には
大幅な最適化が可能な場合。
この人本当にプログラマかな。
877: (ｱｳｱｳｳｰ Sac3-+wK4) 2020/02/17(月)21:49 ID:HH3Dtgxka(2/5) AAS
>>870
白鳥はすべて白い（PerformClickなんて100%ｲﾗﾈ）という人がいるので、
いやいや世界には黒い白鳥もいるんだよ、とまあそういう話
878(1): (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/17(月)22:01 ID:zVw4OscHM(2/5) AAS
>>876
その糞設計だと要件変化ですぐにコードが汚染されるだろうなぁ
処理は今までどおり実行したいが特定のボタンだけ画面から削除したくなったせいで謎のHiddenボタンを置いたり
処理の結果で後続の処理を分岐したくなったせいで不自然な制御フラグフィールドが乱立したり
画面のデザイン変えただけなのになぜか処理の実行順序が変わったり
少し想像しただけでトラブルの兆しがするするでてくる
こういう発想はアマチュアらしくて微笑ましいけど業務で見かけたら説教しなきゃいけないぐらいだ
879: (ﾜｯﾁｮｲ 932c-VKUZ) 2020/02/17(月)22:05 ID:dzSo2/zk0(1) AAS
>>863
各ボタンに割り当ててるコマンドをcomposite Commandで繋いで終わりじゃない？
880(1): (ｱｳｱｳｳｰ Sac3-+wK4) 2020/02/17(月)22:08 ID:HH3Dtgxka(3/5) AAS
>>878
よく分からない妄想ワロタw
意味が分からないよ
＞要件変化ですぐにコードが汚染される
まさにその通りw
君の設計方針だと必然的にそうなる。
881(1): (ｱｳｱｳｳｰ Sac3-+wK4) 2020/02/17(月)22:09 ID:HH3Dtgxka(4/5) AAS
どーでもいい非必然的な機能をモデルに持たせることは、
UIにベタベタ処理を実装するのと同じ糞設計ですw
882(1): (ｱｳｱｳｳｰ Sac3-+wK4) 2020/02/17(月)22:28 ID:HH3Dtgxka(5/5) AAS
一応言い訳しておくけど、>>876に書いたみたいに最適化の恩恵なんかなくても
複数の処理をまとめて一度にやるメソッドをモデルが持つことが自然なケースはもちろん存在すると思う。
っでも俺が言っているのは「黒い白鳥もいる」だからね。
「白鳥は全部白いは間違っている」と言ってるだけだから
883: (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/17(月)22:56 ID:zVw4OscHM(3/5) AAS
>>880
お前のやり方はではすぐにコードが汚くなるって言ってんの
俺のやり方はメンテナンスしやすいモデルを採用してるからコードの品質が維持される
884: (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/17(月)23:01 ID:zVw4OscHM(4/5) AAS
>>882
まとめて処理をする機能が要件にあるならそれをモデルに実装するのが王道で自然な方法
お前はそれをボタンクリックなどという大道芸的な方法で実装しようとしてる異端
885: (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/17(月)23:03 ID:zVw4OscHM(5/5) AAS
>>881
そうだ
だからまとめて処理をするという最小限の機能をモデルに実装せよと言ってる
ボタンクリックなどという余計なお遊びは入れなくていい
886(1): (ﾜｯﾁｮｲ b7a7-sep5) 2020/02/17(月)23:09 ID:HQMlSi3n0(2/2) AAS
こない未来を予測してる奴はバカ
絶対失敗する
しかも、最悪の形で
887: (ﾌﾞｰｲﾓ MM0e-BzDP) 2020/02/17(月)23:18 ID:43uLIzGsM(1) AAS
>>886
来るかもしれない未来を考えないのも同じぐらい馬鹿だな
そして未来がわからんなら余計な拡張性を導入するのではなくコードを容易に改修できるようにシンプルに保つことが重要
つまりシンプルなモデルにやりたいことを素直に書けばそれでいい
それで済むものをわざわざボタンクリックなんていうやらなくていい遠回りな方法で実装するのは後で困る馬鹿の典型例
888(4): (ﾜｯﾁｮｲ 477b-yNzz) 2020/02/18(火)00:50 ID:/0BlMKgF0(1) AAS
>>875
だから君はちょっと意識が高すぎるんだよ。
自動化したいユーザーは、今やったのと同じ操作を100個のファイルに適用したいとかだ。
「ログに出てるコマンドをコピペすれば今やった操作を自動化出来ます」との情報を得て、ログを見たら、
CONTROL TextBox filename my000.jpg
CONTROL Button file_load Click
CONTROL Button filter_A Click
省12
889(1): (ﾜｯﾁｮｲ b7a7-sep5) 2020/02/18(火)00:57 ID:GPdxsdEp0(1) AAS
>>888
だからよ
1処理用の処理を連続で100回動かしたら確認ダイアログが100回出るだろーが
バカかテメーは
890: (ｱｳｱｳｳｰ Sac3-I9Fa) 2020/02/18(火)06:52 ID:fxDAJd/Ea(1) AAS
言い合いになるなら
構わなきゃいいのになあw
891: (ﾌﾞｰｲﾓ MM32-BzDP) 2020/02/18(火)07:50 ID:LkwV7cyFM(1/3) AAS
>>888
意識は高くない普通の感覚だよ
当たり前のことを当たり前にやるだけだ
モデルに処理を書いてビューに紐付けるってごくごく自然なコードだろ
しかもそれすればほとんどタダでオートメーションサポート機能が手にはいるんだぞ
ボタンクリックとかわざわざ苦労してトラブルを持ち込んでくる意味わからねえわ
マゾなのか
892(1): (JP 0H6e-1vH+) 2020/02/18(火)07:59 ID:ZOlvaa/TH(1) AAS
>>889
その程度の回避策が思いつかないようなバカがいるとは
893(2): (ﾌﾞｰｲﾓ MM32-BzDP) 2020/02/18(火)08:20 ID:LkwV7cyFM(2/3) AAS
>>888
ちなみにこのマクロでわかりやすいと思うのはお前だけだぞ
普通の人だったら
オートメーションなのなんでコントロールを操らないといけないんだ意味わからん
ボタンとかテキストとか書かれても何やってるか意味わからん
各行の関連性が意味わからん
操作してるインスタンスはどのフォームだよ意味わからん
省9
894: (ﾜｯﾁｮｲ 63de-sep5) 2020/02/18(火)08:23 ID:didWPBin0(1) AAS
>>892
そこ工夫が必要ならこんなくだらんメソッド呼ばんわｗ
895(1): (ﾌﾞｰｲﾓ MM32-BzDP) 2020/02/18(火)08:43 ID:LkwV7cyFM(3/3) AAS
>>888
例えばさぁ
お前のオレオレうんこマクロでファイルが存在しなかった場合のハンドリング処理はどうやって書くつもりなんだ？
ファイルの形式が間違ってた場合は？
セーブに失敗したときどうする？
指定したディレクトリツリーのファイルすべて処理したいときはどう書くんだ？
896(1): (ﾜｯﾁｮｲ 167b-4wVb) 2020/02/18(火)21:08 ID:U5rnBvKT0(1) AAS
直のWINAPI（というか多分アンマネージ）が混ざる動作だとDebugとReleaseで動き変わること割りとあってめんどくさいな
897: (ﾄﾞｺｸﾞﾛ MM47-P13C) 2020/02/19(水)07:47 ID:bztKe272M(1) AAS
>>896
単なるお前のバグだろ
898: (ﾜｲｰﾜ2 FFdf-IPX/) 2020/02/19(水)11:28 ID:cGULNOoWF(1) AAS
WINAPIのはDebugだと0埋めされるんだろ
そりゃ動作変わるって(バグがあればω)
上下前次1-新書関写板覧索設栞歴
あと 104 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.029s