いくつかのボタンがあり、各ボタン別々の処理をするボタンをクリックした時のイベントを作る時、
・ボタンを配列にしてSWITCHでまとめる方法
・一つ一つイベントを作る方法
の２つではそちらが速いんでしょうか？
それとも、もっと速い方法があるんでしょうか？
誰か教えてください。
よろしくお願いします。
SWITCHでまとめるの意味が良くわかりませんが？
イベントプロシージャの定義では
パフォーマンスはほとんど変わらないと思いますが？
変わったとしてもコンマ何秒とかそれ以下とかだと・・・
コントロール配列にした場合は
カレントのボタンを特定する意味でも
配列の方が遅いと自分は考えますが。
すいません。間違えました。switchではなくて、selectでした。
Select Case index
case 1 '１つ目のボタン
case 2 '２つ目のボタン
・
・
・
こんな感じでするということなんですが、
結局ほとんど変わらないんでしょうか？
Select Case のほうが、開発は楽ですねぇ、
めんどうにやるほど、はやくなることが多いようなので
たぶんこっちのほうが遅いんでしょうけど…。
ここはSelect Caseのほうが、いいと思います。
でも、似たような処理をいするなら、
その処理は共通で、その結果をIndexによって仕分ける…。
(たとえば、コモンダイアログを開く処理は、全部共通。
結果を自分と同じIndexのテキストエリアに返すとか…)
というふうにすれば、少しは早くなると思います。
まったく関係ないボタンをコントロール配列にすると、
混乱するだけなのでおすすめしません…^^;
あんまりはやさにこだわらず、ある程度は手抜きで作るのがいいかなと…^^;
> ・ボタンを配列にしてSWITCHでまとめる方法
> ・一つ一つイベントを作る方法
このふたつの違いだって、多分、
50000回押して、やっと一秒差が出る程度だと思いますし…^^;
ちなみにこれに関係あるかどうか知りませんけど、
ひとつのフォームにあまりにも多くの部品(コマンドボタンとか)をおいたりすると、
そのうちそのフォームが開けなくなります。
(メモリ不足なので、たまーに開けるんですけど…)
よくわからないですけど、
コントロール配列なら、ある程度はその手の問題を回避できるかも…。
少し遅くなりましたが、返信ありがとうございました。
ＭＰ３プレイヤーを作ろうと思い、なるべく高速にしたらＣＰＵへの負担が少なく
なるのでは？と思い、少しでも高速にしようとしていましたが、
> 50000回押して、やっと一秒差が出る程度だと思いますし…^^;
なら、ほとんど関係ないですね。
マザーさん、たかみちえさん、どうもありがとうございました。