ぶっちゃけVB6でよかったんじゃないの？

どうしてもWebじゃなきゃいけないときはASP+VBより他の言語が
いいかもしれないけど、クライアントサーバーだったらVB6で
十分じゃん！
イントラに載せ変えてもユーザーからはブラウザは使いにくいって
評判悪いし、ランタイムの配布の問題だってDDL地獄だって
ちゃんと管理すれば問題ないよ
VBだってちゃんと構造化プログラミングすればスパゲッティには
ならないし、クラスモジュールも特に必要ないよ
VB.NETでなんか劇的にうれしいことでもあった？
ランタイムが重くなっただけじゃん！
なんかさー、MSとかベンダーの手のひらで遊ばれてるような
気がする。
オブジェクト指向もなんだかなー、分かりにくくなって
ソースが追いにくい分、バグが増えてない？

真夜中にクソスレ立ててみたお

そんな5年も前の話題を今さら持ち出されてもアレだから
もう削除依頼出してきなさい。

いや、今だからこそ言えるんだよ

オブジェクト指向言語で開発効率や品質なんて
別に良くなりはしなかった
むしろ分かりにくい分だけ開発者の負担が大きくなった

結局、単価下がって業界がめちゃくちゃになっただけじゃん

VBが20年前のCOBOLみたいな存在になっていれば、将来
今のコボラーみたいにマターリできたのにって思うよって
これは冗談ｗ

言語仕様については、
VB6のなぜこれはこうであれはああなのかみたいな
イビツなところがなくなってすっきりして前よりわかりやすいと思うぞ。
負担って言うのは、単に覚えなおしが多いだけだろ。

単価下がったのは、.NETが出たのと関係あるのか？

VSのバージョンアップが頻繁なのは、確かに保守が面倒だ。
けど、VB6の時代があまりに長かった気もする。

つーか、やっぱり今さらだ。
もう後戻りができるわけもなく、ダラダラ不平を並べても何ら意味がない。

単価が下がったのは>>1のようなカスがはびこってしまったせい。
これに尽きる。

>>4
>VB6のなぜこれはこうであれはああなのかみたいな
>イビツなところがなくなってすっきりして前よりわかりやすいと思うぞ。

もっと具体的に教えてくれよ
何がイビツだったのか？何が分かりやすくなったのか？

>>5
俺だって去年から.NET案件に突っ込まれて、否が応でも
勉強してるけど、メリットが大きければ不平は言わないよ

>>6
まさに２ちゃんのクソレスだな
何の建設的な意見もなく。

営業に同行すれば分かるが、VBしか経験のない後輩を
アサインするとき、二束三文で買い叩かれるんだよ
自分だけならギリギリ乗り切れるが、一応部下がいる身分では
フォローが大変なんだよ

>>7
いや、やっぱ>>2に尽きるわ。今更過ぎる話題を何繰り返してるんだ？
文法云々の話ならとっくの昔に皆乗り越えて、クラスライブラリの恩恵を享受しとるわ。
つか、VB.NET使ってる時点でｸｿ。

仕様どおり動いて管理できりゃ言語なんてなんだっていい。
ユーザーにソース納品する時言語は何で？て話もあるが、別に安定してる言語なら
ユーザーから見たら何だって同じだよ。

ま、VB6はもうどこでも売ってないからありえないが。

デジタルデバイドの下層に墜ちた人は大変だな。

.netに標準でFlexGridコントロールが入っていたら、
VBからの移行はかなり進んでいたのではと、つくづく思う。

VistaでもVB6は健在!!
http://www.microsoft.com/japan/msdn/vbasic/support/vistasupport.aspx
VS2005はSP1でも未対応
Visual Studio .NET、Visual Studio 2003に至っては未サポートwww
http://www.itmedia.co.jp/enterprise/articles/0610/06/news007.html

>>9
開発者がMSDNを購入(購読？)すれば
VB6が簡単に手に入る件について。

しかもJVM問題回避済みのバージョンです。

DDL地獄って何？

DDL地獄=ﾄﾞｷｭｿなデリヘル

出たとこ勝負のド根性ランゲージ

>>1
>VBだってちゃんと構造化プログラミングすればスパゲッティには
>ならないし、クラスモジュールも特に必要ないよ

こういうプログラムを組むことのできるVBプログラマが全体の何パーセントもいないから無理。

>>17 禿同

MSはアホだからこれがいいと本気で思ってるんだよ

>>18
素晴らしい時刻に投稿したなw

.NET Framework 2.0 廃止予定の API 一覧
ttp://www.microsoft.com/japan/msdn/netframework/programming/obsoleteapi/

　（　<●><●>） 　　ドトネト１．０〜２．０廃止なのは分かってます
　 （Ｕ　　 　　 ）つ 　
　　　 ｕ　　ｕ

VB2個、C#2個、どうせ使用頻度の低いAPIだ。無問題。

>>21
旧バージョン自体の廃止じゃないだろ？
.netではランタイムの新旧バージョンが普通に共存出来るようになったから、
不要なクラスやらそのメンバを新版では廃止しているだけ。

＞廃止予定一覧 : アセンブリ単位
＞廃止予定一覧 : 名前空間単位

どうみても再設計による旧バージョンの廃止です。
ありがとうございました。

>>1
悲しい事にフォームもコントロールもオブジェクトというオブジェクトは
全てクラスなんだよ


それを理解できない>>1のようなアホのために、わざわざ
VBという言語で包み隠してきたけど、もう隠し通せないから
ﾄﾞﾄﾈﾄにしたんだyo

＞悲しい事にフォームもコントロールもオブジェクトは 全てクラスなんだよ

文章が成立していない。

コントロールがオブジェクトだったとしてもクラスかどうかは、
プログラミング言語がクラスベースかどうかで決まる。

標準コントロールとてWin32コールのウィンドウに過ぎない。

ＣＯＭはバイナリ部品であってクラスではない。ＣＯＭのバイナリを作るときにクラスライブラリを使うかどうかってだけで。

