【VB.NET】VS2005 選 ..
697:デフォルトの名無しさん
06/11/06 23:27:10
>>689
慣れれば結構違和感ないぞwwww
個人的にPerseが入ったのがウマス
698:デフォルトの名無しさん
06/11/07 02:15:10
単にメソッド定義を楽にってだけなら匿名メソッドは必須じゃないけど、
クロージャ的なことを考えると必要。
てかC#でやったことをVBに移植しようとしてぎゃおすw
699:デフォルトの名無しさん
06/11/07 07:03:19
J#
700:デフォルトの名無しさん
06/11/07 11:09:54
C厨がいっぱい沸き始めたな。
俺はどっちも使うが、VBのライブラリ参照してまでC#使うきは無い。
ほとんどのことはどっちでもできる。
視認性とか可読性は、好みと慣れの問題だろうし。
701:デフォルトの名無しさん
06/11/07 12:23:05
>>700
C#で「VBのライブラリ参照して」何をするの?
もっと効率の良いやり方あるんじゃないの?
つーか、あなた一人でよく頑張るね。
702:デフォルトの名無しさん
06/11/07 12:30:40
スレリンク(prog板:515番)
Vista RCで.NET2.0のソフト動かしたら、クラスライブラリの挙動の違いで
ボロボロだった…
そのまま実行できちゃうのに、同じクラス、同じメソッドで動作が異なるのはマズすぎ。
マジ終わったかもしれん…
703:デフォルトの名無しさん
06/11/07 13:26:00
つまり>>629ってことでいいだろ
704:デフォルトの名無しさん
06/11/07 13:37:34
>>701
VBのライブラリは便利で優れているわけだが、
お前の言うC#でもっと効率がよくなる方法を提示してくれよ。
結局お前も>>570
705:デフォルトの名無しさん
06/11/07 13:45:50
VBには、Myがある。これ以上便利なものはないだろう。
コーディングも極めて単純で簡単になる。当然ソースも見やすくなる。
C#にもあったらなーとつくづく思う。
706:デフォルトの名無しさん
06/11/07 14:32:26
難しい事考えずに、開発効率や短いコードでプログラムを組める言語がいいのでは?
まったく同じパフォーマンスのプログラムを組むのに、100行掛かる言語と50行で済む
言語なら、50行で済む言語が優れていると思う。
707:デフォルトの名無しさん
06/11/07 15:14:04
ならDelphiのポトペタ最強。
708:デフォルトの名無しさん
06/11/07 15:40:38
MyをC#に導入して困ることってあるんだろうか?
どうせコンパイル時に元のクラスに置き換えてくれるんだろうし。
709:デフォルトの名無しさん
06/11/07 15:52:20
半端な釣り餌だな。
710:デフォルトの名無しさん
06/11/07 15:59:38
スレリンク(prog板:515番)
Vista RCで.NET2.0のソフト動かしたら、クラスライブラリの挙動の違いで
ボロボロだった…
そのまま実行できちゃうのに、同じクラス、同じメソッドで動作が異なるのはマズすぎ。
マジ終わったかもしれん…
711:デフォルトの名無しさん
06/11/07 17:34:54
>>708
ヘジだったかな?
曰く要望自体がほとんどないそうな。ぶっちゃけいらな(ry
712:デフォルトの名無しさん
06/11/09 01:55:39
いやMy気持ち悪すぎ
713:デフォルトの名無しさん
06/11/09 02:57:24
>>712
VB厨に言ってもムダだけどな。
そもそも視点が違う。
714:デフォルトの名無しさん
06/11/09 23:59:47
Myって何?thisとかと違うの?
715:デフォルトの名無しさん
06/11/10 00:09:08
リフレクションみたいなもの?
“My”はクラスの海からVBプログラマを救う!? − @IT
URLリンク(www.atmarkit.co.jp)
716:デフォルトの名無しさん
06/11/14 16:59:44
Myの真価は、やはり、My.Settings だろう。
あらゆる言語の中でも、これほど便利なものはない。
もはやiniファイル等を用意して読み書きしたりレジストリをこねくり回す時代じゃないってことだろ?
C#にこれがないのは実に残念でならない。
717:デフォルトの名無しさん
06/11/14 17:10:34
>もはやiniファイル等を用意して読み書きしたりレジストリをこねくり回す時代じゃないってことだろ?
My.Settingsの情報はどこに保存されるわけ?
718:デフォルトの名無しさん
06/11/14 18:41:59
マイ爺さん
719:デフォルトの名無しさん
06/11/14 18:51:44
iniファイルとレジストリを抽象化したTRegistryIniFileなら、
Delphi16ビットの頃からあったよね。
720:デフォルトの名無しさん
06/11/14 20:26:35
>>719
.NETではレジストリは非推奨、iniよりもxmlです。
721:デフォルトの名無しさん
06/11/14 21:40:42
マイムマイムを一緒に踊ったあの娘は今頃・・・
722:デフォルトの名無しさん
06/11/16 01:52:16
>>716
とりあえず使ってみたけど、凄いな。確かに便利。
プロパティーのバインドで、好きな項目を選んであげるだけでよく、
コーディングの手間も技術も不要。
たとえば窓のサイズとか、チェックボックスの状態等、何でもできそう。
あとは、
バインドしたプロパティーは意識しなくても勝手に保持され、
変数同様代入してやれば勝手に読み書きもしてくれる。
で、どこに保持されてんの?
723:デフォルトの名無しさん
06/11/16 09:32:27
>で、どこに保持されてんの?
こういうの最悪。
対処できなくなる。
724:デフォルトの名無しさん
06/11/17 00:00:41
わけ分からんところに勝手に保存される
とでも思ってるのか?
725:デフォルトの名無しさん
06/11/17 15:33:58
使ったことないから知らんけど
普通にappname.exe.configに入ってるんじゃないの
726:デフォルトの名無しさん
06/11/20 04:02:55
My.Settingsは手軽だけど、設定ファイルの保存場所がちょっと…
My.Settingsを使うとフォルダ内で完結しないので移動ができない
727:デフォルトの名無しさん
06/11/20 08:44:31
>フォルダ内で完結しないので移動ができない
サイテー
728:デフォルトの名無しさん
06/11/20 09:28:20
あほいな
729:デフォルトの名無しさん
06/11/21 00:11:19
移動が出来ないってどういう意味だ?
730:デフォルトの名無しさん
06/11/21 01:30:05
馬鹿ばっかりだな。
My.Settingsもまともに使えない奴がまともなプログラミングできるとは到底思えん。
731:デフォルトの名無しさん
06/11/21 02:08:08
レジストリ使わないぜとか自慢するのはいいがマルチユーザ考慮しない低能
732:デフォルトの名無しさん
06/11/21 03:18:29
>>731
最近は、実行ファイルがあるフォルダ以下にユーザ名でフォルダ作って、
その中に設定ファイル作るのが多いと思うけど。
My.Settingsも、そうなればいいのに。
733:デフォルトの名無しさん
06/11/21 08:18:33
>>732
それって、VistaのUACにひっかかりそうだが。
734:デフォルトの名無しさん
06/11/21 09:57:09
unixの/home/hogeに習ってプロファイル内に置くべきXMLで
735:デフォルトの名無しさん
06/11/21 10:46:34
>Winにini→別の場所にini→レジストリ→My.Settings
なんて、OSに振り回されるくらいなら独自(オプソでもおk)クラスのんが良いんじゃね?
標準にしとくと長生きするなら意味あるけど、短命になるなら最悪。
736:デフォルトの名無しさん
06/11/21 11:49:33
こんな感じでクラス作ったほうがいろいろ便利だと思う。
アプリケーションの設定を保存する
URLリンク(dobon.net)
737:デフォルトの名無しさん
06/11/21 20:03:49
楽だからDataTableに値突っ込んでWriteXmlメソッドで保存している。
738:デフォルトの名無しさん
06/11/21 22:40:33
>>736-737
要はXMLなりレジストリなりに必要なオブジェクトをシリアライズするだけだよな...。
つか、>>716のSettingsとかいうやつも同じことをしてるんだと思うけどな。
>あらゆる言語の中でも、これほど便利なものはない。
>もはやiniファイル等を用意して読み書きしたりレジストリをこねくり回す時代じゃないってことだろ?
>C#にこれがないのは実に残念でならない。
を皮切りに、場違いな議論が延々と続くあたり、VB厨との乖離を感じざるを得ない。
739:デフォルトの名無しさん
06/11/21 23:30:16
VBのMy.Settingsってゆーの、使ったことないんだけど…。
C#でアプリケーション設定ファイルを作成したときに
IDEが自動で生成してくれるSettingsクラスと何が違うの?
740:デフォルトの名無しさん
06/11/21 23:38:51
My.Settingsって普通のsettingsと機能どう違うの?
741:デフォルトの名無しさん
06/11/21 23:39:36
かぶったw
742:デフォルトの名無しさん
06/11/21 23:46:00
>>739-740
両方とも特別なクラスってわけじゃないでしょ。
中でしてることは>>736のサイトで書いてるようなんと一緒。
743:デフォルトの名無しさん
06/11/22 00:26:31
いや、
>Myの真価は、やはり、My.Settings だろう。
>あらゆる言語の中でも、これほど便利なものはない。
>もはやiniファイル等を用意して読み書きしたりレジストリをこねくり回す時代じゃないってことだろ?
>C#にこれがないのは実に残念でならない。
って言ってるから、C#で使えるsettingsとは全く違う機能なの?って思って。
744:デフォルトの名無しさん
06/11/22 00:27:06
今>>715のリンク先見てみたけど、C#のSettingsクラスと全く変わんねぇじゃん。
Resourceの方もC#と全く同じ。
>>716の
>C#にこれがないのは実に残念でならない。
ってのはどっからでてきたんだか。
つーか、初期の.NETの頃から、INIファイルじゃなくXMLを使いましょうって言われてるし。
745:デフォルトの名無しさん
06/11/22 00:29:04
俺は専らVBばっかり使うけどMyなんて負け組臭いものは使わないな。
746:デフォルトの名無しさん
06/11/22 00:39:12
>>716
>あらゆる言語の中でも、これほど便利なものはない。
こういう腐れVB厨が将来のコボラと化すんだろうな…。
747:デフォルトの名無しさん
06/11/22 00:46:09
ファイル読むよりレジストリ読んだ方が速いよね?
テンボラリに使っちゃまずいかな
748:デフォルトの名無しさん
06/11/22 00:48:20
また妙なこと言い出すバカが湧いてきたよww
749:デフォルトの名無しさん
06/11/22 00:54:18
DVDのイメージ丸まるダンプしてREG_BINARYで突っ込むのもモマエの自由
750:デフォルトの名無しさん
06/11/22 01:08:27
d
Aチームseason3ディスク3を突っ込んでみるわ
751:デフォルトの名無しさん
06/11/22 01:36:20
毎度思うんだが、@ITのVB専用のコンテンツでVB厨の扱い方が、
なんつーか、ちょっと頭のイカれた子供に「○○ちゃんは間違ってないわよ、周りの子達がおかしいのよ」って
擁護している母親みたいに見えてきてそして僕らがはたから見てて痛々しいというかやるせないというかなんとも言えないこの思いを抱いてしまうのは
きっとVB厨はもう手遅れなんだと心の奥底ではみんなうすうす感づいてはいるんだ、いるんだけれども
それでも救いの手を差し伸べたいと思ってしまう僕たちはきっと偽善者なのでしょうか、性的な意味で。
752:デフォルトの名無しさん
06/11/22 02:02:54
アホの子でもそこそこ使える言語を目指すと言うのは、方向性としては間違っていないと思うが。
753:デフォルトの名無しさん
06/11/22 02:09:45
折角だからC#を選んで、その勢いでXbox360でゲームを出すべし。
754:デフォルトの名無しさん
06/11/22 02:17:40
>>753
恐ろしいことにVB.NETでも可能。
755:デフォルトの名無しさん
06/11/22 02:19:42
>>747
普通は保存形式をテキストにするかバイナリにするかで悩むと思うんだけど...?
756:デフォルトの名無しさん
06/11/22 02:24:05
ファイルに書き出すことをなぜシリアライズって言うの?
757:756
06/11/22 02:28:15
自分でぐぐった。
Wikipedia項目リンク
758:デフォルトの名無しさん
06/11/22 02:28:29
>>756
どの.NETでも読めるようにするため。
C/C++だとエンディアンの関係とかでそのまま読めない事がある
759:デフォルトの名無しさん
06/11/22 02:58:58
>>756
「ファイルに書き出すこと」をシリアライズって言うんじゃないでそ。
オブジェクトの状態を、復元可能な形式で書き出せればいいのだから。
通信やらマーシャリング扱うときもシリアル化したオブジェクトを使うよね。要はXMLだけど。
これは別に.NETに限った話ではないよ。
760:デフォルトの名無しさん
06/11/22 03:10:33
>>754
それ本当?
761:デフォルトの名無しさん
06/11/22 09:06:09
>>760
適当にググったけどソースみつからんかったorz
確かに聞いたんだけどな。
まぁmanaged DirectXは使えるわけだから原理的には可能でしょ。
762:デフォルトの名無しさん
06/11/22 10:53:45
>>754
Content Pipelineはどうしてる?
763:デフォルトの名無しさん
06/11/22 10:55:14
beta1はVB.NETでもCLIでも動くんだけどね
Xboxのゲームを作ってみないか?
スレリンク(gamedev板)
764:デフォルトの名無しさん
06/11/22 13:39:48
>>749
XP起動するのに30分くらいかかるようになりましたw
765:デフォルトの名無しさん
06/11/22 18:59:02
VB.netとC#を合体させたスーパー言語を作ればいいんじゃね。
766:デフォルトの名無しさん
06/11/22 23:02:10
URLリンク(www.vector.co.jp)
作者の方へ
VisualBasicの学習者たちのためにソース公開してください
(公式サイトが消滅しているようなので、ここにカキコします)
((((;゚Д゚)
すばらしいソフトなので、ぜひともお願いします
767:デフォルトの名無しさん
06/11/22 23:21:34
>>744
.Net の 1.1 には My.Setting に相当するものが無かった。
2.0 にはある。ので C# でも普通に使える。
C# にこれが無い、とか言ってる人は2年くらい寝ててさっき起きた人。
768:デフォルトの名無しさん
06/11/23 00:05:12
1.1だとVBでもないじゃん…
769:デフォルトの名無しさん
06/11/23 04:45:42
>>744
バカなVB厨が、
My名前空間に備わっている機能=C#にはない機能
って勘違いした結果だろうな。
770:デフォルトの名無しさん
06/11/23 13:22:01
Microsoftは、未だにVB6を使い続けるユーザー達のために、
Formの既定インスタンス機能や、IDEの挙動をVB6に似せるなど、
移行支援の為の対策をVB2005にたくさん盛り込んだわけだ。
特に、Formの既定インスタンス機能は、改悪と言って過言ではないと
自他共に認めるであろう。
MSは、そこまでしてVB6ユーザーを「救おう」としている。
さて、ここでVB6ユーザーであるスレ主が、
VB2005を使ってみて、居ても立ってもいられずに立ててしまったこのスレッドを見てみよう。
スレリンク(tech板)
> [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ユーザー達を見放してはならない義務があるのだ。
771:デフォルトの名無しさん
06/11/23 14:44:25
>>770
何を言うか、そもそもVB.net自体、VB6しか使えないヘボプログラマを一掃するための
刺客だったのだ。VB.netとVB6なら、まだVB.netとC#,Javaのほうが近い。
やる気のあるやつがVB.netに乗り換え、主流がVB.netになればヘボプログラマはついていけずに一掃されるはずだった。
ところが、VB6ユーザーは数が減るどころか大部分は移行せず、VB6を使うことに固執し、
未だに大きな勢力を持っているので、MSはこれを取り込む必要があるのだ。
772:デフォルトの名無しさん
06/11/23 14:48:06
マルチコピペは無視無視
773:デフォルトの名無しさん
06/11/23 20:05:44
つか、ポトペタ環境最悪
774:デフォルトの名無しさん
06/11/24 01:23:10
VBのMyってのは要するに
あちこちの名前空間に散らばってるクラスたちの中から
高頻度で使いそうなものを寄せ集めてきただけだよね?
775:デフォルトの名無しさん
06/11/24 02:58:25
だけではないが、まそれにちかい
776:デフォルトの名無しさん
06/11/25 16:06:27
vbってndoc使えるの?
使えないならウンコ
777:デフォルトの名無しさん
06/11/25 18:12:44
それはいずれにせよNDoc側が対応してるかどうかの問題であってVBの問題ではないな
778:デフォルトの名無しさん
06/11/25 20:38:21
VB2005になってドキュメントコメントが使えるようになったが、
NDocの方が死滅…w
779:デフォルトの名無しさん
06/11/25 20:49:33
こんな記事が出てきた
URLリンク(www.isisaka.com)
780:デフォルトの名無しさん
06/11/25 23:10:49
ジェネリックでアウトー
781:デフォルトの名無しさん
06/11/25 23:56:39
C++のテンプレートまでは真似れたが、アルゴリズムは真似れなかったC#・・・
782:デフォルトの名無しさん
06/11/26 01:02:23
C#で.net framework2.0に対応したフリーのドキュメント出力ツールは結局
SandCastleのみ?
URLリンク(www.microsoft.com)
783:デフォルトの名無しさん
06/11/26 03:21:41
何その嫌な名前
784:デフォルトの名無しさん
06/11/26 11:27:30
普通にdoxygenが使えないか?
785:デフォルトの名無しさん
06/11/26 23:15:04
私見ですが、
VB厨は、コボラーより始末が悪い気がする。
1>>
もし、私がスレ主ならC#を選択します。
786:デフォルトの名無しさん
06/11/28 12:14:29
>>785
プログラミング言語を選ぶのに「VB厨は、コボラーより始末が悪い気がする。」
なんて理由でC#を選ぶおまえはVB厨よりも始末が悪い気がする。
787:デフォルトの名無しさん
06/11/28 12:22:45
>>786
もともとの話題はどちらを雇ってプログラムを作らすかだったからな。
788:786
06/11/28 19:24:37
>>787
たしかに>>785の意見はまっとうなレスでした。
ごめんね>>785
789:デフォルトの名無しさん
06/12/06 04:46:53
で、様々な理由からVBの方が優れてるでOK?
790:デフォルトの名無しさん
06/12/06 08:27:44
なぜ
791:デフォルトの名無しさん
06/12/07 00:57:35
why not
792:デフォルトの名無しさん
06/12/17 15:22:13
>>789
むしろ、その逆
793:デフォルトの名無しさん
06/12/17 16:39:23
VB6+VBA、VC++をそのまま残して、.NETはC#だけに絞っても良かったのにね
MSはこれからもスクリプト言語や関数型言語と.NETで動かすの増やすのだろうけど
まあ今から新規で始めるとしたらVB.NET選ぶ価値がないでしょう
今後はどう進化するかにもよるだろうけど(そろそろ個性出してもいい頃だと思う
ただ今さらJAVAには勝てないだろうし、VB6の分野をJAVAで扱えるようになればそれで終わりな気も・・・
もしVB6ユーザーの受け皿が必要とすれば、VB.NETはそう言う進化もありだとは思う
794:デフォルトの名無しさん
06/12/17 22:54:50
VB6→Javaでクライアント
ならまだあきらめてVB6→VB2005
に行くやつのがおおいんでないか?
795:デフォルトの名無しさん
06/12/17 23:01:39
javaでクライアントって誰が使ってんの?
796:デフォルトの名無しさん
06/12/18 10:20:32
>java
携帯電話のアプリとか…
>>794
でも、VB6→VB2005に行ってVB.NETを新たに学べる人ならC#も充分学習可能という罠
ただBorlandのPascalと同じでMSもBASICをラインナップから外したくないの鴨。
797:デフォルトの名無しさん
06/12/18 14:08:53
というか「やっぱり言語、シンタックス重要」とヘジも言っているように
VBに慣れている奴はVBのシンタックスがいいだろうよ。
CLR的に見ても少なくとも思想が違う2つぐらいは面倒みないと言語中立な
設計がわからんし。あと鉄パイソンからLCGが産まれたように何の言語から
有用な機能が産まれるか正直誰にも分からんし。VB9は下手したら
C#3.0よりも先進的っぽいですよ。
798:デフォルトの名無しさん
06/12/18 19:25:41
前から疑問なんだけど、C#にはVBのStaticなローカル変数にあたる機能がないわけだが、
これって何か深い理由があるのんだろうか?
どう考えてもあった方が便利な機能だと思うんだけど。
たとえばDispose実装するとき、VBなら既に一度呼ばれてるかどうかのフラグを
Dispose内に閉じ込められるが、C#だとこんなどうでもいい変数をわざわざ
フィールドにしなきゃならん。
799:デフォルトの名無しさん
06/12/18 22:40:28
コンストラクタがNewで統一されていて、関数の戻り値用変数がデフォルトで用意されているVB.netがわかりやすい希ガス。
それだけかよ('A')
800:デフォルトの名無しさん
06/12/18 23:09:04
Disposeのフラグにstatic使っちゃまじいだろw
801:デフォルトの名無しさん
06/12/18 23:14:41
staticの意味合いが違うんだろ。
話はかみ合わない。
言語論争は20年前から見てるもう秋田。
好きなほうを使え。
802:デフォルトの名無しさん
06/12/18 23:18:47
c#使ったほうが優越感はあるな。
でもVBも業務で使われているみたいだし。
803:デフォルトの名無しさん
06/12/18 23:19:45
勝手な思い込みで書くなよ。
話はちゃんと噛み合ってる。
804:デフォルトの名無しさん
06/12/18 23:36:53
>>803
いや全然かみ合ってないと思うよ。
まあマジメに読んでくれると思わないが一応。。
URLリンク(msdn2.microsoft.com)(VS.80).aspx
>>801
好き嫌いの話なんか一切してないと思いますが。
仮にしてるとしても、あんたが書き込んでるこのスレのタイトル知ってる?w
繰り返すけど俺が関心があるのはC#にVBのStatic相当のしくみが用意されてないことに
必然性があるのかないのかだよ。
単なる個人的な好みをぶつけ合うガキ臭い宗教論争に興味はないよ。
805:デフォルトの名無しさん
06/12/18 23:37:24
>VBのStaticなローカル変数
って、Cの関数内staticみたいなやつなの?
806:デフォルトの名無しさん
06/12/18 23:42:47
>>804
合ってるじゃん。
そっちこそ何か勘違いしてね?
807:デフォルトの名無しさん
06/12/18 23:45:27
>>806
まあ噛み合ってると思うなら噛み合ってるということでいいや。
では、>>800の理由は何ですか?
808:デフォルトの名無しさん
06/12/18 23:46:56
>>798
なんでC#にはメソッドローカルのstatic変数がないんだろ。
Disposeしたかのフラグとか便利なのに。
>>800
Disposeのフラグにstatic使っちゃまずいだろ。
(staticは寿命は静的変数なので、インスタンスごとにもてないから)
>>801
staticの意味合いが違うんだろ。
話はかみ合わない。
異なる意味じゃなくて同じ意味で話してるからかみ合ってないなんてことはない。
最初から>>804のリンクの内容の意味で話してる。
809:デフォルトの名無しさん
06/12/18 23:48:03
寿命は静的変数って微妙な書き方だな。
要するにインスタンス変数じゃないってことね。
810:デフォルトの名無しさん
06/12/18 23:50:39
>>808-809
ああ、やっぱりこの程度の人間かよw
いいから黙ってもう一度>>804のリンク先の文章読んでみ
811:デフォルトの名無しさん
06/12/18 23:54:15
ぎゃはははは
ほんとだよお
gyははは
すまんかったorz
まじかよマジで知らんかったよ。
きちんと読んでなかった。
いやすまんかった
ひとつ賢くなったよ。
さんくすorz
812:デフォルトの名無しさん
06/12/18 23:55:24
これVB6のクラスのころからそうだっけ?
813:デフォルトの名無しさん
06/12/19 00:00:12
>>812
そのはずだよ。
814:デフォルトの名無しさん
06/12/19 00:22:19
>>811
まぁC系の人が >>811 みたいに混乱するからってことで。
それにさして効果的な機能でもない気がするしなぁ
815:デフォルトの名無しさん
06/12/19 02:00:03
ていうかDisposeて。勘違い除いても使わん
ObjectDisposedExceptionなげるのを忘れてやしないか?
どっちにしろ変更に弱そう。それならはじめからインスタンスメンバ
にしとけよっていうか。
816:デフォルトの名無しさん
06/12/19 03:30:33
まあ現実にはそこまできちんと作らんこともある。
817:デフォルトの名無しさん
06/12/20 11:52:01
VB6 から VB2005 に移行して勉強した人が、
以前からの会社の都合でどうしても VB.NET 2003 とかで開発する
必要がある、というような場合、言語上で新たに覚えないといけないような点
はありますでしょうか?
Version としてはバックすることになりますが、VB2005 の方が楽になっている
ので VB.NET 2003 とかに戻ると オブジェクト指向プログラミング的に
厳密にやらないといけない部分が出てくると思うのですが、その辺で
やっかいな部分から列挙するとどんな感じになるでしょう、、
このあたりを心配していましたが、すみませんが、よろしければこの件で
ご指導くださればありがたく、よろしくお願いします
818:デフォルトの名無しさん
06/12/20 11:53:40
それとも、VB.NET 2003 で開発していた案件はすべて
VB2005 に移行していくと考えてよいでしょうか
この辺もよろしければ教えてくださると助かります
819:デフォルトの名無しさん
06/12/20 11:56:49
こちらのスレだとスレ違いのようなので別のところに移動します、
すみませんでした。
820:デフォルトの名無しさん
06/12/20 12:00:00
回答:
スレリンク(tech板:342番)
VS2003で作ったプロジェクトがVS2005でコンパイルできないのには萎えた。
しかも、もう.Net3.0とか言ってるし・・。
DirectXと同様に、エンジニアを振り回すのが大好きですね、MSは。
821:デフォルトの名無しさん
06/12/20 12:06:31
書き方が悪いからだろ。
822:デフォルトの名無しさん
06/12/20 14:56:16
.NETってカスじゃんwwwwww
URLリンク(forums.microsoft.com)
>.NETの売り文句である、「自動的に適切なランタイムを選択しバージョンを気にせず使える」という話を信じて安心していたのですが、
>このような自体になってしまい、書き換えるにしても時間が無い絶望的な状況だったりします。
823:デフォルトの名無しさん
06/12/20 15:14:02
>>820
そうですか、やはりソース上の互換性はないのですか
当方は817-819ですが、たとえば、
VB.NET 2003 までは
フォームの Load の段階ではもしかしてインスタンスの生成を書かなければ
ならなかったのが、2005 では必要なくなり、むしろ書くとエラーとなるようでした
これは 2005 のものを 2003 以前の環境にそのまま読み込んでも
実行できないということなのではないかと思いました
それともこれは回避できるのであって、こうではないのでしょうか?
824:デフォルトの名無しさん
06/12/20 15:45:44
>823
> フォームの Load の段階ではもしかしてインスタンスの生成を書かなければ
> ならなかったのが、2005 では必要なくなり、むしろ書くとエラーとなるようでした
書いてもエラーにゃならんと思うが。
825:デフォルトの名無しさん
06/12/20 16:24:10
2003のソースをそのまま追加してやればコンパイルは出来る。
Partial Classの仕組みを理解してなくて、2005で追加したフォームに、
2003のソースの一部だけをコピペしてるのだろう。
IDEに互換が乏しいというべきだろうな。
826:デフォルトの名無しさん
06/12/20 16:46:18
>>824
そうですか、当方823ですが、
ただ2005で、*.vb のファイルのコードエディタにそれを書くとエラーになったかと
記憶しています
>>825
>Partial Classの仕組み
それは、もしかして要するに同じコードが重複するってことですよね
ということは、「2003のソースをそのまま追加」 するということは
その2003での *.vbファイル そのものを 「追加」 するということですね
ということは、やはり、2005 では、 *.vb ファイルのコードエディタには
インスタンスの生成部分を書いては 「ならない」 ということを意味
しますよね
827:デフォルトの名無しさん
06/12/20 16:49:39
続きですが、ということは、結局、
2005 で開発したコードは、 2003 では実行できない
=下位互換性はない
ということですよね
ということはやっぱり、2005 で勉強してできるようになっても
2003 で開発し続けている会社では、2003 での構成方法も
学びなおさないと開発できない、ということを意味しますよね
828:デフォルトの名無しさん
06/12/20 16:53:16
訂正ですが、
>>826
>*.vbファイル そのものを 「追加」 する
これは、正確には
>*.vbファイル に関係するすべてのファイルを 「追加」 する
が正しいですか
829:デフォルトの名無しさん
06/12/20 17:02:18
>>827
何をそこまでてんぱってるのかわからんが、そんなに構えなくてもいいんじゃね?
そりゃ違うところはあるだろうし、2005から追加した機能もあるから
そのあたりの違いは勉強しないといけないけど、基本はほとんど変わらないはず。
普通にやればいいと思うよ。
ちなみに、「Partial Class」は「同じコードが重複する」わけじゃなくて、
1つのクラスを2つのファイルに分割して書けるってだけだよ。
830:デフォルトの名無しさん
06/12/20 17:37:41
>2005 で開発したコードは、 2003 では実行できない
>=下位互換性はない
当たり前じゃん
831:デフォルトの名無しさん
06/12/20 17:41:56
普通に移行ウィザードが発動してコンパイルできるんじゃ。
832:デフォルトの名無しさん
06/12/20 17:43:11
おそらくその移行に失敗した模様だな。
僕のはしょぼいせいかカンペキだ…
833:デフォルトの名無しさん
06/12/20 18:15:43
>820
2.0から3.0への移行なら100%互換だよ
というか追加があっただけで何も変わってない
はず
834:デフォルトの名無しさん
06/12/20 22:14:28
はじめ間違えて 【VB.NET】VS2005 選ぶならどっち?【C♯】スレ
で先にお聞きし、スレ違いと思い直してこちらに来て改めてお聞きしていました。
>>829
なるほど、確かにそうですよね>「Partial Class」
で、別ファイルにあるインスタンス生成部を通常の動作コードに書くと
「重複」になるものと思ったのでした
>>830
やはり
>>831>>832
2003 から 2005 に移行するのには 「移行ウイザード」というのが
あるのでしたか、わかりました
>>833
その辺はまだ知らないのでした
一応、やはり 2005 で勉強してできるようになっても、会社によっては
「2003 で開発し続けていく」 会社もあるでしょうから、そうなるとそこに
行って仕事するとなると、すぐには使えず、 2003用の学習は必要
にやはりなりそうですね・・・
835:デフォルトの名無しさん
06/12/20 22:20:29
>はじめ間違えて 【VB.NET】VS2005 選ぶならどっち?【C♯】スレ
>で先にお聞きし、スレ違いと思い直してこちらに来て改めてお聞きしていました。
あ、間違えた
これがこちらでした・・・大変スマソです(汗
836:デフォルトの名無しさん
06/12/20 23:48:25
そのくらい対応できないようなら首吊った方がいい
837:たかとし
06/12/21 00:17:45
VS2005やったらとてもVS2003は出来ない。
作業が大変楽
838:デフォルトの名無しさん
06/12/26 13:18:16
>>813
違うよ。
VB6にはsharedも初期値代入も無い。
839:デフォルトの名無しさん
06/12/26 13:20:42
Windows Vistaへの対応状況
URLリンク(blogs.msdn.com)
○ VB 6.0 - Supported
× VB.NET 2002 - Not supported
× VB.NET 2003 - Not supported
× VB 2005 - Not supported
△ VB 2005 SP1 - Supported (ただしUAC関連の問題あり)
VBワロスwwwwwwwwwwwwwwwww
.NET Framework 2.0 廃止予定の API 一覧
URLリンク(www.microsoft.com)
( <●><●>) ドトネト1.0〜2.0廃止なのは分かってます
(U )つ
u u
>廃止予定一覧 : アセンブリ単位
>廃止予定一覧 : 名前空間単位
840:デフォルトの名無しさん
07/01/11 21:57:40
>>833
>>682 がちょいと気になる
841:デフォルトの名無しさん
07/01/12 10:21:41
大丈夫だって。
>互換性 ".net" の検索結果 約 1,720,000 件中 1 - 10 件目 (0.15 秒)
互換性について相当考慮してくれてることが分かる。
最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4947日前に更新/199 KB
担当:undef