質問じゃないですけどご意見聞きたいです
解決みなさんはVB6で開発するときに、各々のコントロールのプロパティを設定すると思いますが、プロパティウィンドウで設定するかソースにプロパティの設定を記述するかどちらかですが、どちらの方法を使用していますか？私はソースに記述する場合が多いのですが(理由はあとでソースを見たときにコントロールの設定もよくわかるから)、みなさんの意見をお聞きしたいです。また理由等も教えてもらえると嬉しいです。
テキストボックスの例：
プロパティウインドウでAlignmentの項目の「1 - 右揃え」を選択する。
もしくは
ソースコード内に'Text1.Alignment = 1'と記述する。
ユーザの操作、動作によって
変更の可能性のあるプロパティについてはソースに記載、
変更の可能性のないプロパティについては、
プロパティウィンドウに記載します。
ほぼプロパティウィンドウで設定しています。
#課内でしか使うようなモノばかりで、
#変更はほとんどないというのが前提で、、|'_';
なるほど・・・変更の有無によって使い分けているのですね。
ご意見ありがとうございます。
他にもご意見ある方、よろしければ書き込みお願いします。
変更をしないプロパティを全部かいていたら、
冗長になってしまうよねぇ〜。
以前、オブジェクトを全てソースで一個一個ロードして
っていうプログラムを見たけれども、デバッグ大変でした。
サイズとかはプロパティで変えたりしてますが、
デザイン(サイズ、位置)以外は既定値から変えるときはコードで変更しています。
ずっと固定の物はプロパティですね。
ただし、サードパーティ製のコントロールで「将来他の製品に乗り換えるかも」というものはコードに書いています。
プロパティはコントロールが使用できない状態だと見れませんがコードはコントロールを削除しても残ります。
# 16bitから32bitへの移行の際に32bitで廃止されたコンポーネントで痛い目に遭いました
＞ななしさん
たしかに冗長になってしまいますね。
私はコントロール配列をなるべく使うようにして
ループで処理してそうならないように心がけています。
＞ぶぶさん
よろしければ理由も教えてもらえると嬉しいです。
＞ひろさん
やはり固定のものはプロパティウインドウを使う方が多いようですね。
参考になります。
>よろしければ理由も教えてもらえると嬉しいです。
ほかの人が組んだプログラム等見るとき、ひとつひとつのコントロールのプロパティをみて、どこが変更されているか調べるよりも、コードに記述すれば、
わかりやすいからです。(当然既定値のものは省かないと意味ないですけど)
特に変えるのはVisible とか Enabled とか Grid系だと、Rows とかColsとか
明記しておくと流れもわかりやすいからです(^^;
＞ぶぶさん
ご返答ありがとうございます。
ほとんど私と同じような理由ですね。
プロパティの種類によってもどちらにするか変わるのですね。
>よろしければ理由も教えてもらえると嬉しいです。
大量のプロパティを持つコントロールや、プロパティの数自体が本質的に不定（グリッド系のコントロールの各列の設定等）の場合、プロパティは .frm ファイルだけではなく .frx ファイルにも保存される事が多いのですが、frx ファイルの内容はその製品のデザイン画面でしか表示できません。
つまり、コントロールの開発環境が動作する環境で目視で確認する以外にプロパティを見る方法がありません。
コードなら流用とか共通化も出来ますが frx はそういうことが一切出来ない上に、frmに記録されたプロパティと異なりWindiff等で比較しても何が違うのか全くわかりません。
これは特にメンテナンス性の面で大いにマイナスです。
＞ひろさん
たしかにfrxファイルはエディタ等では内容が確認できないですね。
貴重なご意見ありがとうございます。
私も変更の可能性が無いもの、仕様で固定になっているものはプロパティウィンドウですね。フラグや保持データで表示が切り替わったりする場所やグリッドの列幅調整はコード上です。
ただし、数値型のプロパティの場合は直接数値ではなくて出来るだけ定数や列挙型定数（名称があやふやなので間違ってたら遠慮なく御指摘下さいorz）を使用する様にしています。後から見てわかりにくいのは嫌ですし。コントロールを自作する時も出来るだけ列挙型の値を作成してそれで設定させるようにしています。
出向先で作るオーダーソフトのプログラミングばっかりだったのでコンポーネントが変更になることはあまりなかった人間の意見です（追加は多々ありましたが）今では他の人が作ったソースを見てバグ修正をかけたりする事が多いのですが、確かに全部プロパティウィンドウで設定されていたソフトは非常にメンテナンスしにくくて困りました。
#自作コントロールを多用したソフトの時は出来るだけコメントで説明を
#つける様にコーディング規約が出向先の社内で決められていた記憶が。
> #自作コントロールを多用したソフトの時は出来るだけコメントで説明を
> #つける様にコーディング規約が出向先の社内で決められていた記憶が。
あるプロジェクトでは
VBPの構成に、関連ドキュメントとして説明書きを
追加するように・・・。というようなところもありますよね。
＞那岐さん
ご意見ありがとうございます。
＞定数や列挙型定数
Const 等ですね？
ちなみに、処理速度の面からのアプローチで
ご意見のある方がいらっしゃると参考になるんですが、
いらっしゃるならば、よろしければ書き込みお願いします。
>処理速度の面からのアプローチ
えっとでは、
処理速度の面から・・・。ということでは、
実際問題。
初期値などをコードで設定する
プロパティで値を設定するという差異は、
FormのLoadや他の処理に比較して、
誤差と感じるような微々たる物ではないでしょうか？
余り性能比較を行ったことはありません。
>処理速度の面からのアプローチ
グラフや表の生成の場合だと、結局貼り付けるべきデータの読込と貼付けが一番遅くて、それに比べたらプロパティ設定の処理時間なんか微々たる物です。
ということでほとんど気にしていません。
＞ななさん、ひろさん
ご意見ありがとうございます。
ただ、
Text1.AlignmentのようにChangeイベントを発生させるプロパティがあるので
処理速度低下がすこし気になりました。
どの程度下がりました？
＞どの程度下がりました？
Changeイベントで命令する処理内容と、Alignmentプロパティを設定するコントロール（配列）の数によって変わると思うので計測はしていませんが、
当然一回のイベントでステップ数が多いとそれに比例するのではないかと
思いましたが、それについて明確な見解がある方がいらっしゃれば幸いかと
思い上記に書き込みした次第です。
>Text1.AlignmentのようにChangeイベントを発生させるプロパティ
私はForm_Loadで実行する初期化やChangeイベントの中のテキストの整形（私的にあまり好きではないですがそういう風に組まれる方もいらっしゃるので）等の時は処理中かどうか判別するフラグを立てて処理中にイベントが発生したら抜ける分岐を組んでます。
でないと無限ループに入ってハングアップしたりしませんか？
初期化の時はわざわざ処理する必要も無いような気もしますし。
>処理速度の面からのアプローチ
そういえば数年前、一画面に300個程のコントロール（主にShapeとLabel）を貼り付けて初期化（フラグがONなら■OFFなら□にBackColorとBorderColorを変える）をコードで記述して行いましたが想像していたほどの違いはなかったような。そういう仕様かつ客先からの要求だったとはいえ、我ながら無茶なプログラムを組んでいたなぁと思います。
＞那岐さん
無限ループというのはChangeイベントの中にChangeイベントを発生させる
処理があるということですか？
一画面に300個のコントロールは圧巻ですね。
BackColorとBorderColorのプロパティでイベントが発生していたら大変でしたね。
>Changeイベントの中のテキストの整形
これが
>Changeイベントの中にChangeイベントを発生させる処理
にあたります。こちらが嫌がってそういう処理にしないで下さいと御願いしてもそういう組み方をする人がいるもので…（そういう人に限って自分が書いたソースを修正されるのを嫌がる傾向にあります）
非常に嫌でしたが同じ書き方をした事があります。その時はAPIも市販のコントロールも使わずに特定の文字だけを許可する入力規制を実現させるためでした。Changeイベントに記述していたのは全角文字も含まれるという仕様でしたので。
>一画面に300個のコントロールは圧巻ですね。
もう二度としたくありません（笑）発電所のシミュレータだったので通信で規定の色に色替えとかもしてましたよ。速度的にもあまり違和感は無かったです。
＞発電所のシミュレータだったので
もしかして電力の監視または制御をＸ周期でＤＢとの通信で
状態変化を色を変えて表示。みたいな感じですか？
教育用シミュレータでしたのでDBではなくシミュレート用のデータを返すアプリを動かしているサーバーとの通信です。WinSockを使ってテキストベースのデータ通信を毎秒行っていました。あまり詳しくは言えないのですが（過去の勤務先がばれるので）実際の機器を使えない代わりにGUIを使用して監視や緊急時の制御の練習を行います。
通信結果を見てフラグが立っていれば塗り潰し、数値が入ってきていればグラフの数値を変更、とかですね。表示ビットマップの変更もありましたが、画面のちらつきを抑えるのに苦労した記憶があります。
＞那岐さん
いろいろなご意見ありがとうございます。
みなさまの貴重なご意見が聞けたので
そろそろスレを閉じさせてもらいます。
みなさまありがとうございました。
解決
| ツイート |  |