　 　 　　/´･ヽ
　 　 　 ﾉ＾'ｧ,ハ　　　よ〜く、考えよう〜♪
　　　　`Zｱ'　/ 　　　ソースは大事だよ〜♪
　 　 　 　,!　〈 　　　　う〜う　う〜う　ううう〜♪
　 　 　 / 　　ヽ､_ 　　　 　<アホばっか !
　　　　l 　 　 　　｀ヽ、 　　、<すぐ廃止になる言語やライブラリは使わないようにね。
　　　　ヽ　　　　　　　ヾﾂ
　 　 　 　＼ 　 　 　 　/
　 　 　 　 　ヽ r　ヽ ﾉ
　 　 　 　 　__||､　__||

VB.NETやったあとVB6やるとやっぱ使いにくい

俺はWIN16APIゴリゴリ書いてた世代だけど、スキルと年齢でいろいろ達観
できるようになると、MSに踊らされてることに気づくよ

.NETで恩恵を受けてる？多少プログラムがスマートに書けるようになって
喜んでるやつもいるかもしれないが、全体的にみて、MSの焼き畑農業って
気づいてないやつは一生ドカタから這い上がれないと思うが

でも、この業界で食っていくには、たまにクラスライブラリ触って、はいはい
そうですか。みたいな冷めた目で全体像を丸暗記するしかないけどね

ネイティブ系のクラスライブラリでスマートに書けば良いんじゃね？






ＭＦＣはスマートに書けないお。

>>25
こいつみたいな中途半端な馬鹿がドカタ作業を喜んでやるんだろうな

VBが包み隠した？生産性を上げるために隠蔽するっていうんだよ

WinのOSにあるクラスとは、メッセージを受けるウィンドウのことだよ

VBで作ればコントロールは全部ウインドウになるけど、作りによっては
リソースでも作れる

言語でAPIをラップするときに、クラスをあてがってるだけだろ

>それを理解できない>>1のようなアホのために、わざわざ
>VBという言語で包み隠してきたけど、もう隠し通せないから
>ﾄﾞﾄﾈﾄにしたんだyo

お前、一生中途半端なプログラマとして一生懸命生きてゆけ

APIを知ってなきゃ使えないMFCの使い方を覚えるときに、冷めた目で
丸暗記した世代から見ると、MFCを避けて通れる分だけマシかもな

でも、いまだにMFC案件の方が多いんじゃないかな

ついでに言うと、MSの焼畑農業も大きなのはこれで最後にしてほしい

必要な機能を最低限のコーディングで済ませるという意味で、
.NETの恩恵はほとんどない
クラスベースで作りたいやつは、細々とDelphiやってたのに

普通のレベルのプログラマには、それ相応の言語で十分だよ

＞細々とDelphiやってたのに

勝ち組。

言語のスキルがあってもなくても、.NETなんか焼き直しってことぐらい分かるよ。

.NETになったからって、成果物／工数としての生産性は上がってない、
むしろ、必要なPCのスペックが上がって、大企業に納品するときはVBはだめ、
.NETもだめ、でイントラで作らされて、その挙句、操作性が悪いとのたまうエンドユーザー。

やっと、最近になって.NETで納品しても遅いと言われなくなった。

>>35
例えばさ、VB6で業務に関わる共通関数作ってもなかなか使いまわせないじゃない？
vb.netで業務の大元の抽象クラス作ったら結構な案件で使いまわせたよ。
やっぱりﾄﾞﾄﾈﾄの方がラクになった気がするけどなあ。

>例えばさ、VB6で業務に関わる共通関数作ってもなかなか使いまわせないじゃない？
プロジェクトをまたがっても普通に標準モジュールとして使いまわせるけどな

>vb.netで業務の大元の抽象クラス作ったら結構な案件で使いまわせたよ。
抽象クラスって言いたいだけじゃないの？
なぜ抽象クラスなら使いまわせるようになるの？

>>37
特定の業界の案件とか、マスタメンテってのは大体似たり寄ったりな仕様になるけど
コア部分はやっぱり会社ごとに違うじゃない。
VB6の時はとりあえず標準モジュールをコピーして、中身をそれぞれの会社用に書き換えたりしてたんだけど
vb.netの時はコア部分のクラスを作って継承させたら動くようになった。

コピペして書き換えってデグレード起きたりなんだりでチェックも大変だけど
コア部分の置き換えだったら、それ以外は実績あるからチェックも少なくて済むからラクになったよ。

>vb.netの時はコア部分のクラスを作って継承させたら動くようになった。
ほー、運がよかったんでつねｗ

JavaやC#、VB.NETをうれしそうに使いこなしてるやつも居るには居るが、
オブジェクト指向になって、コーディングが楽になったとか、バグが減ったとか
そんな実感全然ないな
EJB2.0みたいに、さんざん提灯記事で踊らされた挙句、EJB3.0で
POJOに見直し、みたいな、どんでん返しの可能性は高い

抽象クラスが割りとうまく活きてるところって、JavaでWebやるときの
フレームワークくらいじゃないの？

さらに最近では、Singletonに作ったり、Staticで作ったり、フレームワークが
OOを隠蔽して、業務クラスがVBを彷彿させたりするｗ

>>39
要するに私はオブジェクト指向の活かし方がわかりません、というカミングアウトか。
くだんね。勉強しろ。

俺は別にアンチOOじゃないけど、確かに騒がれたほどの手法じゃないな
一生懸命勉強した割には、見返りが少ない

逆に新人PGが戸惑って、デスマになりやすくなったという意味ではマイナスだな

よくOOによってダメPGが淘汰されるっていうけど、同じ目的をわざわざ難しく
達成して、だれも幸せになれないんじゃないかな

個人的にはDel厨だったんで、何の抵抗もなかったけど

>>36
> 例えばさ、VB6で業務に関わる共通関数作ってもなかなか使いまわせないじゃない？

それは単にスキルレベル低いだけだな。
共通化、共有化の方法は山ほど用意されている。
使いこなせないだけでしょ？

COMとか全然使わない（使えない）職場多いんだよな。

俺もVB.NETよりVB6のほうが嬉しい派だけど
>>39はただの勉強不足なだけだろ

そうは言っても、オブジェクト指向が理解できていない人の比率が高い
職場でオブジェクト指向を導入しようとすると>>39みたいな結果や、
もっと悲惨なことになっちゃうから
きっと>>39はそういう職場にいるんだと思う。

ようするに、オブジェクト指向を使いこなすにはそれなりのスキルが必要
で、そのスキルが無い場合は無理して使わないという判断を下す必要も
あるってことだろ。

オブジェクト指向が使えるのは、
汎用的なパーツのみ。

用意できるそのパーツが必要十分なら
それを利用するだけの場合オブジェクト指向は
必要ない。これが現実。

所詮、便所の落書きだけど

>>39に結構賛成。

EJBが3.0で分かりにくいという部分を見直した真摯な姿勢って大切だと思うお。
せっかくの高度な抽象化も、あまりに面倒くさいと使い手が疲れて品質が落ちる。

あと、オブジェクト指向マンセーだった椰子って、同時にEJBマンセーだった椰子が
多いから、漏れは新技術に心酔して枯れた技術をけなす椰子はあまり信用してない。

オブジェクト指向の冗長なコーディングは、DIの別効果によって簡潔になったり、
そもそもSingletonパターンにするならStaticメソッドにしちゃえっつー流行もある。

.NETにしても、最初は壮大な構想をもって売り出されたわけだが、OSに一体化
されることもなくランタイムで終わりかねない感じなわけで。
ただのJavaの対抗馬にしては、お膳立てが大袈裟すぎるでそ。

VBっつーのは、コンポーネント志向のある種の完成系なわけよ。
ただ、だれでも何となく作れてしまうから、VBしかできないPGがVBのイメージを
失墜させてしまったんだ。
まぁ、MSの営業力には逆らえないから、これからは.NET使うしかないけどね。

VB6はやっぱ今更感があるよ
.NETは、VB厨を駆逐してくれたという、隠れた恩恵をもたらしたｗ
VBしかできないやつに限って態度でかいから、そういう奴を一掃してくれた
.NETに俺はモーレツに感謝しているぞｗ

VB厨よか、グローバル変数しか使えないコボラーのほうが１００倍有害
しかも年齢的に駆逐しづらい
キンチョールくらいじゃ無理。密閉した部屋でダニアースが必要

OO難しいかな？
普通に使いやすくていいよ。

>>48
正直、伝票入力したり請求書だしたりする業務にさほど有効とは思えない。

>>49
自分でコード書く分には、OOで書こうが何しようが大差ない。
重要なのは、人が書いたコードでどうやって自分が楽するかってこと。

オブジェクト指向言語がそんなに一般的じゃない時代でも、
「ウィンドウプロシージャの関数へのポインタを構造体のメンバにする」
ことで、効率よくプログラミングしてたわけよ
ただ、C言語でそんなことしても、単なるマニアックな物好きと敬遠されたりｗ
そのあたりの呼吸は難しいわな

しかしオブジェクト指向言語が普及した現在でも、やっぱりその概念的な敷居は
高くて、無理に適用するとついてこれないプログラマが出てくる

要は平均的なプログラマーの能力では、マスターするのがやや難しかったと
いう意味で、単なるダイアログベースの業務アプリにオブジェクト指向言語を
適用しても生産性は上がらなかったという結果に対して、上級プログラマが
オブジェクト指向言語のメリットを無理に意味づけしても誰も納得しないってこと

そういうことを十分に踏まえてVBは生まれたのであって、平均的なプログラマの
スキルがある程度整ったところでオブジェクト指向言語投入したMSの作戦は、
少なくとも日本では功を奏さなかったんだよ

更に言えば、業務ロジックを組む上で、オブジェクト指向的なコーディングが
銀の弾丸になることはほとんどない
テンプレートパターンによて、関数の呼び出し順序を強制するくらいは
使い道はあるけど、共通関数をクラスで作ろうが関数で作ろうが、
ローカル変数を呼び出し側に置くか、共通クラスのインスタンスに
閉じ込めるかの違いがあるくらいで、格段に生産性や品質が上がるわけでもない

共通クラスの本質は、むしろ分散環境に安全に適用する部品への仕掛であって、
大規模プロジェクトでもない限り、そうそう必要はないはずだ

これくらいのことを自分で判断できないレベルの人が、VBだ.NETだ、なんて
議論しても滑稽なだけだと思うが

言語は手段であって、目的じゃないんだから、生産性が上がらなければ、意味はない

オブジェクト指向は着実に浸透しているよ。
使い方がまだまだ稚拙だけど、それでも無かった時代よりはずっと良くなっている。
ただ、個々のスキルの向上以上にいろんな技術や考え方がでてきて複雑になっているだけ。
これでオブジェクト指向の考え方や言語が無かったらと思うとぞっとする。

>>53
まー、確かに浸透してきてはいるが、言語仕様やそれを取り巻く環境が整ってなくて、
プログラマに余計な負担をかけていると思う
DIとかAOPとかアノテーションとか、メタデータやインタフェースの外出し・内包の流行は、
未完成のまま現場に流れてくるから
あ、VB6とは関係ないね

ぁ、それでも無いよりはあった方がいい。
技術ってのは、それを使えない人に合わせるんじゃなくて、使いこなしている人、必要
としている人たちの要望から生まれてくるものだから。
皆が使えるものではないからという理由で抑制できるものではない。
それを実際に使うかどうかは、現場の判断。
使える人がいて、それで生産性や保守性があがるんだったらどんどん使えばいいと思う。

新しもん好きは、無邪気な若者の特権なんだから、そいつらにOOの伝道をまかせると
どうしても嫌なフインキ(ryになるよな

そういうやつって、妙に声の甲高い、OOマンセーのコーラ好きアニメ好きの秋葉系と
相場が決まっているからｗ

でもプロジェクトに１人２人入れておくと、いい働きすることもある
ただし３人以上入れないようにｗ

>>55
俺もあったほうがいいと思ってるよ

ただ、よく吟味もしないまま、技術のないPMが導入を決めるのが困りもん
エンティティびーんとかさｗ
勘定系でもないのに入れんなよ、みたいな
それで、鬱になったりバックレたりするPGが出てきたりするんだから、
本当によく吟味してから導入しろよって言いたい

結論(VBの場合)：
　OOPを理解している奴がほとんどいないプロジェクト→VB6
　OOPを理解している奴がかなりいるプロジェクト→VB.NET

結論(Javaの場合)：
　OOPを理解している奴がほとんどいないプロジェクト→勉強しる。但し、EJBは早計
　OOPを理解している奴がかなりいるプロジェクト→いけいけどんどん、スキル次第ではEJBも。最近はSSHか。

結論（偽装請負メインの会社）

VBの新規案件はほとんどなくなってきたので、一括請負以外適用できない
VB.NET使うくらいなら、C#にして将来のJava要員にする

できないやつは待機させて、自己都合に持ち込ませる

OOPが難しい？それがよくわからない。
ポインタを理解できない人がいるらしいのはまだわかるけど・・。

なんか、現場のプログラマのレベルに合ってないから、OO意味なしって
主張している奴がいるけどさー、

そういうプログラマは適性がなかったってことじゃないの？
そこまで噛み付くほどOOって難しいか？
それで飯食うプロなら、勉強してモノにすべき必須概念だと思うぞ。

悪趣味なデザパタ大好きな人たちは別として。

OOが難しいから意味がない、というより

何でもかんでもOOにする意味がない派と
OOで組んでもメリットを感じない派が合わさってる感じがするが。

何と言うか、俺もプログラマならOOマンセーかもしれないけど、
プロジェクトリーダーとかになると、集めた要員のスキルでなんとか
しのぎたいとき、VBという選択肢がなくなるのは非常につらかった
時期もあった

自分がプロジェクトを管理する立場になって初めて、言語は道具だって
実感したり割り切ったりする感覚が出てくるんだよ

今となっては、平均的なプログラマも何とか物にしてるんじゃないの？
確かにVBオンリーだった人は、この業界から消えていったが、
それはそれで仕方がないんじゃないかな

マ板では珍しい良スレになってきたなage

半可なデザパタ採用は、かえって見通し悪くなるケースも、
確かにありそうだね。

VB.netはVB6との互換性が死んでるのがまず糞。
あと、前はＧＵＩ操作でお手軽にＧＵＩを作成できたのに、
C++で作ってるのとかわらんような面倒臭さ。
この変がアフォだと思う。
全部オブジェクト扱いはいいけどＧＵＩでおけなくなったのは
単に作るのが面倒だっただけだろ？

あんまり仕組みがどうとか関係無いと思う（少なくとも俺は）
ただ単に機能ダウンした。それだけ。

みんなの意見も大体わかるけど、.NETっていうかOO言語化は
いつかは越えなきゃいけない壁で、遅かれ早かれ導入することに
なってたと思う

VBからVB.NETになって、生産性が上がったかといえば、答えはNOだ

でも、それとOO言語を導入する必要はないという意見とは
全然つながらないと思う
結果的には、すこしずつOOが浸透してきているわけだから

>>68
だからＯＯ関係ないって。
単に自分で継承して作ったクラスをＧＵＩでおけなくなったから面倒になっただけじゃん。
頭悪いだろ？君。

俺はOOPを理解して以降、昔の自分のコードもすんなり思い出せるようになった。
VBやCで組んでた頃は、昔のコード見て、思い出すのに苦労してた。
但し、人の書いたコードはやっぱり苦労する。自分の感性に合ってるものとか、
デザパタを意識したようなコードはわりと読み易いけど、糞なコードはやっぱり
糞だな。

俺はOOPって、生産性より、保守性、可読性をあげるための技術だと思っている。
生産性だけをみると却って非OOPに劣る場合もある。

>>67に同意

天下のMSなんだから、もうちっとIDEで隠蔽して、VB並みのお手軽さを
実現してほしかった

なんか、VC++でマクロみたりオーバーライド追いかけんのウザイのと変わらん

>>69
＞単に自分で継承して作ったクラスをＧＵＩでおけなくなったから面倒になっただけじゃん。

つカスタムコントロール

OOってのは使い続けて資産が溜まってきた時に初めて生産性のあがるもんじゃねーの？

漏れのプロジェクトは、VBのコントロールをCOM経由で使ってるから、
.NETの皮をかぶったVBだお

>>73
もうかれこれ.NETのプロジェクトに5年居るが、生産性はVBと比べて全然変わらんのだが。

VBでクラスモジュールを継承できるぐらいの修正でよかったんじゃないの>MS

>>75
5年も使ってればフレームワーク的なものができるだろ。
ほしたら後は差分だけ書けば1本出来上がるんじゃねの？

>>76
画面の生成・破棄のフレームワークとかちょっとしたコントロールの財産は
できたけど、そんなのVBでも作れたし、再利用もできてた
COMでコントロール作るより、.NETのコントロールの方がはるかに
作りやすいのはうれしいけど、はっきり言って、あんだけ鳴り物入りで
話題だったOOって何よ？って今でも感じてる
俺は、VB6でも良かったと思ってる

まぁ、日本のPGにアンケートとったら、一番好きな言語はVB6って答える人が一番多いだろうな。
現に、俺の周りもそんな感じ・・・
つまり、日本人の感性からすると、言語のこれ以上の進化は愚行以外のなにものでもないということ
なのか？　日本人好み（目の前の生産性重視）と言われるとそんな気もしないではないが。

VB6で自分専用のフレームワーク作って、
掛け持ち案件をなんとか乗り切った漏れがやってきましたよ。
でも周りを見回したら、こういう風に使い回すより、
ガリガリ書いて、ガンガンコピペする方が良い！ってﾔﾂらばっかしだった。
OOに関していえば、Cよりかはマシだと思う、毛が生えた程度かもしれないけど。

VB6で変数は全てVariant。これ最強。

オフショアで一緒に仕事してる、インド・中国・韓国の人たちってレベル高くね？

>>78
俺もそう思う。
なんか、OO知らないと自分が無知なのさらけ出すのが嫌だから、使ってはいるけど、
共通関数のメソッドとかStaticで作ること多いし、だったら関数でいいだろ？みたいな。

俺がコボラーを馬鹿にしてたのと同じで、将来OOバリバリの若手に陰口たたかれんのかな。。

もちろん、Option Explicit なんて野暮な記述はしない。

>>81
日本人には、物事を抽象化したり、分割、整理する作業が基本的に向いてないんだと思う。
なんせ、わびさび、情緒、風情、精神、気合いなんて、アナログな世界を好む人種だから。

やっぱ、なんだかんだ言ったって、OOに疑問を持っている人多いから、
このスレも元気なんだよ
Javaのプロジェクトにいても、使いこなしてるのはフレームワーク担当の
一部のエキスパートだけで、大多数の人は言われるがままに業務クラスの
スーパークラスを継承してゴリゴリ書いてる
もしかして、この部分がOOの恩恵なのかな？

>>83
OOのメリットは、生産性じゃなくて、その抽象化と分類によって保守や改修を
楽にする部分にあるのでは？
>>84
確かにDispacherの部分以外で有効に使われてる現場は俺も見たことない
Beanのライフサイクルとか、見えないところでもOOしてるかもしれんが

日本人に向いてないとか開き直ってる人がいるｗｗ

俺はOOに疑問なんか持っていない。
ダカラOOヲリカイシテイナイヤツラトシゴトヲシタクナイ。ツウカヘラヘラシナガラヨッテクンナ。
コレガホンネダク・ソ・バ・カ・ヤ・ロ・ー

日本人がどうかはしらんが、少なくとも俺には向いてないｗ

VB6＋文化オリエントのコントロール＋たまにAPI直呼び＋Cでdll

で、業務アプリは何でも作れるｗ

>>88
んじゃそれでＳＯＡのＷｅｂシステム作ってください。
ケータイ対応もしてください。

まぁ、典型的な日本人の作ったアプリに典型的な日本人の客もていよくダマされるわけで。
日本社会は、これはこれでうまくてきているというか、PGがバカなら客もバカ。

>>90
客にとって作り方なんてどーだっていいことくらいわからんか。

>>89

タランチュラに載せてＯＫ牧場じゃ！
分かったか若造ｗ

>>92
おっさん、楽しそうですがまったく意味がわかりません。

夜中に盛りあがっとるのーｗ
わしの会社(一部上場ブラック)にも理解できるやつはほとんどおりゃーせんわぃね
じゃけ、OOなんて知ったかに任せておけばえーわぃｗ

>>92

意味は分かるが、もう引退した方がいいんじゃね？

>>92-93-95
もまいら…もう寝ろよｗ

アンチOOの馬鹿PGが沸いてきたので、クソスレ終了

本当にありがとうございました

>>91
客にとって作り方なんてどーだっていい。確かにそれは真理だが、俺はあなたとは
仕事したくない。何も得るものがないから。
仕事って金儲けるだけの作業って割り切りが、若僧の俺にはまだできない。

.NET VBとVB6でSQLサーバーを利用し同じものを作ってレスポンスの
実験をしてみたがVB6は瞬時に出るが、.NETはワンテンポ遅くて
重い感じがした。
VB6でまあ十分だろうね。市販ソフトの開発ならVCだろうけど。

客先もVB6の方が喜ばれるのでは？システムはみんなで共有しないと
生き残れないしね。

>>98
感傷に浸ってるとこ悪いんだけどさ、
>>90に対してのレスが>>91ってことはさ、
要するに「客がバカってことはねーだろ」と言いたいことくらいは察してやれんか。
いくら若造でもよ。

>>99
ﾄﾞﾄﾈﾄは中間ファイルだのクラスロードだのがあるから立ち上がりが遅いんだっけか？

実用にならないぐらいの差があるものが市場で受け入れられるわけがないだろ。
そんなちっちゃなことより、大事なものがある。それに気づかない人が多すぎるだけ。

>>102
「大事なもの」を具体的に書かないのは、
書かないのか書けないのか。

>>101
初回のランタイムのロードも、コントロールの描画も遅い
描画の一時無効のAPIでなんとかしのいでる
つか、ちょっと古いマシンだとクソ重くて、めっさ評判悪い

>>100
いや、客には馬鹿が多いぜ・・・
ちょっと調べれば市販品の安いコストでできるのが判るのに、わざわざ高い人月払って作らせたり。
その客のせいで多くの馬鹿も食えているわけで、世の中本当によくできているもんだなぁ...って思うよ。

>>101
ADOの.NET版が重いのかなと思ったけど、どうなんだろう…。
データグリッドでリスト表示させるとVB6は瞬時にでるね。
このままVB6使いたいけど、MS次第か…。
VISTAは32bit対応だから、大丈夫だとは思うけど…。
次のOSは厳しいかな…。

あと最近、システムの引継ぎで色々問題がでてるから、難しい
言語よりわかり易いVB6を使った方が日本の為になると思うけど。

PSPよりDSが売れている理由と似ている気がする。
VB6の方がわかりやすくて良いのでは？

>>105
その考えを利用して「わざわざ高い人月払うよりもこの製品を使えば！」
といううたい文句で汎用的過ぎるパッケージを買わせ、
「カスタマイズ料」と称して二重に暴利をむさぼったのが
あの悪評高いＢＡＣＲＥＸｗｗｗ

遅いのはデータセットの小分けのしかたとか、汎用のプロバイダーだからとか、
そのあたりが大きいお

>>103
大事なもの。
　保守性、拡張性、可読性、技術力、資産の共有、ドキュメント、自尊心、誇り、家族

>>110
ＶＢ６を捨ててﾄﾞﾄﾈﾄにすると家族の命が助かるわけですか。

納品先の情シスが、VBはもうサポート中止ですよね
VB.NETでお願いしますとか言ってくるしな

>>112
そんなにＶＢ６がいいなら
ＶＢ６で作ってﾄﾞﾄﾈﾄのツールで変換かければ？

>>111
さすがの理解力ですね。あんたと議論はしたくない。

最近は、意味も無く高機能で返って気分が悪くなるんだよね。
IT関連･･･。携帯とか…。
感覚麻痺するから気をつけよう。生殖もしなくなったし。
感動しない人間になる。

>>114
何か議論がしたかったんだｗ
技術論に誇りだの自尊心だの持ち出すやつとは議論できねーなあ。

プログラムにはシンパシーっつうもんがあるわけよ。感性っていうか、センスっていうか。
だから、自分のレベルとか考え方の合う奴のソースはわりと読めるけど、その上とか下の
レベルになると、途端に読めなくなる。いらいらしてくる。
で、何が言いたいかと言うと、多分今の世の中のIT技術のトレンドの最下層にいるのが
VB6マンセーしている人達で、そういう人達が、ITヒエラルヒーを支えているわけで、
まぁ、なんというか、結局俺が言いたいことは・・・
諸君、毎日毎日ごくろうさん、これからもよろしくね。

>>117
なんだろう。読めないというより読みたくない、という思いが伝わってくる。

世の中には、大衆車で満足な人もいれば、F1パイロットを目指す人もいる。
人それぞれが分際をわきまえて、極力人に迷惑をかけなければいればそれで
いい。それでいいのだ。

駄目だ。
どんな乗り物にのっていようと、なんぴとたりとも俺の前は走らせねぇ。

VB6サポート復活したんじゃなかったっけ？

見直されてるよVB6

オブジェクト指向言語がかなり眉唾だってことにだんだん気づきはじめてるもん

いったい何だったの、って言える雰囲気にはなってきた

VB.NETもC#もぐだぐだで終わったからな

>>122 いい加減なこと言うなよｗ

vbとvc++で十分だよ

マイクロソフトが各国のセキュリティを監視している時点でおかしい。
なぜマイクロソフトの言い成りになるのか？
VB6良いじゃん！簡単で。システムとは簡単にするから良い。
難しくしたら本末転倒。

ある程度の性能と保守性を保てればなんでもいいよ。
フォームにそびえる長大なイベントハンドラをどうにかできるのなら。

Microsoftは、未だにVB6を使い続けるユーザー達のために、
Formの既定インスタンス機能や、IDEの挙動をVB6に似せるなど、
移行支援の為の対策をVB2005にたくさん盛り込んだわけだ。
特に、Formの既定インスタンス機能は、改悪と言って過言ではないと
自他共に認めるであろう。
MSは、そこまでしてVB6ユーザーを「救おう」としている。

さて、ここでVB6ユーザーであるスレ主が、
VB2005を使ってみて、居ても立ってもいられずに立ててしまったこのスレッドを見てみよう。

http://pc8.2ch.net/test/read.cgi/tech/1159446575/
＞ [VB6とVB2005って全然違わない？]
＞ 1 ：デフォルトの名無しさん ：2006/09/28(木) 21:29:35
＞ まずcommandがbuttomになってて
＞ ？？
＞ 線引こうにもlineが認識されない
＞ なんなの？

私たちはまだまだVB6ユーザーを甘く見ていたようだ。
救いようがないとはまさにこのことではなかろうか。
VB6ユーザーはVB2005に対して、完全同一な物を求めているようだ。

新しいものへのチャレンジ精神があまり備わっていないVB6ユーザーのために
MSは色々な対策を行った。
しかし、いまだにVB6を使い続けているVB6ユーザーには、
新しいものへのチャレンジ精神など微塵も備わっていなかったのである。

このようなVB6ユーザーを生み出したのはMSである。
VB6からVB.NETへと革新的に進化させた結果、このようにいつまでもVB6を使い続けるクズどもが発生したのである。
もはや救いようのないVB6ユーザー。しかしそれでもMSは、最後までこのVB6ユーザー達を見放してはならない義務があるのだ。

VB6じゃきゃﾔﾀﾞ
　　　　〃〃∩ 　_, ,_ 　　　　　ﾔﾀﾞ
　　　　　⊂⌒（　`Д´）　 　　　　　ﾔﾀﾞ
　　　　　　 ｀ヽ_つ ⊂ノ　 　　　　　　　　ﾔﾀﾞ
　　　　　　　　　　　　　　ｼﾞﾀﾊﾞﾀ

