古代VBプログラマ質問スレ（Ver.6.0 まで） part65 [転載禁止]©2ch.net
ここは古代に使われていたVisual Basic 〜6.0 の質問スレです。
質問者は使用しているOS、VBのバージョン、サービスパックのバージョン、
「何がしたくて、どうしたけど、どう困っているのか」を明確に書きましょう。
VB.NETは別物なので専門スレで、VBA、APIの質問もそれぞれのスレで。
○ 質問者の心得
一．質問する前にMSDNやGoogle、過去ログにも目を通してみる。
二．VBScript、インストーラーなどはこのスレでＯＫ。
三．質問は第三者にもわかりやすいよう簡潔かつ具体的に。
四．荒らしは相手しない。
○ 回答者の心得
一．答えられない質問は無駄に罵倒せずスルー。無理するな。
二．代用法を強制しない。
三．回答する上で必須ではない情報をむやみに聞き返さない。
四．荒らしは相手しない。
五．VB情報募集中。
六．回答は質問者が理解できるよう具体的に。
MSDN Online Japan ホーム
http://www.microsoft.com/japan/msdn/default.asp
Visual Studio 6.0 Service Pack 6
http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp6/default.aspx
Google
http://www.google.co.jp/
前スレ VBプログラマ質問スレ（Ver.6.0 まで） part64
http://peace.2ch.net/test/read.cgi/tech/1393069842/
※「まず自分で調べる」クセを身につけよう。 これだけ丁寧に説明されておいて逃げ口上だと理解する人にどうしろと? >>167
ん？
移譲はdelegationじゃないの？
compositionはdelegationの手段。 考え方が逆だよ
同じインターフェースを持つ場合に継承する
まずはこれを理解しないとね やくざの親分が基本クラスで子分が派生クラスと考えた場合
親分はどの子分にも同じ言い方で指示しても子分は指示通り正しく動く
親分でないやくざが子分に指示しても子分は親分の指示でないから意を解せず動かない
このとき、親分と子分の間の意思疎通のルールがインターフェースに相当する
継承がインタフェースか実装かは親分と子分との関係によって決まる
親分よりも保身が第一と考える子分ならインタフェース継承
親分のためなら命を張れる子分の場合は実装継承 VB6ユーザーの俺にはチンプンカンプンなので、分かる内容に変えてください。 >>185
気に入った女の子と仲良くなりたいときに、直接女の子にアプローチするのと
その女の子を知ってる人に間に入ってもらって紹介してもらうのと
どっちが気が楽でしかも成功率が高いと思う？
この場合、間に入ってもらう人が基本クラスに相当し、女の子が派生クラスに相当する
その間に入ってもらう人（基本クラス）が多くの女の子（派生クラス）と知り合いであった場合
その知り合いに毎回同じ方法、手続きで違う女の子を紹介してもらうことができる
見ず知らずの女の子に声をかけてナンパする場合（継承を使わない場合）の成功率と
（基本クラス）に間に入ってもらって、同じ手続きで違う女の子にアプローチできる（派生クラス）
どちらの方が良いかはVB6ユーザーでもわかるはずだ 結局インターフェイス継承と実装継承それぞれのの長所・短所はどうなりますか？ インターフェイス継承はインターフェースだけを継承しているから、
インターフェースを実装しなければ使いものにならない。
実装継承は実装を継承しているから一応使える。 いまいちインターフェース継承ってのが何を言ってるのか分からん。
例えば、クラスAをスーパークラス、クラスBがクラスAを継承したサブクラスとしよう。
VB6のスレ的に考えれば、クラスBでクラスAのインスタンスを生成して、
そのメソッドやプロパティの引数や戻り値をクラスBから内部に持ってるクラスAに引渡していることを言っているなら、まだ分からんでも無かった。
だが>>163辺りを見ていると、インターフェースをクラスで実装すること事態を
インターフェース継承と言っているように見える。
>>163はインターフェースを介することによって、どのクラスがどのクラスを継承するようになるのか説明出来るのか？ ここは古代VBプログラマーのスレですよ。
オブジェクト指向の話は別スレでお願いします。 xojoってフリーソフトを配布するときもライセンス買わないとだめなの？
やけに高いよね？ 消防車 is a 車
消防車 has a ハンドル
is a は継承。〜の一種。クラス
has a は、〜の機能を持つ・実装。インターフェイス。
例えば、携帯電話にカメラ機能を付けるなど、
相互に全く関係ないものをくっつける オブジェクト指向ってなんかしっくりこないんですけど。 インターフェースの継承は実装継承と比較するようなものではない
・インターフェースを拡張したインターフェースを定義する場合
・インターフェースを提供する(必ずしも実装はしない)クラスなどを継承するクラスなどを定義もしくは実装する場合
の後者はインターフェース継承ではない VB6のコントロール配列の特殊性はどうなの？
ハンドルも回すタイプとかステックタイプとかボタン付いてるのもあるな >>192
すごい！ここ数日の中で一番分かりやすい説明です！
本当に驚きました。ありがとうございます！
>>194
またカオスになってきた様相・・・ >>192
それを >>186の説明に適用すると
紹介者はおっさんでも美しい女性でも成立するが
紹介者がおっさんの場合、紹介される女性とは完全異質なのでインターフェース継承だが
紹介者が美しい女性の場合、紹介者でありながら自分も紹介される女性として成立するから
実装継承という事になるわけだよな >>195
フォームとそれに貼り付けられた（コンテナに入った）ボタンとの関係こそインターフェース継承だと思う
VB6でのGUI開発はその本質がインターフェース継承だがあえてそれをそう呼ばず
自分が定義したクラス間で同じような世界を実現するための仕様が Inheritsなのかもしれない インターフェースと継承の違いは基本となるインターフェースおよびクラスの特性で明白
インターフェースは各社のテレビを一元で操作できる学習リモコンのようなものだと思えばいい
使用者は各社のテレビごとに異なる操作方法を知る必要がなく、リモコンの操作方法さえ知っていれば
全社のテレビを、電源ON/OFF、チャネル切り替え、音量変更など全て同じように操作できる
その代わりに、学習リモコンは全社のテレビを操作するために必要な「インタ―フェース」を実装しなければならない
この必要なインターフェースを基本となるインターフェースにすべて実装しなければならないという制約が発生する
しかしその制約以外は何でもアリで、同じリモコンを使ってビデオデッキを操作してもいいし
各社のテレビは直接操作することも全く別のリモコンから同時に操作されることさえ許される
継承における基本クラスは各社がテレビを作る際に必要となるリファレンスモデルのようなものだ
リファレンスモデルであっても放送受信、映像表示および音声出力などテレビとしての基本機能は網羅している
各社はリファレンスモデルに色付けした自社製品としてのテレビを販売することになる
機能を追加するにしてもゼロからテレビを設計するには時間とコストがかかる
だからリファレンスモデルをそのまま拝借してそこへ追加機能を実装するスタイルが継承だ
リファレンスモデルは自分で実装する必要もなくどういう仕組みになっているか知らなくてもよい代わりに
テレビの基本性能はリファレンスモデルより劣ることもないが企業努力でそれを超えることもできない >>200
【インターフェース継承】
TV（クラス）がもつ機能でもリモコン（インターフェース）にそれを操作する機能が用意されていなければ使えない世界
【実装継承】
TV（クラス）がもつ機能ならリモコン（クラス）にその機能を使用する手段を実装することにより自由自在に使うことができる世界 例えば、パナソニック製TVだけがガンマ補正機能をもつ場合ガンマ補正の捜査が要求されたら
パナソニック製TVを使用するように判断し操作する >>204
インターフェース継承でも
If USE_GAMMA_CORRECTION Then
Set TV = PANASONIC
Else
Set TV = SONY
Endif
とか切り替えはできるけど、TVインターフェースにガンマ補正のためにインターフェースが実装されていないと
PANASONICクラス内のガンマ補正機能にアクセスする手段はないという事？ >>205
おいおい、大丈夫かよ
そのコードは一体どこに実装されると思ってるんだ？ あなたが苦労して取得した資格の平均最低月給ランキングは第何位？
民間や国家が認定している仕事の資格や免許。
その求人雇用市場での価値が一目瞭然で分かる。
（全求人情報平均最低月給196,500円）
ぼくらニッポンの民間・国家資格別平均最低月給ランキングはこれだ！
http://jobinjapan.jp/license/ >>206
もちろんクラスの外側だよ
それこそがインターフェース継承の欠点でもある >>211
一言だけ言うと、SOLIDについて調べるといいよ VB6プログラマがインターフェイスとか背伸びすんな。
おまえらは長年寝かした秘伝のソースを改修すればいいんだよ。 VB6ってしばらく触っていないが、知らんうちにスゴイことになっているようだ
インターフェースの継承って一体どんなものなんだろう？
もしかするとインターフェースに抽象クラスの機能でも付いているのかな 抽象クラスの定義は中身が無いメソッドが少なくとも１つは含まれていることが条件だから
インターフェースは、すべて中身が無いメソッドので、抽象クラスでもあるよ。 そりゃな。
C++では逆にインターフェースはなくて
抽象クラス代用してるし。 >>215
> インターフェースの継承って一体どんなものなんだろう？
本気で言ってるのかネタなのか区別つかんが、VB6/VBAでImplements IFooを
「インタフェース継承」あるいは「インタフェースを継承する」と言う人が結構いるってだけの話
あと、Javaクラスタの人にもいるみたいだ あー、調べたら、Javaの方は本当にインタフェースの継承だった
interface A {
void write(String str , int synchro);
}
interface B {
String third = "逃げちゃだめだ";
}
interface C extends A , B {
void write(String str);
} 実装継承ができない言語ならまだしも
実装継承とインタフェースの両方が使えるのに
あえてインタ＾フェースを選択する人って一体？ JavaはInterfaceに実装も書けるようになってる
AbstractClassと重なる部分をマスクとして除けば、Interfaceの意味はより明確になった >>221
一時期、実装継承は悪なんて風潮があったね
今考えると、LSP違反になりやすいとかそういうことが理由だったのかも
あと言語にもよるけど、実装継承を繰り返して継承すると、途中クラスの変更が
事実上できなくなったりするというのも理由の一つだと思う >>223
だからと言って何でもOKのインターフェース継承がおすすめというのは何とも理解しがたい よそのスレで相手にされないやつがここに流れてきているのか >>224
インターフェース継承がなんでもOKというのは、どういう意味？ >>228
たとえば継承10連結とかでもできるってことじゃない？ 俺みたいに、VB6のプログラムがWin8.1までは動いていたんだけど、
Win10にして動かなくなったって人いる？ インターフェースは継承とはレイヤーが違うので、概念上は制限が無いので、継承を包括し得る。C++のように継承でインタフェースを実現する事もありえるが、概念上は継承自体が制限となる。 用語1つで場をこんだけ混乱させてしまうオブジェクト指向ってプログラミングツールとしては最悪の部類だよね
でもそういう最悪をかき集めたものが飯の種になる矛盾を孕んでる
混乱が飯の種ってまるで火事場泥棒みたいなやつだ いやあこの話題の中で委譲の話を持ち出す人が居たのには驚いたわ
確かにインターフェースは委譲出来ないけど、ソレは抽象クラスでも同じことだからね これがニッポンの民間・国家資格別平均最低月給ランキング。
将来有望な資格も見えてくる。
資格別の求人件数と平均最低月給ランキング。
あなたの資格の市場価値が一目瞭然！
http://jobinjapan.jp/license/
プログラマーの大切な資格は正当に評価されているか確認しよう。 >>237
XP以降、VB6のランタイムはWindowsに包含されているから
EXE配布だけで実行させられるんで意外に重宝してる。
日本語表示させるためにはVBJP.dllとかが必要になるんで面倒だけど >>233
馬鹿が集まっているスレだからという方が10000万倍説得力があるわ VB6の後継かどうか知らんがVBAを拡張する計画があるみたいね
Excelユーザーに感謝せんとな VBAが拡張されるとしたら、おそらくECMAScriptの最新機能を
取り込んでくるだろうな。 何の因果か未経験からVB6でのシステム保守に携わっています。
川口輝久の「Visual basic6 基礎編」は持ってるのですが
何とか理解できるようになったので
生産性向上のため見るべきサイトや本などが
あればお願いします。
漠然とした質問で申し訳ないですが
よろしくお願いします >>247
できるだけ他言語の新しい知識には接しないことだな。
VB6がクソに思えてしまう。 Fowlerのリファクタリングなんて良いんじゃないかな
VB6の場合いかにして手に負えないレガシーの塊を解きほぐすかって方針で勉強したほうが役に立つだろう
この方針なら他の言語に移った時にも学んだ事は無駄にならない
方向を誤ってVB6マスターを目指しちゃうと将来的に有意義な経験がなにも残らない >>250
VB6でテスト用意してリファクタリングするのは恐ろしく時間の無駄になる予感がするんだが・・・ みなさんありがとうございます。
開発といいましても既存の画面の修正からなのでリファクタリングというのをやってきます 日本の会社はリファクタリングにお金なんて出さないから注意な リファクタリングっていうのは解析作業の一種で、
複雑になってしまったコードを解析して
その結果を反映させること。
リファクタリングに金を出さないという話であれば、
複雑になったコードを解析するのにも金を出さないって話だぞ。
そのとおりだが。
解析して、コードは修正せずに、バグと戦って、次回も解析するか、
解析して、コードを修正して、バグなく楽に修正、次回も楽になるか
の違いだ。 質問させてください。
Windows7 pro 32bitにVB6.0Professionalを入れました。
これに適用するべき、MSが配布している更新ファイルを調べてみたのですが、
Vs6sp6B.exe
VB6.0-KB290887-X86.exe(＝vbrun60sp6.exe)
VB60SP6-KB2708437-x86-JPN.msi
この3つ以外にもありますでしょうか？ 俺もそういう更新ファイルとか分からんから適当に入れた
http://pastebin.com/sSPzxYHt
リストアップしてみた（関係ないのもあるけど） お前ら教えろください
同じフォーム内にあるメソッドから〜_Clickみたいなイベントを呼び出すのってアリですか？
直感的にダメな気がするんですが、なぜダメなのか説明出来ません
どちらにしても誰か理由を説明出来る人いますか？
教えてエロい人 イベントが発生してないのにイベントハンドラが実行されたら困惑するだろう
平日にハロウィンコスプレするようなもんだ どーせイベントの内容をコピペしたメソッド作ってそっちを呼ぶんだろ？
それなら最初からイベント呼んでおけ 普通はイベントの中身をメソッドにして、両方共其のメソッドを呼ぶように作るものだな >>267
> VB屋はこれだから嫌だね
どれのこと？
わざとらしいアンチぐらい
見分けようよｗ >>261
> 同じフォーム内にあるメソッドから〜_Clickみたいなイベントを呼び出すのってアリですか？
なし
> 直感的にダメな気がするんですが、なぜダメなのか説明出来ません
その直感は正しいよ。理由はいくつか有る。
まず、一般的にフォームというのはユーザーの入力と処理を結びつけるためにある。
結びつけるだけなのでなるべくフォームに処理は書かない。
処理はフォームとは別に（ビジネスロジック用の）クラスに分離する。
このクラスはフォーム関連コードは一切ない。これにより自動テストがしやすくなる。
このように分離するので、二つのイベントハンドラから、共通のクラスのメソッドを呼び出すので
_Clickを直接呼び出すことはない。
これが大きな理由では有るんだが、クラスを使うほどじゃない場合でも
処理はprivateメソッドに書いて、内部的には処理と結びつけるコードは分離させておいたほうがいい。
それから、もう少しわかりやすい理由として、依存関係の話がある。
_Clickというのは、ボタンだったりするわけだが、そのボタンの存在に処理が依存しているのか？ということ。
通常はボタンには依存していないだろう。仮にボタンをなくしたとしても、処理の内容は変わらないだろう？
だが、_Clickを呼ぶと処理の中にそのボタンが紛れ込んでしまってるわけだ。こういうふうに
余計なものが混ざるとUIを変更した時の影響範囲が大きくなる。
どちらにも共通することは、その責任が明確に分離されていること。単一責任の原則とも言われている。
自分の担当範囲の処理だけを行うことで、それぞれの処理がシンプルになる。
絡み合わせる必要が無いものを、絡み合わせてはいけない。 >>261
お前さんの直感は正しくて基本的には良いことじゃないけど、まあ程度問題ではある。
良いことじゃない理由は、メソッドの名前と実態が乖離するから。
（ボタンがクリックされた時に呼ばれるはずのメソッドが、それ以外の時にも呼ばれることになる）
これは、「イベントハンドラが呼ばれるのはイベントが発生した時だけだ」という前提でコードを読んでいる
プログラマの期待を裏切ることになる。
程度問題なのは、そうは言っても十分短いコードなら上記の前提が正しくないことに
プログラマは気づくことができる。 せめてインターフェース継承くらい深い議題でないと盛り上がらんな VB6からVB.NETへの移植を体系的にまとめた本は有りませんか？
最悪VBではなく他の言語でも構いません
別言語への移植に関する情報が欲しいのです >>275
移植元、移植先の両言語をちゃんと理解すれば移植は簡単だろう >>275
新しくはないけど
http://www.amazon.co.jp/gp/product/4798102164/ref=s9_simh_bw_p14_d0_i1?pf_rd_m=AN1VRQENFRJN5&;pf_rd_s=merchandised-search-4&pf_rd_r=1RM0Y8MGQP2Y6H6E51H9&pf_rd_t=101&pf_rd_p=204601349&pf_rd_i=465392 👀
Rock54: Caution(BBR-MD5:60fb6bd37e268099e6257349e1247e68) 
