C#, C♯, C＃相談室 Part95

[過去ﾛｸﾞ] C#, C♯, C＃相談室 Part95 (1002ﾚｽ)
上下前次 1-新
通常表示 512ﾊﾞｲﾄ分割ﾚｽ栞

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

797: デフォルトの名無しさん (ﾜｯﾁｮｲ 477b-yNzz) [sage] 2020/02/15(土) 13:10:05 ID:M9LrwgB50

※１
書いてあることとはこちらの状況と合致しているわけでもないが、とにかく見えてないとPerformClickは動作しない。
> TabControl.TabPages コレクションに少なくとも1つの TabPage が含まれている場合
>  (Click、DoubleClick、MouseDown、MouseUp、MouseHover、MouseEnter、MouseLeave、MouseMove)、
> TabControl クラスでは、次のイベントは発生しません。 コレクションに少なくとも1つの TabPage が存在し、
> ユーザーがタブコントロールのヘッダー (TabPage 名が表示される) と対話する場合、
> TabControl は適切なイベントを発生させます。
> ただし、ユーザーの操作がタブページのクライアント領域内にある場合、TabPage は適切なイベントを発生させます。
> https://docs.microsoft.com/ja-jp/dotnet/api/system.windows.forms.control.click?view=netframework-4.8
自動翻訳がイマイチなので英語も。
> The following events are not raised for the TabControl class unless there is at least one TabPage in the TabControl.
> TabPages collection: Click, DoubleClick, MouseDown, MouseUp, MouseHover, MouseEnter, MouseLeave and MouseMove.
> If there is at least one TabPage in the collection, and the user interacts with the tab control's header (where the TabPage names appear), the TabControl raises the appropriate event.
> However, if the user interaction is within the client area of the tab page, the TabPage raises the appropriate event.
> https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.control.click?view=netframework-4.8

http://mevius.5ch.net/test/read.cgi/tech/1508168482/797

823: デフォルトの名無しさん (ﾜｯﾁｮｲ 477b-yNzz) [sage] 2020/02/16(日) 11:26:32 ID:j/dbz9ZG0

>>819
まあその「俺のプログラムが一番だ」という姿勢は俺は嫌いではないし、
むしろプログラマは全員持つべきだとも思うけども、
動的結合の価値（意味）が分からないのなら、まずはそこを理解した方がいい。

現在、Clickイベントをエミュレーション出来ないGUIフレームワークなんて、存在してない。
リフレクションも割と一般的になりつつある。(常用するのはどうかとも思うが)
だから、使いどころはあるんだよ。
静的結合だけでやれ、みたいなのは言ってしまえばC++がそうだが、それでもRTTIは検討されている。

動的結合の価値は>>816も書いてくれているが、同様に以下でも触れられている。(これらだけでもないが）
https://www.atmarkit.co.jp/fdotnet/dotnettips/270performclick/performclick.html
言ってしまえば「実行速度を捨てて保守性を採る」わけであり、これが適切かどうかは状況によるので、
PerformClickやリフレクション等を使うこと自体が間違いだ、というのはさすがに行きすぎてる。
(なお既に言ったが、速度至上主義のC++は割とそういう思想だし、これも間違いでもないが）

ただそれはさておき、PowerShellは使ったこと無いから調べてみたが、確かに面白いものではある。
ポイントは、.NETオブジェクトをインスタンス化出来ることと、それらをパイプで流せる点か。
>>815を見る限り、C#等CLRな物ならリフレクションで内部の関数をぶち抜いて、自在に呼べるのか！
(名前があやふやだが確か）COMでも似たようなことをしていたMSならあり得るか！とも思ったが、
そうではなくて、自分で.NETクラスをインスタンス化して呼べるだけか？
まあそれでもリフレクションを使えば何でもありにはなるし、
.NETを使うだけで本式のバッチスクリプト環境が自動的に提供されてしまう、というのは画期的ではある。
ここら辺はMSの上手いところだとは思う。

http://mevius.5ch.net/test/read.cgi/tech/1508168482/823

842: デフォルトの名無しさん (ﾜｯﾁｮｲ 477b-yNzz) [sage] 2020/02/16(日) 20:24:37 ID:j/dbz9ZG0

>>838
違う。定石に反しているのは君の方で、つまりはカッコイイソリューションを目指しすぎている。
馬鹿みたいなソリューションの方が、現実的に使いやすいことは多々ある。
多分、ちょっと若すぎて元気がありすぎるのだと思う。
これ自体は悪いことではなく、むしろ上達には必須の性格で、良いことだとは思うが、
世の中のアプリがどうなっているか、もう少し周りを見た方がいい。

GUIの自動化で一番簡単なソリューションは、GUIを記録してしまうことだ。…(A)
俺が昔使ったアプリだと、「ログ画面」にGUI操作と等価のコマンドが一々流れる、というのがあった。
そして自動化したい場合は、このログ画面内の該当部分をコピペしたファイルを読ませるだけ、というものだ。
当然、見れば分かる程度であり、例えばファイルを読み込んだらそのファイルパスがまんま表示されている。
なら、そこを変更するだけで同じ処理を他ファイルに適用出来るよね、というわけだ。

冷静に考えれば分かるが、Unixのshもこれと同様だ。（というより上記方式がshのパクリだが）
shもhistoryで出てくる履歴をコピペすればバッチファイルになるようになっている。
そして必要なら該当部分を変数化してループを回せ、ということでしかない。

俺は使ったことないけど、Webブラウザの自動化ツールとして有名なSeleniumも以下見る限り似たようなもんだ。
https://www.valtes.co.jp/qbookplus/509

だから、初段階のスクリプト環境はこの程度でいいし、実際、この程度でも相当有益なんだよ。
そしてそれを手っ取り早く実装する方法がGUIのエミュレーション(PerformClick等）になる。
だから、
> 自社アプリにオートメーションサポートを実装するための基盤ではない
これはちょっと意識が高すぎる。（気持ちは分からなくもないが)
PowerShellでオートメーション、というのはその先の先の先位で、
初期段階に於いては超オーバースペックでしかない。
そして殆どのアプリでは最終的にも必要としない。

http://mevius.5ch.net/test/read.cgi/tech/1508168482/842

上下前次 1-新書関写板覧索設栞歴

あと 150 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.016s