　↑
ブビ中の現実

新しいものへのチャレンジ心がないのはVB6固執者だけじゃない。
こぼる、C、JAVA、それしかできんとほざくPGは多い。

＞こぼる、C、JAVA、

これらの言語に対してＶＢ６はＯＯＰ言語になるのに１０年遅れた。
コボルでさえOO-COBOLが存在。

まさに、>>128 が現実。

>>131
だからさ、言語云々じゃなく人を言ってるんだが。
こぼらーが全員オブジェクトコボルにのっかえたか？
C使いで＋＋使えない人なんて腐って捨てられるほどいるし。
OO万能ってのもそもそも間違いだし。

まあ、私は2003、2005と乗り換えて普通にやってるが、VB6をたまにやるとややこしくてつかれる。
コード量がやっぱり多くなるし。

＞こぼらーが全員オブジェクトコボルにのっかえたか？

子ぼらーはＪａｖａ中に派生した。

水に溺れて氏滅したネズミはブビ中だけ。

＞C使いで＋＋使えない人なんて腐って捨てられるほどいるし。

これ逝ってるのは、腐ったＭＦＣを使わされてるヤツだけ。

普通のクラスライブラリなら無問題。

だからさ、出来ないやつはどの言語でもいるっていってるだけなのに。
なんでそこまでVB6を目の敵にするの？

もしかして、VB6”ごとき”の言語も使えなかったの、なんかとらうま？ｗ

135=相手を攻撃しはじめた負け犬

まあ、2chで、”ブビ”って書く人でまともな人見たこと無いけど。

>>137
見えない相手を攻撃乙！

書き込みだけでわかるじゃん、基地外か基地外かぐらい。

まあ、自分はまともだと思ってる基地外ほど手に負えないものは無いけどね。

>>134
STLすら満足に使えない連中が多いんですが。

>>135
元々使えない奴でもVB6ならなんとかなっちゃうから。
結果、「旧VBやってる連中って駄目だ」と見えてしまう。

なるほど、VBこそが最強言語なんですねぇ〜

オブジェクト指向を学ぶのにも最適だとか

VB6もOOでしょ？　ただ、継承とかおいしいところが使えないだけ。

ITカルト集団だろう？難しいのが良いみたいに…。
VB6である程度はできてしまうよ。

継承がおいしいかどうかは微妙

VB６のコードじゃ勃起しない。C++では何度もイッた。Delphiでも抜いた。
Javaは・・・まぁ、ピクッてするぐらい。そろそろC#かなぁ。

CなんかどうでもいいからVBを使いましょう

だからVB.NETで駄目なところはGUIでコントロールを設定・配置できなくなったことだって。
継承ぐらい判断しろよ＞ＭＳ
馬鹿じゃねぇんだからさｗ

GUIでコントロールを設定・配置できなくなった


・・・釣り？

>>148
使ったことあるの？
できないでしょ。

少なくともVB6でできた似たようなことができなくなってるよね。
それがわかってるならいちいち知らない振りしないで。
君と話すの嫌なんだ。

GUIでコントロールを設定・配置できない？　継承ぐらい判断？
何の話だ？

GUIで設定、配置って、いわゆる「ポトペタ」のことじゃないの?

>>147はできなくなったって書いてるんだから違うんだろ。

>>45
>VBっつーのは、コンポーネント志向のある種の完成系なわけよ。
>ただ、だれでも何となく作れてしまうから、VBしかできないPGがVBのイメージを
>失墜させてしまったんだ。
>まぁ、MSの営業力には逆らえないから、これからは.NET使うしかないけどね。

これがすべてを語ってる希ガス

ベテランが普通にC/Sで業務アプリ作るんなら、VBがいちばん効率がいいと思う

ぶっちゃけVB6しか使えない奴の愚痴かもしれないが、
20代で新しい技術に何も考えずに飛びついてる奴より、
さっさと管理職なり、業務SEなりに転身してる奴の方が
生き残ってると思うんだが、どうよ？

だって、.NETのプロジェクトやってても、何がメリットか
よく分かんないし、VBでできなくて.NETでできること
(継承とかポリモルフィズム)がうまく使える機会とか
ほとんどないし

こんなこと言うと、「お前が使いこなしていないだけ」
見たいな厨が現れると思うけど、実際の現場では、
そういう厨に限って、一人突っ走って、みんなに迷惑
かけること多くね？

＞そういう厨に限って、一人突っ走って、みんなに迷惑 かけること多くね？

ドトネトとVB6と両方ゴミだからじゃね？
時代は両方とも見限ったようだよ。

VB6はまだ見限られてないだろ

http://www.vector.co.jp/soft/win95/util/se072729.html
作者の方へ

