久しぶりにExcel/VBAのソースを弄りました。旧VB系の言語は４、５年前までは、さんざん使っていたのに、.NET系に移行して馴染んでしまうと、綺麗さっぱり忘却するものです。便利機能に接すると不便な面は忘れるのが習性なのかもしれない。
不便な面は忘れて、綺麗な面だけが記憶に残るから、過去を美化する....(脱線しそうなので元に復帰)
Objectの扱いが、如何に不便だったか、改めて感じたしだい。
Excelの画面に TextBoxが貼り付けてあり、入力補助画面を開いて、そのTextBoxに値を戻すという、ありきたりなモノですが、入力画面にTextBox.Objectを渡す部分が、巧く動作しない。
入力画面.元CONTROL = 親.TextBox1 では コントロールobjectを引き渡しできないのは、朧気ながら覚えていました。
set 入力画面.元CONTROL = 親.TextBox1 で可能だろうとやってみると、TextBox1.valueの内容値しか移らない。
Default propertが働くのだっけ? Setは objectの代入できた筈なのに....
よくよく、思い出すと,, Set Property を作り set 入力画面.元CONTROL = Find.Controls("TextBox1") のような事をした記憶がある。
過去ソースをあぶり出して、確認。そのように実装してました。
Set構文が必要なのと、Default Proopertが余分な動作してたのですね。今からみると、不思議な記述をしていたものです。
私の中では、旧VBや VBAは過去のモノと認識しているため、完璧に脳の非活性化領域に追いやられてます。
しかし、現実の現場では、VBAは現役で、ますます、VBAアプリも増産されています。それに伴って、VBAプログラマも育成されています。コンパイラ言語としての旧VBは過去遺物になりつつありますが、 VBAは Officeが残る限り、続きそうな感じ。
VBAの不便さを感じた分、NET系言語の便利さが余計実感できます。 Framework1.1にも、戻れないのに。
VB6が出てきた当時は、VB4/5と「おさらば」できると喜んでいたのをふと思い出しました。人の思いは留まらないし戻れないと言うことかもしれません。
当面は、VBAのお仕事にも対応できるようにしておかないといけないのかなぁ。