「職場のパソコンでマウス操作やキーボード操作を自動化する」のは UWSC だったらよかったのにという話【UWSC】

「職場のパソコンでマウス操作やキーボード操作を自動化する」
「職場のパソコンでマウス操作やキーボード操作を自動化する」という記事を読みました。2021年頃の記事です。

毎年特定の時期、社内システムにひたすらデータを入力する作業を延々と繰り返す業務があり、入力操作を自動化した方の話のようです。

前提条件として、既存の自動化ツールの使用は無し。ほぼ素の状態のWindowsパソコンで、操作自動化を目指し、WindowsPowerShellでマウス操作およびキーボード操作を所定の順番で行うスクリプトを作成、自動化に成功したがいくつか課題も残ったとのこと。

情報システム部門に既存の自動化ツールの使用の許可を求める方法はなかったのかなと思いつつ、UWSC だったらという考察をしました。

座標指定を必要とする画面での座標の変化による影響
座標を使っての指定が必要な画面の場合、この影響は避けられないですね。
また指定に座標を必要としない画面では基本的に影響を受けないのですが、逆に見た目は変わらないのに内部的な処理が変わった影響を受けるという場合もあります。

BTN(LEFT,CLICK,100+STATUS(ID,ST_X),100+STATUS(ID,ST_Y),40)	//座標指定の場合
CLKITEM(ID, "ボタン名", CLK_BTN)	//クリックアイテム指定の場合
getstr(id,1,STR_EDIT)	//番号指定の場合

編集ボックスの番号で指定している場合など、編集ボックスの位置が変わらなくても、番号を変えられてしまうと取得される内容が変わるという場合があります。

例外的な処理の影響
これは、例外処理の設計で対処できます。

IF POS("例外のタイトル",STATUS(GETID(GET_ACTIVE_WIN),ST_TITLE))>0 THEN
CLKITEM(GETID(“例外のタイトル”),”OK”, CLK_ACC or CLK_MUSMOVE)
id=getid("元のタイトル",-1)
ENDIF

例：特定の条件でのみダイアログが表示されるケースなど、アクティブ画面が例外のタイトルを含んだ場合だけ、例外の画面で「OK」を押下して、元のタイトル画面に戻るような処理ですね。
 
処理時間の影響
これは、待機処理の設計で対処できます。

REPEAT
SLEEP(0.03)
UNTIL getstr(id,0,STR_ACC_STATIC)="DB更新成功しました。" OR _
chkbtn(id,"ボタン名",1,FALSE)=0 OR _
POS("元のタイトル",STATUS(GETID(GET_ACTIVE_WIN),ST_TITLE))=0

例：特定の文字列が出現したり、「ボタン名」が消失したり、アクティブ画面が「元のタイトル」ではなくなるのを待機したりします。

何が起こるかわからない
これは、充分なサンプルデータによるテストが実現できない場合、必ず未知のエラーに遭遇する可能性があります。必ずしも充分なサンプルデータによるテストが実現できる場合ばかりではありませんので、都度の対処が必要だと思います。

UWSC でやったら、こんな感じになるのではないかと思います。

「誰もが無料でWindows自動化を始め、生産性を向上し続けられるようにする」