VisualBasicの学習者たちのためにソース公開してください
（公式サイトが消滅しているようなので、ここにカキコします）
((((；ﾟДﾟ)

ぶっちゃけとおちゃづけってにてるよね。

>154「お前が使いこなしていないだけ」
半分正解ってとこかな、
末端PGはフレームワークを利用してアプリ層書くだけだから
OOPL使うメリットどころか意識さえしてないだろ。
下の層のソースでも見て勉強しろ

未だにVB6のヤツイラネ

未だにVB6のヤツイラネ とか言うヤツイラネ

グレープシティのツールに依存しまくってるから自動で.Net仕様に変換できねー
ということで要らないお馬鹿な先輩様を切って保守要員にまわせた
これだけでも相当なメリットだと思う俺は何だ？

つーかコピペ厨の先輩様がOverridesだのOverloadsだの理解出来るわきゃねーんだよｗｗｗ
なァ、そうだろ？その師匠である前田ァ

基本的な概念くらい一冊薄っぺらい本でも読めば理解できる。

連中「概念」とか、そういうことが書いてある本は読まないだろ。
全ページに画面写真があって「このアイコンをクリックします」とか
図解してあるような本なら、かろうじて読んでくれるって感じ。

ブビﾞ厨の淘汰には役に立ったが、製造にはプラマイゼロで激しく評判の悪いドトネト

難しい＝良い事だと勘違いしてるやつ大杉
そして、そういうやつに支えられているオブジェクト指向

というか、MSの商売上、どうしてもVBからドトネトに乗り換えざるを得ないのも
寡占企業の弊害以外の何ものでもない

同じ機能の画面作るなら、分かりやすい方が良いに決まっている

JETエンジン使えるVB6最強

.NETは遅すぎて使えない
いちいちSQLに直すからだろうけど
そんな経験したやついる？

>>56
>そういうやつって、妙に声の甲高い、OOマンセーのコーラ好きアニメ好きの秋葉系と
>相場が決まっているからｗ

コーラが重要なキーワードだなｗ

確かに得意がって抽象メソッドとか作ってる椰子は、炭酸系をよく飲んでる気がするぞ

馬鹿に分かりやすいのと、常人に分かりやすいのは
違うということが分からない馬鹿がここにもいます。
ひらがなだらけの本を読む大人がどこにいるんだよ。

>>166

JETってACCESSとか小規模のDBに使ってたDAOのこと言ってる？

>>169
たぶんそれ
VB6のほうがはるかに早かった

> 同じ機能の画面作るなら、分かりやすい方が良いに決まっている

VB6と同様に「むずかしい」機能はスルーして、GUIでポトペタして、
イベントハンドラにコピペでごりごり書くって方法もつかえるが、
ちょっと見た目がちがうと、移行できないんだよなぁ。
どっかに欠陥があるとしか思えない。

>>170
その速度の差が何に起因しているのか説明できずに、文句だけ言うんじゃないよ。くれくれ厨。

>グレープシティのツールに依存しまくってるから自動で.Net仕様に変換できねー

グレープシティがらみのリプレース案件つらいよな

.NET版のコントロール置いてから、同等メソッドを置換する作業を延々とやって、
最終的には、微妙な部分で動かないんだお(-д-；)

.NETでも使えるよ

間違って関係ないファイルをダブルクリックすると
やたら.NETが立ち上がるのがウザイ

>>172
もう一年くらい前の話だから覚えてないよ
テストアプリ作ったら断然VB6のほうが早かったので
そっちで作った

>>175
ファイルの関連切っちゃえば？

ADO.NETの楽観的排他制御は、分散系のシステムには必須だけど、
ちょっとしたクライアントサーバでは、設計次第でパフォーマンスが悪くなる

データセットの作り方に注意するとか、Readerを使うとか、ADOを使うとか、
いろいろ検討しないと、すぐ劇遅システムになっちゃうよね

もう慣れたからいいけど、教科書どおりに作って、デスマもずいぶん経験したｗ

おまえらVBスレであげてんじゃねーよ

>>176
も前、.NET以前に、この業界向かないんじゃ？

アンチドトネトとアンチOOスレって、馬鹿が多い分いつも元気だよなｗ

楽観的排他は、Web系のシステムでは、.NETに限らず常套手段ですが。
なんなら、タイムスタンプなんかの更新用フィールド設けて手作っつう手もあるし。

>>182
だから、ちょっとした暮らさばなら悲観のが実装が楽っつってんの

>>183
じゃ、そうすれば？別にADO.NET使わないといけないわけじゃねえべ？
つぅか、ちょっとしたクラサバで、でも速度が気になる程の大量のデータ
なんだ？　びみょーだねぇ。

.NETのほうでレコードをINSERTするのが大変だった
ACCESSのファイルにINSERTする手段がSQL文しかなくて
繰り返すとやたら時間がかかった

>>184
楽観・悲観というより、C/Sで更新用のレコードを一旦クライアントにロードするより
FOR UPDATEしたほうがいい場合もあるよ

>>186
ちょ、お前、それを悲観つぅの。

どっちの手法もメリデメがあるけど、ブビ中がタイムスタンプ型の排他制御に
慣れていないのが問題

楽観が常に正しいと思っている厨が話をおかしくしてないか？

SPREADの.NET移行は、間違いなく大変

ADO.NETでFOR UPDATE使うとロックの制御があやしくならない？

だから、VB使いたい奴は使い続ければいいじゃん

で、失業すればいいじゃん

ダンボーラーになればいいじゃん

はい、ちゅいまちぇーん

>>191
ロック制御というか、トランザクション制御が難しい
つか、クラス設計が良くない

データベース独自のロック機構は使うなと
MSDNライブラリのADO.NETの説明に書いてあった気がする。

.NET版のHibernateにしとけ

俺に命令すんな！

>>195
そうだね、さらに遅さを求めたい人には必須だね。

>>192

寒杉

お前、友達いないだろｗ

>>192
いや、そういう問題でもないでしょ。
いまさらVB6でモノを作られるお客さんのほうがかわいそう。

客のほうが、自分がちょっと齧ったからって「VBで作っちゃえばいいですよ」
みたいに言う場合がいまだに多いんだけど。

俺はVB.NETがオフィースのVBAに入ってきたら、そろそろ信頼してもいいかな
と言う感じだな。
なんたって、仮にオンボロをオフィースに入れたら、オフィースもろとも共倒れだからな＞Ｍ�j
てことで、VB6>ボーランド
ってどう？

>>201
おまえに信頼されたとこでなんのメリットもない

>>202
と、お前が何を言おうとも誰も影響を受けない

ｱﾎばっかりだね。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

>>195
>>.NET版のHibernateにしとけ
NHibernate使うような椰子が、VB6に固執すまい。

今20代で、.NETを新鮮に感じてるやつも、やがて30半ばになると分かるよ
もの覚え悪くなるし、新しいことよりルーチンワークを好むようになる
ここまではただのオサーンの愚痴だけど、一番むかつくのが、
マーケッティング主体の技術の焼き直し

VBをDelphiに似せるだけだったら、なにもここまで改修(改悪)する
必要はなかったはず
結果的にDelphiまで無くなってしまって、そんでもって、クソMFC以来の
苦痛の学習も久しぶりに味わった

どっちょねっちょなんちぇじぇんじぇんむちゅかちくないんでちゅけどぉ
どこがむちゅかちいのかなぁ？　とってもふちぎでちゅぅ

>>207
難しいんじゃなくて「面倒臭い」って感じじゃね？
MFCで組んだときとたいしてかわらんような苦労するべ。

ぷろぐらむにとういつちぇいとはんようちぇいをもたちぇようとちたら
ほんりゃいめんどうくちゃいものなにょら。
ぶびちゅうはいままでそういうこちょをめんどうくちゃがってやってき
ちぇにゃいにょら。そのむくいをうけちぇるにょら。

>>209
いや、できるものができなくなったんだから、アプリ的には普通に改悪じゃん。
そのことを怒ってるのに、ＯＯがどうだとか関係無いことで的外れな煽りウザイ。
仕事じゃMFC使ってんだよ。
こんなデータコンバーターとか関係ねーもんをパパっとそれなりの時間で作れるからよかったんだって。

DelphiやMFCでバリバリやってたプログラマなら、.netなんて楽勝だろよ。
30代でルーチンワークを好ようになるって、いくらなんでも老けすぎ。

常識的に考えて、開発効率って点でVB6よりVB.NETが劣ること
なんて何一つないだろ。

VB6でやってたことを、そのままVB.NETで置き換えようとするから
なんのメリットも見出すことが出来ないんだよ。
VB6がいかに特有の非効率的な作業を開発者に強いるものであったか
理解するためにはまずVB6以外の開発を知らなきゃならない。

まあ、ＶＢは消滅傾向にあるみたいだけどねｗ
（だってMFCと変わらんもんなぁｗさらにＭＳの独自言語だから仕様がかわるかわるｗ
バージョンアップのたんびに作り直してらんねぇよｗそりゃＶＣ移るわｗ）

ま、くやしかったら、コントロール配列みたいなもん、今の構造で復活させてみなさいってこったｗ

コントロール配列いらね。ダサっ。

>>214
コントロール配列（みたいなの）がないと、
インスタンスが複数になるコントロールをＧＵＩから配置できなくて普通に不便じゃね？

コントロール配列！
こりゃひでえｗｗｗ

結局何もわかってないんだよなー。

じゃあ、普通にGUIで置いていったエディット１、２、３・・・に全部同じ処理かけようと思ったらどうなるん？

バカ丸出し
勉強しな
俺のとこにも経験は長いが未だにVB6のヤツがいるがつかえねーし

>>215
ぜんぜんじゃ不便じゃない。つぅかそんぐらいコードでパッパッて書く。
にしても、複数のインスタンスをGUIからちんたらポトペタ。あ゛〜俺が最も嫌いな
画面デザインだ。虫唾が走る。

visitorパターン

GUIの部品を配列に入れるのって.netでもフツーにできるけど、
コントロール配列って、そういう意味じゃなくて?

>>219
馬鹿はお前。できないし。

>>220
嫌い？なにいってんの？この人。学生かよｗ
仕様書にそう書いてあるんだからそうやって作るんだよ。

>>222
自分で継承して作ったもんもできたっけ？

>>223
お前みたいなやつがまだいるのかよ。。

>>224
当然できますが。

>>224
たしかできない。

複数のインスタンスって・・・
インスタンスハンドルは動いてるアプリに一つでしょ
マルチプロセス、マルチタスク？
ウィンドウハンドルの間違いじゃないの？
VBは、ウィンドウクラスウィンドウ作ったりメッセージループ作ったり、お膳立て要らずに即イベントプロシージャ書き始めればいいのが売りで。
画面デザイン・動き含めて、パッパッとこんな感じでどうでしょうとすぐできる。
VB.NETは使ったこと無いからどうだか知らんが。

>223
仕様書にポトペタで作れって書いてあんのか？
すんごいおせっかいな仕様書だな。園児向けか？

>>228
↑こいつ、インスタンスをインスタンスハンドルだと思っててﾜﾗﾀｗ

>>229
はぁ？お前が>>220で「嫌いな画面デザインだ」とかいうからだろ？
お前、作り方じゃなくてデザインに文句言ってたんだよな？

つまんねー議論しててもしゃーねーべ。

VBが見下されるのも無理ねーわ
俺は大好きだが・・・

VBが見下されるのも無理ねーわ
俺は大好きだが・・・

>>231
画面デザインが嫌い。
↓
仕様書にそう書いてあるんだからそうやって作るんだよ。

お前のレスがおかしい。「そうやって」ってポトペタでってことじゃないのか？
正しくは、「仕様書にそう書いてあるんだからそのデザイン通り作るんだよ。」か？

>>230
あー、.NETは知らんが、JAVAだとオブジェクト作ればもれなくついてくるな。
WINのAPIだとボタンだのリストだののコントロールオブジェクトの型はHWNDの派生なわけだ。

VB.NETでは、VB6のコントロール配列はなくなりましたが、コレクションやオブジェクト配列を
使うことができまる。これらには同じ種類のコントロールだけでなく、ボタンやテキストボック
スなどを混在させることもできます。
皆さん、大変でしょうががんばって覚えましょう。

>>235
はぁ？そもそもお前が画面デザインが嫌いっていったところからすでにおかしいんだろｗ
自分の発言がおかしいのに修正入れることなく他人様に間違え押し付けるとはどういう了見だてめーｗ

>>237
それ、ＧＵＩからどうやって配置したらいいですか？

>>236
トンチンカンなこと言ってないで、今日はもう風呂はいって寝ろ。
WinAPIとOOPをごっちゃにすんなよ。WinAPIのウィンドウクラスとOOPのクラスは別物だから。
勘違いすんなよ。

>>238
たしかに画面デザインが嫌いとは言ったが、その前に(コントロールをポトペタじゃなく)コードで書くと言っている。
画面デザインが嫌いと言ったのは、そのついでみたいなもの。お前が勝手に「画面デザインが嫌い」の方に拘っただけ。

ちょっと俺風呂はいってくるわ。すまん。

>>239
ブビ厨のみなさまには大変残念なお知らせですがGUIからは今のところできません。
つぅか、常識的に考えたらわかるでしょ？　

ミクロレベルで考えても、GUIから登録するよりコードで出来たほうがはやいし柔軟だろ。
一生サポートされねーよ、そんな機能。

>>242-243
そんな君等にjavaをオススメ。
驚愕することになんとできていますｗ

VisualEditorが重くて仕事になりませんが

>>244
Javaの開発環境っていろいろあるわけで、それを書いてくれなくっちゃ。
GUIだから、クライアントアプリかアプレットの話だろうけど。

いろいろはねーよ。大きくわけるとNetBeansかEclipseの2択。

ググってみましたが、それらしい情報を見つけられませんでした。
探し方が悪いのでしょうか？　それともJavaではコントロール配列という呼び方
ではないのでしょうか？　エロい人教えてください。

>>248
javaはソース内に定義したnewを探して配置してくれてるような希ガス

>>237
ええ? VB6のコントロール配列って、同じ種類のコントロールしか入れられないの?

>>249 イヤん、怖い...

>>244
VisualEditor触ってみたけどできてんな。
すげーな。どうなってんだ、これ・・・

VB厨がJavaに触手を伸ばそうとしています... これも進化の過程か？

>>250
...だから、VB6はOOPをサポートしてないってあれほど(Ry

>>252
VB.NETもそれができれば移植も楽になって、状況は変わっていたかもしれないな。

いやだから、コントロール配列とか別にいらねって。

>>206
> VBをDelphiに似せるだけだったら

Del厨ってここまで誇大妄想してるとは、さすがに想像もつかなかった。

俺は使ったこと無いけど、.NETでもあるじゃん。ButtonArray
しかしこんなの使わなくてもググれば簡単なサンプル山ほどでてくるのに・・・

ButtonArray ??? なんじゃこりゃ

>>258
VB.NETだとＧＵＩから使うには
↓こういう面倒なことしなきゃいけないんだって。
http://dobon.net/vb/dotnet/control/buttonarray.html

なこともあって、「なんで改悪したの？」って話になる。
まあ、構造をオブジェクト指向っぽくしたってのはわかるんだけど
これができるのとそれは別の話しだよね。ってこと。
実際、javaのVisualEditorではできてるわけだし。

失礼。
ButtonArrayはSystem.ComponentModel.Componentを継承しており
デザイナ上でドロップできるのでGUIでコントロール配列ができると思ってしまった。
（ちなみに、Microsoft.VisualBasic.Compatibility.VB6名前空間な）
>260
簡単じゃん
このサンプルはコードでボタンのインスタンスを生成しているけど、
デザイナで貼り付けてコードではその参照を取得するようにすればさらに簡単じゃん。
さらにデザイナで貼り付ければWithEventsキーワードはついているから
Handlesキーワードを使って静的にイベントハンドラを定義すれば
一番簡単だと思うが。

>>260
あぁ、俺なんとなくわかったよ。ブビ厨ってのは、こんなんが面倒くさいって思っちゃうんだね。
このコード見て、クローン使えば簡単になるなとか、ファクトリメソッドパターンも使えそうだなとか
そんな発想ができないんだね。そういうオブジェクト指向的な考えにいかないんだね。
この通りやんないとって思っちゃうんだ。そうか。。。そりゃ無理ないわな。俺が悪かった。

昔からこの板には「ポトペタ」という、業界でまったく通用しない独自の
造語を使ってVBを叩くことに熱中しているヘンな人がいるね。

>>262
ＧＵＩから配置・設定できないことには変わりないじゃんｗ

で、だったら、MFCの方がなんぼか楽って結論に辿り着くでしょう普通。
さらにどうせMFCと手間も変わらない状態になっちゃって、言語仕様も変更されたとなっちゃ、
そりゃもうVBにいいところなんてこれっぽっちもないっしょ？
素直にVC使うっての。こっちは言語仕様までMSに変更されることは無いからね。

ＶＢ厨からマウスをとりあげたら、仕事できないよぉって泣いちゃうな。

ここのブビ坊はプロか
レベル低すぎ・・・
俺だって半年程度でまだまだ勉強だけど・・・

>>260-262
結局、.NETはGUIでサクッとは行かずにオーナドローか。
VB6はGUIのコントロールが即プロシージャに繋がるから、直感的にもサクッと分かりやすくて、
すぐに、これでどうでしょう？、じゃあこれでは？と画面も動きも(単純なものなら商談しながら)すぐに修正できてしまうところが売りなんだけどな。

>>265
なんでそういう発想になるのかさっぱり分からん。
コントロール配列のないＶＢよりＭＦＣの方がなんぼか楽？
う〜ん、やっぱり分からん。俺も昔はそんな考えだったかなぁ。
言語覚えたての頃の感覚ってもう忘れてしまったなぁ。

>>268
プロならこんなの1分もかかんねーだろ。

>>268 それは部品があればこそでしょ。VB.NETでも一緒だと思うけど。ようは慣れの問題じゃないの？　もう観念してＰＧやめるか、勉強するかすれば？

>>269
>コントロール配列のないＶＢよりＭＦＣの方がなんぼか楽？
今のＶＢだったら、ＭＦＣの方が楽だと思うよ。（まあ、あんまり変わらない程度だが）
それに言語仕様の問題もある。（こっちのがでかい。つか、同じ苦労でどっちか？っていったらＭＦＣになる）
バージョンアップのときに動かなくなるのはやっぱり困る。
１〜２万行程度ならなんとかなるかもしれんが、プロジェクトごと１０万超えてるもんもあるのに
言語の仕様変更なんてされたらかなわん。

>>271
商品ってコントロールの数が半端じゃないじゃん。
ちょっと小さめのプロジェクトでも全体で５００は超える。
その１つ１つに対してソースで座標設定していく手間といったら、それだけでマジ死ねる。（しかも、それだけじゃないし）

マジなのかネタなのかわからん
俺はVB6からVB.netに移行して生産性は2倍から3倍くらいに
なったと思っている。バグも減った。

C、C++、java、vb、delphiが出来る漏れが冷静に判断つるに、.netの方がmfcより簡単でちょ。
ｱﾎか。。。。。。。。。。。。。。。。。。。

だからお前らDelphiにしとけばよかったんだよ。こんなの昔からだぜ。
2Way-Toolにはいろいろ制限もあるけど、慣れてしまえばこんな快適な環境ないぜ。
がんばれ、ＶＢ厨。ファイトだ。

俺は、コントロールの動的生成＋レイアウトマネージャで自動配置、
なんてよくやるけど、それでもコントロール配列は欲しいな。
ループ回して処理したいケースは多いし、自分で配列作ると
保守性悪くなるし。
結局、フォームの初期化コードをどう生成するか、って話だし、
無理な話ではないと思う。

>>273
そんなのコードでは参照を取得すればいいだけじゃん・・・

>>278
手動で全部入れんの？ｗ

>>273
コントロールの数が500超えるちょっと小さめのプロジェクトって...
これ、全部同じ種類のコントロールなのか？　
これをオブジェクト指向なしで作るなんてＶＢってのはすごいな。

>>279
だから、慣れればコードの方が早いって。コピペも置換もサブクラス化も使えるし。
最近のＩＤＥはリファクタリングの機能も充実してる。
俺には、マウスでちまちまプロパティエディタでしこしこの方がしんどい。

>>280
なにをいってるのかね？
別に５００個同じものでなくとも５００個見直す必要ができるでしょ？

>>281
早くないって。
結局、配置したコントロールを手動でまとめる作業（格納する？）は必要だぞ。

>>282 お前、日本語がちょっとおかしいぞ。

>>283 簡単にまとめる（格納する）方法を考えればよかろう。

>>283 つレイアウトマネージャ

>>284
はぁ？つか、おかしいのは、まず、>>280の頭。

>コントロールの数が500超えるちょっと小さめのプロジェクトって...
>これ、全部同じ種類のコントロールなのか？　
>これをオブジェクト指向なしで作るなんてＶＢってのはすごいな。

そもそもこの文章で俺は>>280が500個のコントロールを全部同じ種類のコントロールだと思った理由がわかってない。
別に500個のコントロールが全部同じ種類でなくとも、その個々のコントロールが
他のなんらかのコントロールと同じ種類であれば500個見直す必要があるでしょ？
これはわかるじゃん。
まあ、まず、>>280が意味不明。

ああ、まず、それを先に言えばよかったのか。
じゃあ、改めて、

>>280の文章が何をいわんとしてるのかさっぱりわかりません。

>>287
俺には、お前が>>273で、「その１つ１つに対してソースで座標設定していく」と考えたのかがよくわからん。
VB.NETでも別に画面上のドラッグドロップできるでしょ？
だから、俺は、あぁ、これはコントロール配列が使えないことを言っているんだと思ったわけ。となると、VB6だと同じ種類
のコントロールってことでしょ？　で、まぁ一応念のため>>280で疑問形にして聞いてみたわけ。なんか間違ってる？

どうしてC#を使わないの？

C#、C++、C！

C！、ひぃぃぃひぃぃぃぃお許しくださいもう
メモリリークしませんからデスマだけは
ひぃぃぃぃぃ

>俺には、お前が>>273で、「その１つ１つに対してソースで座標設定していく」と考えたのかがよくわからん。
配置の作業的には、「ソースで座標設定する」か「配置したコントロールを手動でまとめる」のどっちか。

今度は>>288の

>となると、VB6だと同じ種類のコントロールってことでしょ？

がわからん。

アプリ全体でコントロールが５００個あって、そのうちの３００個がエディットで、そのうちの１００個がボタンで、そのうち・・・ってなってたとして、
エディットについていうと、３００個のうち、同じ処理をしなきゃいけない、ものが各ダイアログごと２０個ずつありました。
っていったら３００／２０種類になるじゃん。
なるけど見直す必要のあるエディットボックスが３００であることにかわりはないじゃん。

コントロール配列が無かったら、上記の「ソースで座標設定する」か「配置したコントロールを手動でまとめる」処理を
３００個全部についてやらなきゃいけないってことでしょ。

>>289
ＶＢのときにＭＳ仕様で痛い目にあったから。
ＶＢも終わったし、もういいかなｗ・・・とｗ
やっぱり、言語の仕様変更は一番困る。

レイアウトマネージャはスルーかよ

あと、visitorパターンも

>>293
なんですか？それ。

あと、いまさらMFCってなんなんだよ。それこそ廃れてんじゃねーか。

>>296
うるせーな。
びっくりなことにMFCしかねぇんだよｗ

>>295
レストランなんかで、テーブルの配置とかウェイターの立ち位置とか指示
してる人がいるでしょ。あの人のことだよ。
VB厨ってほんとOOPの常識が通じないんだなぁ。新世界へようこそ！

>>298
検索してもjavaしか当らないじゃんｗ

同じ言語が１０年以上、仕様も環境も互換性も一緒ってまれなことだと思うぞ。
その点、Ｄｅｌｐｈｉはえらかった。　がんばれＶＢ厨。

はぁ...ＶＢ厨はググり方も手取り足取りですか...　まったく応用がきかねぇな。

本質が見えてねーつか、見ようとしてねーんだよ。この馬鹿は。

>>300
一般的（？）なもんだけ使ってりゃC++なんてほとんど変わってないと思うけど。

>>301-302
何が言いたいのか本気でわからない。

C++ほど変わりまくったもんないんじゃない？

>>304
どのへん？１０年前とだよ？

いま一番あたらしいのってVC++2005だっけ？一昔前のとは全然違うのになっちゃってるように見受けられるが。

>>306
なんで突然ＩＤＥの話はじめるんですか！？
なんで突然ＩＤＥの話はじめるんですか！？

えっ、えっ、どう見てもIDEの話はコミコミの流れですよね。。？？

>>308
いや、テキトウなこといって後悔してるのディスプレイ越しに伝わってくるから別にいいよｗ

>>309
エラソウにする前に、ここでC++の言語仕様に特化した話して何の意味があったか教えていただけませんかｗｗ

>>310
それは>>300←こいつに聞いてくれｗ

>>131
Visual Basicってオブジェクト指向の言語だと思うけど…？
VB厨が無理やり無視してるだけで。

コボルのOO言語でないのとは話が違う。

VB6のコントロール配列は秀逸だけど、そんなに使う場面あるかなー
テキストボックス並べるくらいなら、グリッド系のコントロールという手もあるし。

俺も昔、Excelのユーザーフォームで、コントロール配列がないのに
気づいて、WithEventとクラスモジュールでなんとかした。

その時は、SwingでaddListenerするのに比べて、シンタックスに無理があるなー
と思っただけだったし、俺なら.NETでやるんならC#に持ち込むよ。

IDEの究極の完成系はVB6だけど、職業プログラマなら、マウスより
キーボードになっていかないか？

支離滅裂だけど、慣れれば.NETのが楽だし、メンテしやすいよ。

ただ、初めて触った言語がVBだった人は、ある意味不幸だな。

>>263
キミいろんなところで同じこと書いてるね。
プログラマの癖にweb検索もできないのか？w
恥ずかしい奴。

>>206
年齢は関係ないでしょ。
実際俺は30後半だけど全然抵抗ないよ。

っていうか、.NETがVB6からの改悪だと思ってる時点でなにか大きな勘違いをしてる。
あるいはそもそもPGに向いてないのかもね。

　 ε　⌒ﾍ⌒ヽﾌ
　（ 　　( 　・ω・）　ブビ
　　しー し─Ｊ


　　　　　　 ε　⌒ﾍ⌒ヽﾌ
　　　　　　 （ 　　( 　・ω・）
　 　　　 ε　⌒ﾍ⌒ヽﾌ⌒ヽﾌ
　　　　 （ 　　( 　・ω・） ω・）
　 　ε　⌒ﾍ⌒ヽﾌ⌒ﾍ⌒ヽﾌ⌒ヽﾌ
　　（ 　　( 　・ω・） ( 　・ω・）ω・）
　 ε　⌒ﾍ⌒ヽﾌ⌒ﾍ⌒ヽﾌﾍ⌒ヽﾌ⌒ヽﾌ
　（ 　　( 　・ω・） ( 　・ω・） ・ω・）ω・）
　　しー し─Ｊしー し─Ｊ し─Ｊ　─Ｊ

言語は環境や時代の変化に合わせて絶えず変化していくもの。
Perlは4から5へのバージョンアップ時にOOPをサポートし、多くのスタイルが変わった。Rubyはこの10年で1.0
から1.8へと進化した。PHPもその前進のPHP/FIから、PHP3, PHP4, PHP5と変化し続けている。
ほとんどの言語が下位互換を不完全ながら維持しているものの、旧式のスタイルは次第に排除されつつある。
C++とて例外ではない。ANSIとISOの合同委員会による1998年の標準化以降も改定を重ね、2005年には、TR1
がリリースされ、多くのコンパイラがこのTR1のサポートに取り組んでいる。
C++もSTLの標準ライブラリへの追加により、その開発スタイルは様変わりした。私も久しぶりにC++を触った時に、
ネームスペースがサポートされていることに驚いた。まぁ、時代の流れを考えれば当然なのだが。
ＰＧたるもの、同じ場所にとどまっているわけにはいかない。新しい技術へ対応する柔軟性は持ち合わせておか
なければ取り残されてしまうぞ。避けては通れない道なのだ。これは言語に限った話ではないが。

C#を触って以来、もっと早く移行しておくべきだったと後悔している。でも、今が幸せだから…

>>313
不特定数のメニュー項目の動的な追加、削除などで必須。
ファイルメニューに「最近使ったファイル」などがある場合は必ず使う。

動的な要素より、順序性をもった設定やﾁｪｯｸをループ処理できるのがコントロール配列の強みかな？
グリッドも最近の何でもExcel症候群な風潮で受け入れられやすくなってきたけど
ウェブはテキストボックスやドロップダウンコンボなわけだしね。
そういったインタフェースにするならやっぱコントロール配列にしちゃうよ。

List(of TextBox)に突っ込めよ。
手間かかるけど。

C#ってそんなにいいかなー
VB.NETのほうがいいような。遅延バインディングができるから

>>321
わかったからVB6で我慢しとけ。

>>312
VB6は言語として継承をサポートしてないでしょ。当然、ポリモフィズムも使えない。
サポートしてるのは中途半端なカプセル化だけ。とてもOOPとは言えない。

VBはエンドユーザーコンピューティングとして絶滅しないと思うよ

大手の社内SEやってるけど、基幹系はSAPやホストで外注、
情報系はVBやVBAで内製してる

俺もDelphi上がりだけど、VBのお手軽さを捨てた割には、Delphi
みたいに軽快じゃなくて、なんだかなぁと思う

そのうちPCのスペックが追いついて、気にならなくなるんだろうけど、
初回起動時のモッサリ感は、エキスパートが作っても変わんないね

>>324
いや、それはVB6のときの話でVB.NETは手間や構造そのものがVCで作ってるのと変わらんよ。
すでにもう、終わりそうだけどｗ
そのうちほんとに終わると思うよ。＞VB

VC使ったことないだろお前。

>>325
VB6の話してんだけど。

あと、手間は別として、構造はVC++と.NETは全然違わね？

俺の周りのDelphiユーザーは、MFCの安直な設計にやる気を無くして
深く使いこなしてはいなかったけど

>>326-327
8年近く使ってますが何か？

つーか、VB6と比べるとどうしても今のVB.NETがVC寄りのツールに見えてしまうんだな。
少なくとも、VB6のときに俺が考えていた進化とは全然別のところにいったな。と。
もっとビジュアル色強くなると思って期待してたけどね。

折れ的にはVB6は大して使ってなかったけど、
ライブラリが無い言語で仕事になる物なのか？

>>329
意味不明

>>329
VB6でもdllが書けるけど、そういうことかい？

>>331
.NET Frameworkの話をしてるんじゃなかろうか。

ライブラリが無い？
VB6ランタイム、VB6コントロール群は？
LibファイルとかDLLファイルとか、物理的に見えないと駄目な人？

>>333
そういうレベルですらないと思う。

＞開発者によるVisual Basicの利用が急減，JavaやC/C++が主流に
＞ttp://itpro.nikkeibp.co.jp/article/USNEWS/20061129/255223/

Visual Basic 6.0以前のユーザーが減少しているほか，Visual Basic .NETを使用する開発者も26％減少した。

>>335
>その他の主な調査結果は次の通り。
>
>・2007年にWeb関連の開発に従事する予定の開発者は70％以上
>
>・リッチ・インターネット・アプリケーションの開発に従事している開発者は80％
>
>・Ajaxの利用率は28％

うさんくせえww

Ajaxってどうなんかね？
苦肉の策って言葉がぴったりだと思うんだが。

>>337
やはりコンサル様の飯の種でそ。
Googleが提供してるオフィスもどきは素直に凄いと思ったが。

Ajaxは便利だよ

>>339
いや、便利なのは認めるけど、そもそもブラウザ（HTML+なんか）でやるってのが無理があるわけで。
JavaScriptでの工夫って、要らない努力としか思えん。

と、クリックワンスで楽しんでるプログラマ発言です。
とりあえず、イントラ範囲ならば クリックワンスは有用。

いやいや、ﾛｰｶﾙPCにアプリケーションがインストールされない
安心感は違うよ

> ﾛｰｶﾙPCにｱﾌﾟﾘｹｰｼｮﾝがｲﾝｽﾄｰﾙされない安心感

って、何のためにコンピュータ使ってるんだろう。

ネットワークにつないでJavaScriptを野放しにする方が絶対に不安だと思うのだが。

インターネッツ

>>342
　>>344

>>343
　それできないならｐｃｲﾗﾈ。携帯で十分

ﾌﾞﾋｱﾌﾟﾘよりＡｊａｘのんがｶｺﾖｽ

exeよりはマシじゃん。nyしてればわかるだろ

Ajaxはライブラリが揃ってだいぶ使い易くなったね。
開発環境がもうちょっと充実してくれば、今後のスタンダードになるかも。

>>348
ならないな
ブラウザ依存の点からいくとflashのほうがよい

>>349 はあまり研究してないみたいだけど、今のライブラリはブラウザ間の
相違をかなり吸収してくれてる。それが各ライブラリの売りのひとつ。ライ
ブラリが増えて選択に困るぐらいで、それが逆に悩みのたね。今後はブラウ
ザもそのへんの互換性は意識してくるだろうし。そしてなんていってもクー
ル。ちょっと試してみれ。驚くほど簡単で便利になってるから。

>>326 につっこむ香具師は誰もいないのかぁ？ｗ

VB.NETが嫌いな人はC#も嫌いなんだろうか、Delphiも当然嫌いだろうなぁ。
Ajaxなんてとんでもない？
VB厨が好きな開発環境はこんな感じか。
・GUIベース。フォームにコントロールを貼り付け。プロパティを設定、イベントを
　関連付けてゴリゴリ。MDI、SDIは別にいらね。つぅか面倒なのでダイアログベース
　で十分。
・コントロール配列が無いと泣く。ほかのやり方なんて想像もつかない。
・リストやコレクションは不要、配列だけでOK。ハッシュマップはあればまぁ使う。
　いや寧ろ、配列より使うか。
・OOPは不要。あってもいいが使わない。強制されるのはいや。動けばいいのだ。
・便利なコンポーネントがいっぱい欲しい。グレープシティは神様、ほとんど依存。
　PGがやるのは、基本的にイベントコードだけ。関数分割めんどくせ。イベント関数
　の中身がやたら長くなる。

あらためて書いてみると、やっぱ子供なんだな。素人でもできるレベルの作業だもんなぁ。

>>323 だったil||li ＿|￣|○ il||li

>>352 (゜_゜)(。_。)そんな感じ。だけど、おまえ（ ´∀｀）ﾓﾅｰ

VBScriptが好きでしょうがなくて
VBScriptでAjaxしてるのはVB厨に入りますか？

VB6好きだが、Borlandはいい。
ポトペタでスプリッタができる。
例えば、左exploreスタイル・Treeスタイル、右Form。
右FormでGridも即ポットンペッタンできる。
MFCでスプリッタ&Formはやっかいな面がある。

http://itpro.nikkeibp.co.jp/article/USNEWS/20061129/255223/

開発者によるVisual Basicの利用が急減，JavaやC/C++が主流に

　米Evans Dataは米国時間11月28日，プログラミング言語の利用状況に関する調査結果を発表した。北米の開発者430人以上を対象に調査を実施したこところ，昨年の春と比べVisual Basic系を使用する開発者が35％減少したという。

　Visual Basic 6.0以前のユーザーが減少しているほか，Visual Basic .NETを使用する開発者も26％減少した。

　現在，最も利用率が高いのはJava（45％）で，以下C/C++（40％）とC#（32％）が続く。

　Evans Data社長のJohn Andrews氏は，「プログラミング言語の世界では，1990年代初頭より米Microsoftが圧倒的に優勢だった。しかし，スクリプト言語やJavaの台頭により，Visual Basicの将来は頭打ちになった」と述べる。

　その他の主な調査結果は次の通り。

・2007年にWeb関連の開発に従事する予定の開発者は70％以上

・リッチ・インターネット・アプリケーションの開発に従事している開発者は80％

・Ajaxの利用率は28％

ＯＯＰで作るのは嫌（出来ない）だが、ＯＯＰの成果物は欲しがるのがＶＢ厨。

VBはビジュアル面をさらに強化して、子供（小学生,園児）向けの簡易言語
として生き残ればいいと思う。将来のレゴブロックみたいになるかも。

>>352
>グレープシティは神様、ほとんど依存。
これね。本当にどうにかならんもんかね。

158 名前：仕様書無しさん[sage] 投稿日：2006/11/29(水) 18:20:42
VBプログラマは、ここ数年.NET Frameworkへの移行で四苦八苦してきた。
「静的型付言語」であるVisual Basic .NET（VB.NET）で従来のVBプログラマがまず叩き込まれるのは、「Option Strict On」である。
これによって、Visual Basicコンパイラが「正しい行い」をプログラマに強制する。
VBプログラマの苦痛は、VBが中途半端なニセモノプログラミング言語の汚名から解放され、真のプログラマが利用する言語へと進化するための痛みとして認識されている。
http://www.atmarkit.co.jp/fdotnet/special/pdc2005_02/pdc2005_02_01.html

VBScriptだとjaではない。
Avbxだろ。

>>361 Option Strict Off にすれば？ｗ

>>360 そうそう。
ぶどう街の製品って、使えないんだよねぇ。バグだらけで哀れだし、ライセンス高いしｗ
プリントエンジンなんて、ハンドルされてるクリスタルレポートで充分だと思うけどね。

>>58,>>64
なにそれ？それってもしかして、.NETで、COMオブジェクトが使いにくかったり(えなかったり)、スプリッタフォームに弱点をもってるがゆえのヒガミ？ｗ

:\Documents and Settings\里山芳紀\My Documents\PONITE\up1148973.jpg
:\Documents and Settings\里山芳紀\My Documents\PONITE\2338.jpg
お初ぽにてん

( ﾟдﾟ) ﾎﾟｶｰﾝ　なに自分の名前晒ちてるんだろう

書き込むところ失敗した
VBScriptって構文が.NETっぽくないけど、もう廃れてるんですか？

ぶっちゃけMS-DOSとN88-BASICでよかったんじゃないの？

>>360>>364
グレープシティのあのライセンス体系には怒りさえ覚える｡
もしかするとこれが.NETが浸透しない一因なのではないのかとも思ってしまう｡

でもflexgridだけは必要

ヒント：コンポを買う時代→オプソを拾う次代

>>372
いいヒントだ。

もうVB6には戻りたくないよ。VB.NETヽ(´ー｀)ノﾏﾝｾｰ

>>364
×ハンドル
○バンドル

グレープシティのWebFormsなんか最強だと思うぞ

ASP.NET＞＞＞＞超えられない壁＞＞＞＞Java(JSFとか)＞ASP+VB

俺は、WebFormsが使えるというだけで、.NETマンセー

Webでスプレッドとかツリービューとかを手書きでやって死んでいった
同僚がたくさんいる
クラサバのIDEの問題なんて、それに比べれば大したことはない

Ajaxでスプレッドシートでまともにさくさく動くのなんか
存在しない。一番まともなGoogleの奴でも重すぎ。

なんかすごそうだな
ツリービューとかノードの追加とかもできるん？

C#とVB.NETって構文似てませんか
これもMSの罠なんですか

俺もツリーを手でゴリゴリコーディングしたことある

つか、あれは絶対コントロールを使うべき（その当時は無かったが）
MSDNみたいに重いは、バグるは、チラつくは、顧客は切れるは、で、
結局Aplletを埋め込んで逃げた＋何人か退職したｗ

>>378
ウルトラツリーマンセー

ノードの追加って、動的にってこと？できるよ

　　_, ._
（　ﾟ Дﾟ）ウツトラツリーでググってもウルトラマンしかひっかからないんですがぁ

>>382
これのことかと。
ttp://www.grapecity.com/japan/support/database/P7_339.htm

　　_, ._
（　ﾟ Дﾟ）�dQ た、たかぃ･･･まけてけろぉ

>>323
VB6はインターフェイスの継承は出来るからポリモフィズムも使える。

高いかなー
Webでツリービュー操作できるなら安いもんじゃね？

>>383
このデモみたいなのがVBみたいに作れるのかい？

すっげー。

dim n as new infragistics.webuiultrawebnavigator.node
n.text = "test"
uwt.nodes.add(n)

でノード作れたよ。

MSがグレープシティを買収して
オープンに放流すればいいのに

開発しているのは海外の会社で、グレープシティはそれを売っているだけだろ。

日本語化が主なんだろうな。
バグ報告受け付けて直したりしてるのは
製造元にたらい回ししてるのかな。

グレープシティーってたしか何か宗教がらみの会社だったような

>>391
初めて使った頃は、同じ会社の製品だと思っていたから、
パッケージ毎に時刻の入力規則が違っていて、右往左往した。

結局、Webでもコントロールを貼り付けて、VB6ライクに開発したいわけで

俺もASP.NETで開発して、もうJavaのWeb開発には戻れないと思った
ほんと、ここ数年、JavaのWeb開発はデスマにならなかった試しがない

ツリービューも都度submitでサーバーサイドで書くならなんとかなるけど、
JavaScriptメインだと地獄をみるからな

俺は、クライアントサーバーならVB6かDelphi、WebならASP.NETが最終形だと思う

最新技術を一生懸命に追いかけて、かえって苦しんだから。特にここ数年

あの言語がどーした、この言語がどーした、って熱く語るやつほど現場で足引っ張るし

＞JavaのWeb開発はデスマにならなかった試しがない

それはただ単に開発スキルが無い技術者と開発スキルが無いのに
仕事を受ける営業が悪いのでは…。漏れはそういう事ないが。

まあ、漏れも.NETがステキと主張するやつらの意見を組み入れて
.NETで開発してみたいんだが、あれ鯖がWindowsじゃないとダメじゃん。

漏れの中の評価ではクライアントサイドではExcelやAccessのVBAが
最強だと言う認識がある。

サーバーサイドはやっぱJavaなんじゃないか？と思う。

>漏れはそういう事ないが。

この業界の経験が浅いか、協調性のない人間か

技術を持ってる人でもデスマに巻き込まれるのがこの業界

まあそれがジャワ糞クオリティですよ

超一流のエンジニアが居てもデスマるのがこの業界

ただデスマを悪化させるのは中途半端な奴だ

たとえば
・中途半端なエンジニア
・中途半端なPL

>あの言語がどーした、この言語がどーした、って熱く語るやつほど現場で足引っ張るし

禿げ同

最新技術マンセーの秋葉系PGウゼェ-------------!

趣味でやってろって感じ

職業適性のない人種が最後に流れ着くのがこの業界

できるやつはそもそもこの業界を避ける

いくとしても大手SIerに行くが、DQN下請けのせいでデスマ必死

>NETで開発してみたいんだが、あれ鯖がWindowsじゃないとダメじゃん。

>漏れの中の評価ではクライアントサイドではExcelやAccessのVBAが
>最強だと言う認識がある。








ﾌﾟ

Windows鯖最強だと思うけど。何がいけないのかわからない。
UNIX系が安定しててWinが安定してないってのは
昔の話になってしまった気がする。

足りない脳で考えろ

VB6が現役の頃は、VB6をバカにしていたくせに・・・。

>>402
何かにつけてMSへの上納金が必要になる。

MSへの上納金なんて安いもんだと思うけどなー。
高い生産性、安定性を得られるんだから。

>>406
こういう奴がセキュリティーホールを野放しにしてのほほんとしている。
パッチあてるのに再起動しないといけないＯＳなんて糞だ。

マルチコアでスレッドが最適化されないうに糞
昔は確かに良かったけどね、今は糞爺カーネルでスケジュールがきつい
スレッディング。VMが多数のスレッドを最適化できずに苦しそう。

http://game10.2ch.net/test/read.cgi/gameama/1165021442/

　『朝日戦争』　発表未定

朝日戦争(ちょうにちせんそう)とは統一朝鮮が日本を占領下に治めるまでの仮想世界を描いた
スパイ型オンラインFPSゲーム。

各プレイヤーは日本に潜伏する在日朝鮮人工作員となり、他プレイヤーと協力しながら
わずかな銃器、細菌兵器を手に日本各地を転戦する。
日本での職業は自動的に割り当てられ、普段は日本人に成りすまし自衛隊に見つからないよう警戒し、
他プレイヤーが属するメディア、警察、自衛隊、工場、学校などの情報を交換しながら拠点攻略を目指す。
日本人を1人殺すごとに1点が加算され、各地に点在する発電所、駅、空港、軍事施設、工場、放送局などを
破壊、占拠すると莫大なボーナスが得られる。
貴重な武器、弾薬、細菌兵器は拠点、軍事施設、降下されるパラシュートなどから調達しながら高得点を狙おう。
得点はランキングされ、100万点を超えるものには英雄の称号が与えられる。


っていうゲームを誰か作ってくれ。

>>407
なるほど。パッチあてたときの再起動が問題かー。
Webサーバーは分散してるから1台ずつ再起動すればいいけど
DBはしてないからなー。どうしてるんだろ。

>>402
同意。
サポートやってるが、Linuxのほうがトラブルが多い。
特にドライバ系のバグはたちが悪い。
セキュリティホールはどちらにもそれぞれ、それなりにある。

>>410
つ[クラスタ]

>>412
そういえばそれしてた。ディスクだけ共有ディスク使って。
あれ？問題ないじゃんｗ

もう、冬休みが始まっているのか？

オブジェクト指向とか、WindowsよりLinuxとか、大企業以外必要なし

簡単にできることをわざわざ難しく実現する必要なし

みんな疲れてるんだよ

>>415
ダウンサイジングは進行中だと思うが、
大企業で、
UNIXを入れられるところにLinuxをもって来ている事例はあるだろうか。
Windowsサーバはうんざりと言うのは、身をもって感じているけれど。

>>416
大企業は、わざわざLinuxでトラブるより、ベンダーのUNIXを使うかな
Linuxは開発環境で一時的に立てることもあるけど
Windowsサーバは部門レベルで使うし、要は適正規模の話だよ

VB6対.NETの話は、単に言語の問題ではなくて、MSのOS寡占がネックだよな

技術的なことを言うと、普通、優れた技術は、たとえばそれが中小企業が開発した
場合、その中小企業が特許取って独販するか、一旦大企業に買い取られる
それまでに、限られた範囲で良い技術だけが生き残る

でもこの業界の技術は、こなれないうちに、提灯記事によって新しいもの好きの
開発者が実業のプロジェクトに適用してしまう
しかも、なぜかこの業界では、技術が広まるスピードは遅いが、使い物になるか
どうかのジャッジは遅い

EJBなんかその一例だし、オブジェクト指向設計やその言語もフレームワークや
コンポーネントのサプライヤを除いて、「労多くして功少なし」という実感を
持ちはじめている技術者は多い

>>417
しかも、なぜかこの業界では、技術が広まるスピードは遅いが、使い物になるか
どうかのジャッジは遅い

ここ日本語間違ってますので、文言修正お願いします。PGレベルの脳みそでは
間違いがわからないかもしれないけど

ほんとEJBとか飛びつくアホが多くてﾜﾗﾀよ

しかも、なぜかこの業界では、技術が広まるスピードは早いが、使い物になるか
どうかのジャッジは遅い

出版業界の陰謀

激しく同意

どっかに、ステートレスビーン以外は負の遺産とかレスがあった。
EJBはSpring+Hibernateに置き換わろうとしてるね。
その時代も、新しいもん好きのオタクがEJB、EJBって騒いでた。

MSのIDEのお膳立てとWebFormsは評価できるけどな

Javaのプロジェクトなんか、Eclipseの環境設定とか思ったより時間かかるし、
いろんな技術が出てる割には、設定がマンドクサで生産性が悪くて結局デスマ

そうはいうけど、既存技術に実際に触れてみてその上で
どういう点が問題かっていうのを逐一体感するっていうプロセス無しには
本当の意味では最新技術の利点は享受できないわけじゃん。

EJBのセッションbean→Spring 然り
EJBのエンティティbean→hibernate然り
手続き指向→オブジェクト指向 然り

結局、新しいものには常に飛びついていかざるを得ない。

＠○Tとか○経ソフトウェアとかJavaW○rldとかの記事にすぐに
飛びつく馬鹿が多いからな

そいつらは設定自体が大好きだから、生産性への寄与なんて
眼中にないんだよ

ちゃんと技術を選別できる奴が、そいつらをいかに諌めるかが、
実はITプロジェクトにおける最重要項目

>>424
その技術を適用できるかどうかの試験は、大企業とか大手資本が
買って出るべきなんだけど、ゼネコン体質だから中小を人柱にする

しかし優秀な技術者が、中小に行くわけがない
彼らは大企業の研究職かアカポスに行くことになるが、舶来中心の
ソフトウェアの世界で、日本人が活躍できる場は少ない
RubyやSeaserみたいに、オプソで花開くこともあるが

中小にいるのは、技術者じゃなくてオタクでしかない
オタクはとにかく新しいものや設定が大好きだから、彼らが勧めるものが
生産性を上げる可能性は低い

もはやVB6というよりJavaスレ

あたらしい技術に飛ぶつくのはヴァカだ、って意見は解らなくもない。

しかしさ、枯れた技術(COBOL,RPG)とかでデスマしている
連中はただのアフォで無能で救い様のないヴァカ？
あいつら何十年も同じ事をグチりながら深夜まで頑張っているんだが。

漏れは同じデスマするなら新しい技術の人柱になってデスマに
なる方がまだ納得できるが。

コボラーのデスマは、もともと構造化プログラミングさえされてないルーチンを
改修するときに大火事になるんだよ
ピリオド１個で地獄を見るからなｗ

新しい技術を使って生産性を上げられるかどうかは
どうしてもインプリメンテーションを実施する担当者自身に依存する。

日本だけじゃないの。いまだにその辺割り切れてないのは。

漏れ的にはデスマと新しい技術との関連性はそれほどないなぁ。
COBOLでデータベース操作するのとSQLでデータベース操作するのと
どっちか生産性高いか？って聞かれたら間違いなくSQLだし。

でVBとJavaだと、小さい規模のだとVBで大きめだとJavaの方が生産性高いなぁ。

おそらくデスマするヤツはどんなハードウェアでもソフトでもデスマになる。

>>94
広島県人ﾊｹｰﾝ

少し枯れてからのほうがいいよ。枯れすぎは良くないけど。
今最高なのはVB2005

デスマの原因を外的要因（仕変の取込など）と内的要因に分けると、
内的要因のうち、言語の習得の難しさ、プロジェクト固有の
OOフレームワークの理解、煩雑な設定による時間の浪費など、
新しい技術に関与している部分は多々ある

430の続き

だから、素人を集めておいて最新技術が使ったけどデスマになったから
結局その技術何の役にも立たなかったねなんていってんのは全然筋違いだってこと。

むしろそういう素人が人海戦術やってたような作業を、
「新しい技術を使うことで」軽減する、または全くやらなくてよくなるって状態を目指すべき。

つまるところ、デスマは、参画してる要員のスキルと適用する技術のアンマッチで起きる

>>435
ほとんど同意なんだけど、そろそろOOに関しては判定しなければならないと思う

その上で、OOは、「フレームワークやコンポーネントのサプライヤを除いて」
生産性も保守性も上げてないと言っている

フレームワーク（ディスパッチャとか）やコンポーネント（コントロールとか）に
適用すればよいことは、ずいぶん前から分かっていたことで、それ以外の
クライアントの部分については、VB6で良かったのではないか、という括り

>だから、素人を集めておいて最新技術が使ったけどデスマになったから
>結局その技術何の役にも立たなかったねなんていってんのは全然筋違いだってこと。

結果的にそれが「検証」になったという意味では無駄ではないと思うが、
実業に適用するのももっと慎重にならないと、提灯記事にのせられて
いつまでも不幸なデスマを繰り返すんではないかと

>>437
VB6の「何が」良かったっていう主張なのかもうちょっと具体的にしてほしい

結局、VB6のクラスモジュールが実装継承できればよかったんだよ

>>438
>実業に適用するのももっと慎重にならないと、提灯記事にのせられて
>いつまでも不幸なデスマを繰り返すんではないかと
素人が混入してしまうプロジェクトにおいてそれは確かなんだが、
むしろその原因は最新技術をつかったことじゃなくて素人をプロジェクトに
まぜてしまったことに求めるべき。

素人≒抽象化ができない奴（つまり分類・整理、階層化ができない。面倒臭さが先に立つ。頭が単細胞。でも、だらだらコード、おれおれコードなら書ける。）

>>440
実装の継承なんて別になくてもいい。
basを無くしてくれれば。

OOP無しのコードとOOPが適切に使われたコードでは、コードの可読性が全く違う。
まともなOOPのコードは、アウトラインツリーをドリルダウンするかのように違和感
なく読み下していける。
ドキュメントも同じで、見出し、段落、節、本文が適切に配置された論文は読み易い
が、乱文は論意を把握するのに苦労する。
馬鹿にはそういう論文は書けないし、まともなOOPのコードは書けないんだが、VB６
の方がいいと言うのは、つまり世の中には馬鹿が多いということ。ワードよりもエク
セルでドキュメント書く奴が多いのも、同じことを示唆している。

すみません。俺もバカです。高卒です。

さすがにOOPまで生産性の観点から否定する奴はどうかと思うぞw

自信もっていえるけど、仮にOOPが生産性の向上をもたらしてない、あるいは
低下をもたらしてるなら、それはOOPの問題じゃなくてアンタ自身の問題だから。

それとよくメンバに馬鹿が混じってるからOOPは怖くて使えないっていうことを
現場の実践上の観点からいう人がいるけど、これもおかしい。

論理が逆立ちしてるんだよな。
ある意味人間は全て「馬鹿」だからこそOOや構造化といった手法に頼らざるをえないんでしょ。

世の中の人間が全部フォンノイマンみたいだったらOOも構造化もいらねえよ。

VBでOOP適切に使えばいいやん。

>447
適切に使えないから問題なんでしょ？

>>444
>まともなOOPのコードは、アウトラインツリーをドリルダウンするかのように違和感
>なく読み下していける。

構造化プログラミングでも可能。それ以上にOOで何が分かりやすい？

>>446
言いたいことはよくわかるんだけど、たとえば
「この最新鋭の戦闘機が旧型に比べて撃墜されやすいのは、新型に
技術的な問題があるのではなく、乗りこなせないパイロットが未熟なだけ。」
といくら力説しても、
「戦争に負けたくなければ旧型を使わざるを得ない」と言われるだけじゃまいか。
さらには「未熟なパイロットでもそれなりに戦果を挙げられる機体」こそ
名機と呼ばれるのではないだろうか？

つまりOO使える人はニュータイプってこと？

俺が・・・ニュータイプ？

ぼくが・・・いちばんうまくOOを使えるンだっ！

OOは殺し合う道具ではないわ。

>>52
>テンプレートパターンによて、関数の呼び出し順序を強制するくらいは
>使い道はあるけど、共通関数をクラスで作ろうが関数で作ろうが、
>ローカル変数を呼び出し側に置くか、共通クラスのインスタンスに
>閉じ込めるかの違いがあるくらいで、格段に生産性や品質が上がるわけでもない

ここに集約されてるけど、業務関数を書く人にとって、クラスベースで書く恩恵はあまりない
関数を使うときのローカル変数が減る代わりにセッターが増える
インスタンス生成部分のコーディングがうざいだけ
だからこそDIなんだけど
コンテナがしかるべき生成をやってくれれば、業務クラスは標準モジュールチックに書ける

OO言語は大歓迎だけど、お手軽ツールのVBなら、もっとVB6みたいにきれいに
隠蔽してほしかった
逆に言うと、標準モジュールやフォームモジュールを擬似的に実現してほしかった

実力のある人だけがカスタマできる余地を残して

>>455
そこまで分かっているなら、使い分ければいいだけ

OOでテンプレートパターンやファクトリーパターンで事前・事後処理の
セマンティックスを強制できたり、呼び出し側に変数を用意させずに
カプセル化するメリットは大きい
生成部分のコーディングが面倒な部分は、たとえばコンテナに委譲する

なにも、給与計算で管理職と平社員の残業代を多態性で書くわけじゃない
（提灯記事にありがちな例ねｗ）

>>450
そのとおりで、棲み分けとして、VBはAT車であって欲しかった
ここぞというときはMTもできるAT車もあるし

つーか、VB.NETがＯＯがわからないから嫌いなんじゃなくて
GUIから配置できなくなってるから嫌いなんだよ。

つーか、VB.NETが駄目==ＯＯがわからない奴とか勝手に決め付ける奴ウザイ。
もっと人の話をよく聞け。
問題の切り分けもできないの？

俺等はVB.NETがVB6の頃に比べて明らかに使いにくくなったのに怒ってるの。
ＯＯとは関係無い。
強調するけどＯＯとは関係無い。
ＧＵＩで置けたはずのものがおけなくなってるのもＯＯが原因じゃなくて
単にVB.NET作った奴がアフォなだけの話じゃん。
javaのswingではとっくに同じことできてるんですよ。もちろんＯＯですよ。

DelphiをPascalじゃなくてJava5で仕切りなおせばめちゃくちゃ売れる

Swingに2Way-Toolあるか？
すくなくともJBuilderは糞だったぞ

>>449
OOPによる分かり易さのメリットの一つに、分析からコーディングまでを一貫した概念で
作業できるという点がある。
例えば、学校のあるシステムを作るとした場合、学校、教師、生徒という概念を、
学校--◇教師◇--◇生徒　というふうにモデリングして、ほぼそのままソースに落として
いける。
構造化プログラミングの場合、これらの関係を一旦プロセスの観点から細分化し、関数に
構造体なりを渡すような作り方になってしまう。考え方の違いかもしれないが、俺は、
hoge(teacher, student[]) より、teacher.hoge(student[]) の方が断然分か
り易い。

まぁ、これ自体はVB6でもできるんだが、クラスの継承が使えないのはいたい。
例えば、校長、教頭、教師の権限関係をVB6ではモデリングできない。フラグを使うても
あるが、やっぱり可読性を損なう。OOPを使うと制御文(if文等)を使う頻度を減らせるメ
リットがある。

後、逆の奴もいるな。

VB6の方がよかった＝ＯＯは使えない

とか決め付けてる奴もいい加減他の人間の主張を曲解して、
自分の主張に組み入れるのを止めろ。つーか、死ね。

VB.NETでＯＯっぽくなったのは俺も歓迎する。
だからといって他の機能がデグレードしていいわけないだろ。
しかも、類似製品がすでにやってて解決方法もやり方も見えてるのに
面倒だからやらんかった・・・みたいな対応。なめてんのか。

>>456
OOでテンプレートパターンやファクトリーパターンで事前・事後処理の
セマンティックスを強制できたり、呼び出し側に変数を用意させずに
カプセル化するメリットは大きい
>>461
>hoge(teacher, student[]) より、teacher.hoge(student[]) の方が断然分か
>り易い。

つまるところ、OOなんてそれだけなんだよ

まったくもって、銀の弾丸ではない

しかし、Cのポインタで無理やり書くと嫌われるけど、OOで書くと読みやすい
その読みやすいっつーのは、人間様にとって、もっとも大事なこと

>>458
お前の言ってる意味がわからん。GUIでなんか置けなくなったのか？

>>461
VB6は実装継承は出来ないけど、
ポリモフィズム使えればOOPの旨み十分でしょ。
実装はオブジェクトコンポジションでいいよ。

>>464
多分自分で継承して作ったクラス。
おけても色々使いにくい。

VB6でポリモルフィズム使えるの？
コーディングサンプルくれくれ君

カスタムクラスもおけるっつーの！
前も書いてなかった？
それとSwingの話は？

Implements

>>466
.NET コンポーネントつくれるやん。つくり方が分からんだけちゃうんのん？

>>465
でも、無いよりはあった方がいい。
テンプレートメソッドパターンを始め多くのデザパタが使えないわけで。

Javaプログラマーですがデザパタ知りません＞＜

>>472 いちいち報告せんでもよろしい。

>>468
カスタムクラスは置けても結局プロパティの設定ができないじゃん。
意味無し。

なんか>>458みたいな人見てると物悲しくなるなw
自分が馬鹿だ、ということもわからないほど馬鹿なら、
プログラマなんてやらない方がたぶん俺の人生幸せだろう、と思うことも出来ないわけで。

>>474
プロパティ設定命なんだなぁ。その一点だけでVB.NETが嫌いなのか。
他のメリットと引き換えにできないぐらいに。
つぅか、つくれるっつうの。そんなにプロパ設定したけりゃつくれよ。

>hoge(teacher, student[]) より、teacher.hoge(student[]) の方が断然分か
>り易い。

こういうのとかもう古いよ。
とくにASP.NETなんかだったらBCEパターン推奨だから、
teacher_svc.hoge(teacher, student[])
となって、ビジネスロジックの部分はメソッドの形態だけ見ると
むしろ構造化設計に近くなるといえる。

あくまでも大事なのは各機能の高凝集性・疎結合性であって、
この辺の感覚無しに真にOOのメリットを得ることなんて出来ないと思う。

>>476
いや、普通にさ、ウィンドウにに
浮動小数点数値制限したエディットボックス（入力制限がかかってて数字と「．」しか入らない。自分で継承して作成したクラス）
を複数配置してさ。
クラス弄れば設定全部変わるみたいなことできれば俺も満足なんだよ。

>>477
お前みたいなトンチンカンなこと言ってる奴が皆をデスマに導いていく。
>>478
できるっつうの。つぅかお前にできないことがVB.NETの問題なんだな。

>>479
できねぇって。
やってからいえってマジで。

>お前みたいなトンチンカンなこと言ってる奴が皆をデスマに導いていく。
どこが？

>できるっつうの。つぅかお前にできないことがVB.NETの問題なんだな。
同意。つか.NETすげー。

>>480
できるって。お前ならやれる。がんばれ。

478=458だよね？
こんなことネタで言うとも思えんから真面目に言ってるんだろけど、
本当同情するはこういう人。
>>479の言うとおり、そんなの普通にできるし、現に俺も自作のコントロールなんて
いくらも作ってるから。君が例に挙げた数値だけ入力可能なコントロール含めて。

あんたプログラマ向いてないよ。
まあこういう奴は得てして人の話に聞く耳もってないんだけどw

あ、わかった。プロパティの追加も含めて、全部GUIでやりたいって話じゃない？

>482
それは糞上司スレで頻出の発言だなｗ

なぜか>>461はOOP覚えたての元VBプログラマな気がした。

>>484 VB6だとそんなことできるの？

>>477
>teacher.hoge(student[])
>teacher_svc.hoge(teacher, student[])
処理分担が移っただけのような...どっちもOOPじゃん。

>>487
同じことがやりやすかったよー。
コントロール配列あったもーん。

>>479
俺が>>477でいいたかったのはOOのメリットが見てくれだけの話じゃなくて、
たとえば>>477の例で説明すると、
・teacher_svc以外ではteacherの内部状態を変更しない。
・teacherはありえない状態を設定できない。
ってルールを守る・守らせることができて初めて
保守性・拡張性っていうメリットを得ることができるってこと。

逆にいうと、teacher_svc以外でteacherの内部状態を変更するような
設計をしてしまうといくら見掛けがOOでもメリットがないってこと。

たしかに、>>489には
http://www.microsoft.com/japan/msdn/net/general/custdsgnrdotnet.aspx
に書いてあることは難しいかもなぁ。
でも、それなりに分かり易く書いてある本もあるからがんばれ。

>>491
これもやったよー。
超面倒だったよー。
コントロールごとやらせんのかよー。
ＶＢ６に戻してよーｗ

あれ？.NETってリフレクションって使えないの？
もし使えるなら自分でVB6コントロール配列相当の
汎用コンポーネントつくればいーじゃん。

よくわかんないけど、なんか解決すんの？

>>490
つまりフレームワーク設計者に、VB6あがりプログラマがやんちゃなことをしないように面倒をみる責任があると？

>>493
いやだから、そんなことができるスキルあるならコントロール配列が無いことにブーブー言わないっつうの。

しかも、なんかVB自体のカスタマイズみたいな話になってて微妙にズレてねぇ？
やっぱり、できないんだろ？

コントロール配列が無いって、コレクションクラスに、コントロール入れるのじゃ駄目なんだろうか?

リフレクションを使用したコーディングはもはや常識です。
まぁ使わなくてもカスタムコンポーネントは作成できます。

うう、この微妙で言葉にしにくい強烈な不便さはちゃんと使った人間にしかわかるまい。
そのおかげでユーザー減ってるっちゅーの。
どうせ使ったことなんてないんだろ、お前等！
お前等のわからんちん！
もう、知るか！死んどけ！

それはそうと、>>498 の件名の後ろについてる変な記号、何？

件名が何のことかしらんが Be

できないならMFCでコンポーネント作って呼び出すだけにするとか
考えないの？俺らは問題を解決するのが仕事だろ

>>477
BCEパターンから
>逆にいうと、teacher_svc以外でteacherの内部状態を変更するような
>設計をしてしまうといくら見掛けがOOでもメリットがないってこと。
みたいなことがどう導かれるんだ？

たとえば、１レコードのインスタンスteacherがあって、それを永続化したいとき、
teacher.save()よりもtacherDA.save(teacher)みたいな方がいいってこと？

まだコントロール配列がどうのいってんの？
こんなもの必要ない理由が十分書いてあるのに・・・
自作したって簡単だし
イベントレシーバをインデックスで判断するなんてバカだろ
ラップしろよ

>>503
なんで.NETのコンポーネントをMFCで作るんだよ。VB.NETで作れよ。

>>504
うーん。というよりteacher.save()っていう形式にこだわることが
OOの本質じゃないってこと。
わかりやすさっていう点ではteacher.save()ができるのが一番
いいのかも知れないんだけど、それだといろいろ実装レベルの問題があることが
わかってきた。
当然teacherをビジネスルール付きのドメインモデルとして
構築する場合(MVCパターンなど)はteacherの内部状態はteacherにカプセル化される。

インスタンスの永続化はビジネスルールのレイヤーじゃないので
ちょっと例としてはあれだが。

まぁなんにしろケースバイケースじゃないの？
こだわらないことにこだわることもこだわることにこだわらないことも。
ただ闇雲にひとつの技術論に固執する必要はない。最善の手法というもの
は時代によってまた状況によって変わるもんだ。その人にとって一番良い
選択肢を選べるのが一番の幸せではあるんだが。

うーん、今がそれほど選択子豊富な状況とは思わないよな。
最後に広まったテクノロジの問題点だけが、いくつかブランチとして
（似たような）ソリューションの選択肢を持つって感じ。

俺も

DataAdapter.Fill(teacher)

みたいなコードみると、OOってなんだったんだ？と思う。

teacher構造体をデータアクセス用の関数で
Load(&teacher)
してるのと同じだし。

オブジェクト指向の次はどうなるんだろうな。
アスペクト指向は別物というより、補完するものだし、
サービス指向は適用ドメインが限定されるし、
コンポーネント指向も根底にあるのはオブジェクト指向だし、
OOP自体は今後数十年はなくならないと思うが、それとも言語
が進化してそれすら感じさせなくなるんだろうか。
考えてみれば、今の言語もこれまでの技術論の集大成みたい
なもんだもんな。
究極の進化形は、仕様書や言葉等の自然言語からその曖昧性
も汲み取ってシステムを組み立ててくれるようなコンパイラ
かな。

.NETFramework、
1.0
1.1
2.0
3.0?

ちょっとバージョンアップ早すぎない？？。
そんなにVSたくさん買えないよ・・・。

>>510
ん？　DataAdapter.Fill(teacher)　も普通にOOだと思うが。
デザパタでいうAdapterパターンとBridgeパターンの応用みたいなもんじゃね。

現状と問題をどの視点から見渡すかって
概念がないでヤレあの技術だあの理論だ
なんていったっていい笑いものだろ

てか.NETになってタダでアプリ作れるようになったのに
企業は未だにVB6ってマジですか？って気になる。

>>511
関数型言語とか、いろいろ吸収すべきエッセンスあるとおもうけどね。
OO含む手続き指向は、状態変更ってことに対して無頓着すぎたって思うし。
仕様の形式化とか、形式化された仕様自体の再利用とかそういう方向に行かないかなあ。

>>516
仕様の形式化と再利用は歓迎だけど、なんでもかんでもXMLで記述ってのは
見直されつつあるね。XMLは元々冗長性をもった言語だし、コードで書いた
方が楽な場合もあって本末転倒な気がする。特にスクリプトなんかのインタ
プリタ系言語の場合、コードと設定ファイルの境界が曖昧になりつつある
ような気がする。設定ファイル弄るのもコード弄るのも手間は同じだからね。
制御構造が柔軟な分、コードの方に分がある。
仕様書がコードに近づくのか、コードが仕様書に近づいていくのか・・・
あ、ＶＢスレだった。失礼。

javaは有無を言わさずxmlを強要してくるのがうざい

Javaでxmlを扱う場合、Eclipesでの開発が前提にあり、それらのプラグインが
自動的にxml生成するから現実的にxmlがウザいとは思わんけど。

手作業とかでイジる場合もあるけど、テンプレートからコピーして
適当に置換するだけでオッケイな場合がほとんどだし。

そりゃ、メモ帖とかでJavaのコードかいている人には苦痛だろうけど。

VBできないやつの発言ってレベル低いよなｗｗｗｗ

GUIでコントロールがどうたらこうたらとか騒いでる奴は、
VB6の検索で正規表現が使えなかったり、ファイルや
プロジェクトからの検索結果を一覧表示できなかったり、
適正なマウスドライバ入れないとスクロールホイールが
効かないことには不便を感じてないのか？

マウスドライバ？w

Java7から登場するjava.lang.XMLの構文はYAMLに近いものにしようかという議論がある。
JavaOneでアンケートとってたらしいし、Sunも冗長性を認識してないわけじゃないよ。たぶん。
てかYAMLとかならコンバータも余裕で作れるっしょ。

>>518
.NET もXMLてんこもりじゃねぇかよ。

JavaのYAMLパーサなら既にあるよ。

>>521
それを補って余りあるほどIDEがモッサリしてないからね。

YMALがいいよ、YAMLマンセー、てかINIでもいい。XMLウザっ！

XML最高じゃん。

XML Schemaがあれば別にコンパイル済みなXMLにしたって問題ないんだよね。
近い将来そういう方向に流れてくとは思うが

XMLってどうしていちいち終了タグに開始タグと同じ要素名が必要なんだろ。
あれがあるから冗長だっていわれるんだよ。終了タグは全部</>とかでよかった
気がするんだが。そしたらちったぁすっきりする。

Lispでそれがきもかったから止めたんだよ。
あれは書きやすいがバグりやすく特定しにくい仕様だからな。
ある仕様が糞だと思ったら何かとトレードオフしてると思え。

S式とかYAMLの書きやすさは捨てがたい。
XMLの子要素として使うのはどうよ。

XMLの柔軟性はVB6プログラマ向けじゃないなぁ。CSVで十分。
構造が自由に決められるより、１つに決まってた方が余計な頭使わなくていいのだ。

スレと関係無いけど
XMLって無駄に階層化すると後で参照に行けないよねｗ

＜データＡ＞
　　＜データＢ＞
　　　　＜データＣ＞
　　　　　　＜データＤ＞
　　・
　　・
　　・
　　＜データＸ＞
　　　　　→（後の追加でここでもデータＤが必要になった）

作ったときはよくても後で↑みたいな構造になると作り直した方が早くね？ｗ

ハナッから

＜データＡ＞
　　＜ID_データＢ＞
＜データＢ＞
　　＜ID_データＣ＞
＜データＣ＞
　　＜ID_データＤ＞
＜データＤ＞
＜データＸ＞
　　＜ID_データＤ＞

みたいに構造化ライフで作った方が変更効きやすくね？
あ、ちなみにＩＤが必要になるほどまとまったデータのときね。

お前はデータベースの設計を勉強した方がいい

>>535
気合と勘で作ってたからイマイチわかんねｗ

データＸに追加なら小手先で誤魔化しようがあるけど、
その上にデータ０、１、２、とかあって、それに追加とかなったらわけわからんようになるな。

＜データ０＞
　　→（後の追加でここでもデータＤが必要になった）
＜データ１＞
　　→（後の追加で・・・）
＜データ２＞
　　→（後・・・）
＜データＡ＞
　　＜データＢ＞
　　　　＜データＣ＞
　　　　　　＜データＤ＞
　　・
　　・
　　・
　　＜データＸ＞
　　　　　→（後の追加でここでもデータＤが必要になった）

ちなみに＜／・・・＞は省いてる

データの一意性もへったくれもない設計だな。
xml以前の問題かと。

>>538
でも、既存の引継ぎとかしたりすっと大抵こうなんじゃん。
ＤＢに大量にデータ入ってて変えられなかったりとかあるじゃん。
仕事のほとんどこんなのの辻褄合わせなんだけど・・・。
うっかり階層データにすると変更できないんだよね。

大抵こうなる、と言うか正規化ができてないのを引き継いだ場合の話か？
うっかり階層データもうっかり横長DBも似たようなモンだろう。
まあCOBOLerからの引継ぎはそんなモンとあきらめれ。

そこは一から作り直す提案と言うかチャンスを自分でつくれ。

VB厨は子供部屋でVB音頭でも踊ってろｗｗｗ

月刊ウインドウズデベロッパーマガジン | 今月の内容
ttp://www.shoeisha.com/mag/windev/new.asp
【特集1】Visual Studio 20005この先の未来へ

Visual Basic .NETコッコ倶楽部
Excel VBA実践教室
西田雅昭の新・Visual Basicのツボ

あんだけ嫌われていたJavaScriptがねぇ、分からないもんだよねえ
ttp://alfalfa.livedoor.biz/archives/50724029.html

Ajaxやらされてる連中にすれば
JavaScriptは糞以外の何者でもないだろ

最強言語VBがあれば他はいらないなー

そうだね。だけどブヒアプリはいらないなー

まあ、何も作れないやつは気楽に好きなこと言えるからいいよな。

VBを極められないアンチの戯言が情けないねｗ

ブビを極めた人が居るのかもしれない。だけどブヒアプリはいらないなー

549はいらない

おまえのために存在してんじゃない。どっちにしてもブヒアプリはいらないなー

☆社会の寄生虫、派遣会社をぶっ壊せ！やつらは背広を着た８９３だ！

私は今ここに要求する！派遣法を改善・改正せよ！
サラ金真っ青の３０％、４０％超の暴利を搾取し労働者から毟り取る。

　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！

ついでに薄利で中小の乱立する派遣会社に消えてもらって
　派遣は大規模派遣会社のみが薄利多売でやる商売にしろ。
そうすれば労働者の手取りも増えてニートやフリーターも減るだろう。

【付録漫画】フリーザ様に学ぶ派遣会社搾取問題
　http://up.spawn.jp/file/up56249.jpg

こぴぺにあれだが、派遣問題と、ニートの間には箱根の山と三途の川が流れるぐらいの差がある。
ニートが派遣になれっこないじゃん。ｗ
派遣がニートというか廃人になるのはろーりんぐすとーんだが。

こぴぺにあれだが、プログラマと、ブビ中の間には箱根の山と三途の川が流れるぐらいの差がある。
ブビ中がプログラマになれっこないじゃん。ｗ
プログラマはブビ中にはならないがニートというか廃人になるのはろーりんぐすとーんだが。

アンチくんは何年生？

XML、EJB、UML(OO)、そして.NET

鳴り物入りで登場して、知ったかぶりが踊らされてた割には
いまいちパッとしない絵空事技術

EJB以外は結構パッとしてますが何か？

XML…データベースやBtoB、XSLとぶつけてHTML生成などと
　　　　期待されたが結局設定ファイルどまり

UML…顧客と見栄っ張りを煙に巻くには大変便利。似非インテリ御用達

OO…裸の大様の衣装。低学歴が下駄を履くにはこれしかない！ｗｗ

EJB…2.0で見捨てられ、3.0で逆進化。あ、退化か

.NET…OSになれきれずお役御免予定の劣化版JavaVM

558･･･自分が不得手な技術の功績や実績を素直に受け入れられない天の邪鬼。

天の邪鬼の誤用乙ｗ

いや別に間違ってないけど。
「素直に受け入れられない」→「つむじまがり、ひねくれ者」→「天の邪鬼」
ものすごく自然。

現代人でありながらどういう仕事してたらXMLもUMLも使わずに済むんだ？

ゲームならOO以外はあんまり使わないよ。
XMLもイマイチ使いどころが難しいから使わないなぁ。
簡単なものならCSV程度で充分だし、
込み入った構文ならスクリプトエンジンを組んだり
専用ツールを自作するし。
.NETはC#でツール作るぐらいかな。
UML?EJB?なにそれ食えんの？

OOには、今まで職業プログラマが培ってきたテクを明文化したもので別に
目新しい技術じゃない。
ただ、セマンティックの記述が難しく、どうしてもアカデミック？な表記になる。
それによって、うれしそうに小難しいことを言いたがる厨が湧くのはしょうがない。

OOが業務プログラムに適用してうれしいかという疑問はごく自然。
抽象化しやすいものは、基本的に目に見えるものであり、巷に溢れる
業務概念を擬人化して抽象化しているような「絵本」は、えてして現実的ではない。

XMLが設定ファイル、とくにDBのスキーマと入れ子用の設定ファイル以外に
使い道がみいだせなかったのは事実。

.NETはJavaの対抗馬以上にMSの飯の種なんだから(ry

EJBは2.0で猛省して、3.0では原型をとどめていない。
でも、それでいいんじゃないか？
行き過ぎた設定や難しさは、淘汰されるんだよ。
だけどなぜOOが淘汰されないか？そんなに現場でデザパタする人がいなくて
実害を受けていないから。
フレームワークはそこそこOOしてるけど、たいていオプソのパクリ。
無理してUML図の納品を強制する元受も、無駄と分かってやんなくなってきた
顧客が業務ごとのシーケンス図やコラボレーション図を欲しがるわけないっつーのｗ

>>561
微妙に間違っているような気がするぞ
俺も国語得意じゃないから、的確に何がおかしいのか言えないけど

>>564
まあ、君が実務をやってないか、やっててもろくな仕事してないのは良く判った。

アンチは仕事ができないクズだものな

そもそもプログラムを仕事の手段として割り切れる人間か、そうでないかで話が違うんじゃね？

http://local.joelonsoftware.com/mediawiki/index.php/%28Forum%29_%E7%A7%81%E3%81%AF%E3%81%AA%E3%81%9C%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%8C%E5%AB%8C%E3%81%84%E3%81%8B

自分は仕事を実現する手段として見る部分が多いから、
↑みたいな話は賛同できる部分がおおい。

このスレにも散見できたけど、

OOの利点である継承がVB6では使えないじゃん→だからVBだめじゃん

とか声高に叫ぶバカは、なんつーか…いろいろバカだな。

＞OOの利点である継承がVB6では使えないじゃん→だからVBだめじゃん

なら反論してみ？

ＯＯとフレームワークは関係無いお。

「それに昔のガールフレンドを殺そうと思ったら、丸頭ハンマーに代るものはありません」
「確かに。」
ここくらいかな、笑えたの。

ハンマーに当たるんがライブラリだし、ライブラリの上のレイヤーがクラスライブラリじゃね？

ライブラリが弱いと、逆にソースコードジェネレーター＆フレームワークが活躍することになってしまう。

XMLってこれからだろ

XBRLとか

>>569
関係ない訳ないだろ。

.netのDataSetとか内部はXMLでのDBだし。
使ってないとか、設定ファイルとか言ってるやつは、タグかかれたTEXTファイルで見えないと駄目なんだろうね。

>>573
関係ないよ。

プログラム書く場合に、手続き言語で書きまくるか、手続き言語にクラス文法が追加されたOOP言語でクラスライブラリを使うかの違いだから。

ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

もっというと、OOP言語でOOP文法追加前のソースもコンパイルできるんだから、論理的に全く関係無いと言い切れる。

C++コンパイラでCをコンパイルできるし、DelphiでTurbo Pascalソースをコンパイルできる。

>>576
　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　 　　　　　j
　彡､　　　|∪|　　 |　　　 　　　 Ｊ
/　　　　 ∩ノ ⊃　 ヽ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／

つりじゃねーよ、事実だよ。

OOP言語ってのは既存言語にクラス構文追加してるだけ。

まぁいいじゃん、OO好きな人はOO使えばいいし、OO苦手な人は、・・・そうだな、せいぜい可読性の高い書き方だけはしてくれ。

つhttp://kmaebashi.com/programmer/object/index.html

私はコレで、VB 6を卒業しました
ttp://www.atmarkit.co.jp/fdotnet/vblab/opensemi_02/opensemi_02_01.html

javaのswingだけは勘弁してくれといいたい。

>>582 何で？？

>578
　　　　　　　　　　　　　　 .| 　 |　　|　|　　 |　 　 |　　| ｜ 　 |　　 | 　 |｜　|　|
　　　　　　　　　　　　　　 .| 　 |　　|　ﾚ　　|　 　 |　　| ｜ 　 |　　J 　 |｜　|　|
　　 　∩＿＿＿∩　　　　| 　 |　　| 　 　 J　 　 |　　| ｜　　し　　 　 |｜　|　|
　　　 | ノ＼　　 ,＿ ヽ　　.| 　 ﾚ　｜　　　　　　｜　 ﾚ｜　　　　　　　|｜ Ｊ　|
　　　/　　●゛　　● | 　 .J 　　 　 し 　 　 　 　 | 　 　 |　　　　　　　｜|　　 J
　　 |　∪　　( _●_)　ミ　　　　　　　　　　　　　.｜　 　 し 　 　 　 　 J｜
　　彡､　　　|∪|　　 |　　　　　　　　　　　　　　.Ｊ　　　 　 　 　 　 　 　 ﾚ
　/　　　　 ∩ノ ⊃　 ヽ
　(　 ＼　／ ＿ノ　|　 |
　 ＼　 "　 ／　　｜　|
　　　＼ ／￣￣￣ ／
　　　　　￣￣￣￣

>>583
インターフェースが全部同じくせに、
クラスによって動かない機能とたまに動作するっぽい機能と
ほかのクラスに比べて動作がヤバイ機能とあんまり多すぎてむかつく。

>>585
そーなんだ。swing居ったら気をつけよう。

>>578
初歩的かつスレ違いだが、VS.net ってVB6のソースコード食べる？


しばらくマから離れていてまた開発方面に異動になるもんで聞きたい。

さすがVBユーザーは向上心が高いなぁ

>>587
俺がswingのリストビューでキー入力取得できなくて悩んでるときに
自称javaエキスパート（ﾜﾛｽｗ）クンが俺を馬鹿にしてきた。
「そんな作業にいつまでかかってるんですか？ｗ」
とか、抜かしやがる。俺もちょっとイライラしてたのでその日の進捗で

「リストビュー（カラム付きのよくわかんねぇのｗ）でキー入力が取得できません。
○○さんがやり方を知っているようなのでまかせてしまってもよろしいでしょうか？
私は■■（優先事項）の仕事を進めたいです。」

っていって丸投げしてやったら１週間もかけてなんの情報もつかめずじまい
（俺も調べたけどそれっぽい情報が１つもない。できるように解説してるサイトもあるけど
作者にメール送ってみたら、動いてないことが発覚。結局、できてる奴がいなかった）
進捗のたびに「やっぱりできないでしょ？」って聞いてやったら「そんなはずない」とか
なんとかグチグチグチグチ何故か認めないで１ヶ月はこんなもんに費やしてたなｗ
どうやら彼はswingを糞だとどうしても認めたくないらしいｗ
（まあ、いいところはいいんだからそんなもんできるできないなんてどうでもいいと思うんだけどよｗ）

javaって結構、やってる人数いるはずなのになんの情報もねぇよな。
客に微妙なこと要求されるとことごとくできねぇ。
できたためしがねぇ。
だからプロジェクトのはじめであらかじめjavaで組むから微妙なことできません。
っていちいち宣言してる。そういう言語だよなjavaって。

異動先に居るのがVB6のソースだとわかっているので。

ぶっちゃけなくても、C#があるのにVB.NETは必要ないだろ？
おもいっきりかぶってるじゃん
VBAシリーズもんとして、VB6も.NET上でうごかせるようにしてほしかった

>>590
・・・してほしかった？？　うぎゃっ

>>588
　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　 　　　　　j
　彡､　　　|∪|　　 |　　　 　　　 Ｊ
/　　　　 ∩ノ ⊃　 ヽ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／

オブジェクト指向を学ぶならＶＢだね

Ｊａｖａなんかいらないから

>>588
　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　 　　　　　j
　彡､　　　|∪|　　 |　　　 　　　 Ｊ
/　　　　 ∩ノ ⊃　 ヽ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／

>>588
「自称javaエキスパート」が無能なのは分かったが、
それがjavaに拡張されるのは分からない。

>俺がswingのリストビューでキー入力取得
キーイベントを拾いたいってことだよね。

>リストビュー（カラム付きのよくわかんねぇのｗ）
どのクラスのことかな？

>>588 藻前、友達いるかぁ？　俺もいねぇけどｗｗ
よかったねぇ。釣る相手がいて。

>>595
この表現でわからない人なんてどうせ使ったこと無い人なんだから説明したって無駄でしょ。
聞いてどうするの。知りたきゃ自分で調べたらどうかね。

なんで涙ぐんでんだよ >>597

日経ソフトウェアでもVB大プッシュされてたね
さすが最強言語

＞されてたね

その通り、過去形。


ttp://software.nikkeibp.co.jp/software/backno/2007/0701indexc.html

特集１：フリー言語で真のプログラミングを学ぶ
総論　複数のプログラミング言語を学ぶ意義
Part1　オープンソース/C言語に学ぶ「ソースコードの読み方」
Part2　Rubyに学ぶ「Ruby on Railsの正体」
Part3　JavaScriptに学ぶ「言語の拡張性」
Part4　Eiffelに学ぶ「正しいオブジェクト指向」

特集２：みんなのTurbo DelphiではじめるWindowsプログラミング

第2回　私はコレで、VB 6を卒業しました
ttp://www.atmarkit.co.jp/fdotnet/vblab/opensemi_02/opensemi_02_01.html

アップグレード・ウィザードはやはり使えない？！

>>601 やっぱり？ｗ

>>601
「作り直した方が早いですね」
って結論になっててﾜﾛｽｗ

(T_T)

>>599
やっぱり？

>>600 に戻る

世の中のプログラム言語すべてがVB6互換になればいいのに

>>605
つうか、いまさら？ｗ

普通の神経の持ち主なら、MSのああいうツールは一切期待しないだろ？

>>600 Turbo Delphi？ｗ

>>426
>しかし優秀な技術者が、中小に行くわけがない
>中小にいるのは、技術者じゃなくてオタクでしかない
>オタクはとにかく新しいものや設定が大好きだから、彼らが勧めるものが
>生産性を上げる可能性は低い

禿しく同意！

中小にOOマンセーのやたら横文字使うバカって見苦しいｗ
そんなに技術論語りたいなら、最初から大手池ってのｗｗ
語ってる割には、無理やりデザパタ使って、読みにくいったらありゃしない

OOは、生産性じゃなくて、保守性を上げるためにやるもの
業務クラスで、変なOOしてるバカとかマジ死んで欲しい

結局OOが製造になんか貢献してくれたかというと、そうでもなかったんだよな
もちろん、フレームワークとか、抽象化しやすい部分に限っては適用できるけどね

ぶっちゃけVB6でもよかったんじゃないの？

>>610
VB6は生産性が低かったし、
バカを弾くフィルタにならなかったじゃないか。

>バカを弾くフィルタ
確かにこの一点のみ.NETは評価できるな
それ以外は、MSの商売以外の何ものでもないが

俺的には、次に低学歴OOマンセーをフィルタして欲しい
それと、@ITとかの提灯記事ライターとか

生産性が最も高いVBさえあれば済むね

VB6はランタイムのスタティックリンクができたら
最強すぎて無敵すぎだったのになー

一つのフォルダに入れれば良いじゃん。

だめだよ。先にロードされたの使っちゃうもん

それはスタティックリンクしても同じことだろｗ

maji?

スタティックリンクになんか利点あるか？

DLLでも無いのに共有されるのか？どうなの？信じられないんだが

DLL　HELL

スタティックリンク = EXEに入っているライブラリを使う
DLL = EXEと同じフォルダのライブラリを使う。

単にファイルが一つなのか分裂しているかの違いだけ。

いや、DLLは既にロードされてたらそっちを使っちゃう。
必ず同じフォルダのを使うとは限らないよ

> いや、DLLは既にロードされてたらそっちを使っちゃう。
パスが違うのなら、使いません。いったいどこの情報だよｗ

日経ソフトウェア

Windowsの話だよね？
だったら仕様としては
同一フォルダ→システムフォルダの順で検索する、と決まってるよ。

でもメモリ上に乗ってる場合はそれを使うって書いてあったよ

信じる者は救われる。

カレントのDLLを使うと思ったら既にロードされてる
DLLを使ってしまって挙動がおかしくなることが
あるから気をつけようって書いてあったよ。

ああ思い出した。Windows 3.1の時代はそれで苦しめられたなぁ。

システムドライブのルート、Windowsフォルダ、System32とかの順は、
Windowsのバージョンによって違うんじゃなかったっけ？
しかもNT系は、レジストリで検索順を変えられたはず。

概要設計と詳細設計とコーディングが並行しているプロジェクトに途中参加したとき、
ローカルにあるACCESSのファイルを操作するのにrdoを使うルールになっていた。
絶対にダメだと説明したのだけれど、「もう決まっているから」という理由で却下された。

rdoは裏でデフォルトのdaoを呼び出していて、PCの起動時点ではインストールされている内の最新版のdaoだった。
ところが、使用しているレポートツールがdaoを呼び出しており、ひとつ前の版にしか対応していなかった。
この呼び出しで、デフォルトのdaoがひとつ古い版に切り替わって．．．

ttp://pc.2ch.net/prog/kako/1012/10128/1012818811.html

極論じゃなくて事実なんだがほっといて、
ドライバもダメなんだね。
RDOは死亡か？
DAOの解決策のクリーンな環境って何だよ。解決策になってない。
解決策はVBやめること。

[VB] "Jet VBA ファイル...の初期化に失敗しました" エラーが起きる問題
http://www.microsoft.com/JAPAN/support/kb/articles/JP192/9/34.asp
アプリケーション開発と配布イメージの作成は、クリーンな Visual Basic 5.0 環境で行う。(「詳細情報」欄を参照してください)
もしくは
Visual Basic 6.0 にバージョン アップし、ディストリビューション ウィザードを用いて配布イメージを作成する。

＞VB 6業務アプリはいつまで使えるの？Vistaでは？
＞ttp://www.atmarkit.co.jp/fdotnet/vblab/opensemi_01/opensemi_01_03.html
＞私の個人的な意見としては、.NETに踏み込むとき、既存アプリケーションの移行から入ってしまうと、
＞挫折する確率が高いのではないかと感じています。

旧ＶＢは全部作り直し、

＞VistaはMSDEをサポートせず――影響するシステム数は膨大に？
＞http://www.itmedia.co.jp/enterprise/articles/0608/30/news010.html

またまた全部作り直し。

＞第2回　私はコレで、VB 6を卒業しました
＞ttp://www.atmarkit.co.jp/fdotnet/vblab/opensemi_02/opensemi_02_01.html
＞アップグレード・ウィザードはやはり使えない？！

終焉。

M$の馬鹿！！

MS最高！！　VBは永遠！！

MSのMSによるMSのためのバージョンアップにより、もまえらおよそ38歳で引退

OOいいよとかVB6ダメとか、「うれしそうに」言ってる時点でDQN

同じものなら楽して作りたいだろ？
おこちゃまは、自分で自分の首を絞めてるよなｗ

「同じもの」意味するところが問題だな。
本当に同じものは作れないからね。

>>629
Windows 3.1時代の話だな。

VB6.0は捨てろ。
.NETで全て書き直せ。

>>640
振り込めサギに何度も引っかかるヤツがいる訳だよな

＞Windows 3.1時代の話だな。

これ、はっきり言って違うおね。
VB2（Win3.1）はDLLコールだけでマシだったのが、
ブビが壊れだしたのはActiveXベース（Win9X）になったその後。

またいつもの知ったかDel厨くんが、恥をかきに現れたな。w
彼は真性Mだな。w

最強VBに勝てないからってなｗ

age

s

タイトルとは裏腹に、なにげに良スレage

君たちPGはやはり優秀だ。

俺は事務屋でカス同然だがBV2005EEでそこそこの物が作れれば神扱いの職場だ。

いままでExcelVBAはまあまあやっていたけど、VBはいままで使ったことないステートメントやらいっぱいでけっこうきつい。


どこか勉強するための良いサイトってないですか？

1冊本買った方が面倒ないぞ