画面上に並べる部品数に比例して難解至極な計算式が羅列されるのですらか、もう「めまい」が してきます。
こういうコーディングしていて、画面上のレイアウト調整はどうしたのかと思ってしまいます。 ウィンドウの数は50個くらいありましたから、全体の並びの感じを変更なんていったら、この複雑 怪奇な式をいじって調整ってことになるのでしょうか。少なくとも、ここまで開発するまでにも当 然相当の試行錯誤や調整があったはずです。
たとえソースが公開されても、このくらい複雑に書いていれば、完璧なプロテクトです。こうい うのを、「オープンなブラックボックス」とでも言ったらいいのでしょうか。
ウィンドウシステムになってから、アプリケーションもより対話的になり、メッセージやボタン などの配置に凝るようになりました。単なる位置調整くらいで済めば、このようなコーディングで も対応できるかもしれませんが、後から、追加や削除、さらには配置順序の全面的な入れ換えなど も珍しくなくなりました。できあがって実際に使ってみてから、より使いやすい配置に直していく ことが多くなりつつあります。このような場合に、このようなプログラムはどうするのでしょうね。 考えただけで気が遠くなります。
ウィンドウ上にボタンなどを並べたいとき、このような位置計算をしなければウィンドウ対応の プログラムが組めないなんてことはありません。どちらかというと、何も書かなくても、標準的な 並べ方をするのであれば、どのウィンドウシステムでも一個一個の要素位置は自動配置してくれま す。そうでなければ、誰もウィンドウシステムなど使えないでしょう。
たとえば、チェックボックスは、x座標を指定しなければ、重ならないように等間隔に水平に並 びます。これでも気に入らない場合だけ指定するのが普通ですが、この人達はどうもウィンドウシ ステムを信用していないようで、すべてを自分でやりたがっているように思えます。
この場合、PANEL_CHOICE_XSとPANEL_CHOICE_YSの指定が不要になります。x方向だけではなく、y 方向も、普通にコーディングしていれば、他の物と重ならないように自動調整してくれます。
位置調整以外に、表示メッセージの変更も多発します。このプログラムでは、一見、文字列を全 然使用していないように見えますが、実はマクロとして山のように使っています。メッセージはヘッ ダーファイルにまとめられていたのですが、これがくせ者なんです。メッセージを変更する度に、 ほぼ全てのファイルを再コンパイルになります。これでは、いくらコンピュータが高速になっても 全然効率は上がりません。
そもそも、プログラム中に、直接にせよ、マクロを通して間接にせよ、文字列を書くなんてこと をしては、せっかく多国語対応ウィンドウを提供されても、多国語対応ソフトはできません。
プログラム中ではなく、何らかのファイルに文字列を用意しておき、必要なつど、あるいは起動 時などに読み込んで使うようにすれば、簡単に多国語対応ソフトができます。もちろん、カスタマ イズも容易です。お客さんのいる前で、「ここはこんな感じでどうでしょう。」とか言いながら、 さまざまな調整、確認をしていきたいものです。ある程度の変更はコンパイル不要で、定義ファイ ルのような物の変更だけで、その場でできるのが常識でしょう。UNIXに限らず、パソコンの世界だっ てそういうのはいっぱいあるでしょうに。