route127の日記: RUNしようVBA 4
Excel VBA製の業務システムに触らないといけなくなった。
帳票を打ち出す為に、「指定セルに記号列打ち込んでコマンドボタンを押下」という作業を10回以上繰り返さないといけない上、クリック毎に本部との通信で10数秒位待たされる、と聞くに至っては流石に付き合い切れないな、とperlで自動化スクリプトを書き始めた。
セルの値を読み書きする程度ならWin32::OLEの練習問題レベルなのだが、ワークシート上のボタン押下シミュレートとかユーザーフォームとか出てくるとちょっと難易度が高い。
幸い先人によるVBAでの蓄積があるのでそれを利用させてもらうことになるのだが、それでもシート上にチェックボックスの処理なんかは(自分にとっては)難しい。
(隠しオブジェクトのCheckBoxesを使うかShapeオブジェクトのControlFormatを使うかとか)
そういえばWebスクレーパでもチェックボックスは苦手にしていた。
シート上のActiveXコントロールについては一時はWin32::GuiTest使ってパチポチやろうかとも考えたけれども、結局ボタンは関連付けられてるプロシージャ(Button1_Click等)名をRunメソッドに渡すこととした。
プロシージャ名のあたりを付けるのにボタンを含むシート上のシェイプを列挙させたりしていた。
my $sheet = Win32::OLE->GetActiveObject("Excel.Application")->Worksheets('ほげほげ');
foreach my $num (1..$sheet->Shapes->Count){
my $shape = $sheet->Shapes($num);
print "Name: ", $shape->Name, "\tTop: ", $shape->Top, "\tLeft: ", $shape->Left, "\n";
}
今回は出番なかったけれどもユーザーフォームにもWorkSheetsのきょうだいにあたるVBProject以下に収まっているらしくVBAからボタン配置等色々弄れたりはするらしい。
そんなのを読んでると(Win32::LoftとかTk用のZooZのような)GUIビルダとしてもVBAが使えるのではないかという気がしてくる。
その内容なら (スコア:0)
変にperlとか使うより、VBA(の機能追加)で完結させた方が良い気がする。後々のメンテ性を考えても。
Re: (スコア:0)
ほんとこれ。
たったそれだけのことをするのにわざわざperlを使う意味がわからない。
Re: (スコア:0)
同感。
違う環境で動かす必要が出来たとき、perl必須にしていいの?
Re: (スコア:0)
うちに所属する社員か協力会社さんなら、教育的指導するレベルの悪対応ですよコレ。
この対応後に、仮にメンテを外部に委託することになったら、今まではVBAのスキルを持つ人材を募集すれば良かったのに、VBAとperl両方のスキルを持つ人材を見つけなきゃいけなくなるし、当然スキル分の単価も上がる。
マネジメント的視点を持たない、技術者のオナニーだなぁ。