none
Microsoft Visual Basicの名前空間の混在について RRS feed

  • 質問

  • VB6.0からVB2005へアップグレードした為、各コントロールオブジェクト、クラスが

    .NET FrameWorkの固有の名前空間とMicrosoft Visual Basicの名前空間のものが混在しています。

     

     まだ、ユーザー配布用のセットアップは先が遠くエラーあるのでコンパイルできないのでアドバイスをお願いします。

     

    このアップグレードのコンパイル結果はアップグレード前のVB6.0のものと比べて大きいものになるような気がしますが、

    どうなんでしょうか?

     

    Microsoft Visual Basicの名前空間のクラスを使わないほうが良いのでしょうか?

     

    たとえば旧クラスのTabstripコントロールに新ListView、DataGridView、旧MsFlexGridとかが混在、VB.Day、Left$、Mid$

    IintegerタイプのColor、データベース作成にODBC、旧レコードセットの取得用ADO、ドットネットのDataAdaptorのOLEDBの混在が当ソフトにあります。

     単純に考えてこの状態で良いとは言えないのですが・・・・・・・・。

     

    簡単なアドバイスをお願い致します。

     

     

     

     

    2008年11月15日 10:41

回答

  • じゃんぬねっとさん、ありがとうございます。

     

    System.Data.Odbc 名前空間の存在は分かりませんでした。

     DataSetに関しては参考書を見ながら数ルーチン組んだのですが、レコード数が多い場合は

    分割表示しなければならないようで、これからこの辺のテクニックを勉強しようと思います。

     また、ActiveXControlの移行についてはおっしゃるとおり工程の余裕が出来た状態でやって行こうと思います。

     

    今回の、これらの件に関しては大変勉強になりました。

     

    今後ともよろしくお願いいたします。

     

     

    2008年11月18日 12:17

すべての返信

  •  ネット移行者 さんからの引用

    VB6.0からVB2005へアップグレードした為、各コントロールオブジェクト、クラスが

    .NET FrameWorkの固有の名前空間とMicrosoft Visual Basicの名前空間のものが混在しています。

     

    完全修飾名がダブるわけではないので、名前空間が混在していること自体は別に問題はありません。
    (後の質問を見るに Visual Basic 互換のものが存在していることを問題視しているようですね)

     

    このアップグレードのコンパイル結果はアップグレード前のVB6.0のものと比べて大きいものになるような気がしますが、

    どうなんでしょうか?

     

    通常は VB6 より大きくなります。

     

    Microsoft Visual Basicの名前空間のクラスを使わないほうが良いのでしょうか?

     

    使っているものによりけりですね。

    VB6 からのアップグレード用の互換のためだけに用意されている系統のものはお世辞にも褒められたものではないです。

     

    # この書き方だと誤解されそうなので書いておきますが、「アップグレード用の互換 ≠ VB プログラマのための互換」 です。

    # 後者は結局 .NET Framework の機能を使っているものも多いので自由でいいと思っています。私は使いませんが。

     

    単純に考えてこの状態で良いとは言えないのですが・・・・・・・・。

     

    互換用コントロールと ADO 関連については .NET に移行した方が良いですね。

    2008年11月16日 7:44
  • じゃんぬねっとさん、ご回答ありがとうございます。

     

    「ADO 関連については .NET に移行した方が良いですね。」と言うことで、

    次のことについて教えてください。

    1. データベース作成にODBCを使うことはNGですか?

    .NETでは作成コマンドが見当たらなく、SQLを使っているみたいですが・・・。

    2.   次のコードはADOですから、例えば.NETのDataReader辺りに変更すべきなんでしょうね。

            cn = New ADODB.Connection
            cn.ConnectionString = AdoConectString & DB_Select("dataX_TABLE")
            cn.Open()
            rst = New ADODB.Recordset
            rst.CursorType = ADODB.CursorTypeEnum.adOpenForwardOnly
            rst.let_ActiveConnection(cn)

        ・・・・・・・・・・・・・・・

    3.  もう一つ、ActiveXControlについてお願いします。

    VB6.0で作成したActiveXControlをFormに貼り付けて使用しています。

    このコントロールのSize指定、Color指定でInteger型を使用しています。

    一応問題なく動いていますがVB6.0のActiveXControlは.NETに作り変えたほうが良いのでしょうか?

     

     

     

     

     

    2008年11月17日 12:51
  •  ネット移行者 さんからの引用
    1. データベース作成にODBCを使うことはNGですか?
    .NETでは作成コマンドが見当たらなく、SQLを使っているみたいですが・・・。

     

    "データベース作成..." 接続に用いるデータ プロバイダのことでしょうか? 一応 .NET にも System.Data.Odbc 名前空間以下に専用の Connection や Command が存在します。 NG ということもないと思いますが、普通は対象の DBMS 用に最適化されたデータ プロバイダを使います。

     

    2. 次のコードはADOですから、例えば.NETのDataReader辺りに変更すべきなんでしょうね。

     

    はい。 ADODB は COM ですので参照の管理をする必要がありいろいろ面倒な問題が発生します。 ADODB と ADO.NET はコーディング手順はほとんど同じですので簡単に移行できると思います。

     

    複数レコードの SELECT については DataReader ではなく DataAdapter + DataTable (DataSet) のセットをお勧めします。 こちらも DataReader とは少し勝手は違うものの Fill メソッドまでの手順さえわかれば簡単に移行できると思います。

     

    3. もう一つ、ActiveXControlについてお願いします。
    VB6.0で作成したActiveXControlをFormに貼り付けて使用しています。
    このコントロールのSize指定、Color指定でInteger型を使用しています。
    一応問題なく動いていますがVB6.0のActiveXControlは.NETに作り変えたほうが良いのでしょうか?

     

    はい。 作り変えることを推奨します。 FlexGrid は DataGridView で作り変えが可能ですが、こちらは最初だけ少し手こずるかもしれません。

     

    後工程で問題が発生しにくくなるように時間が許す限り移行することをお勧めしますが、大人の都合もあると思いますので、工数の見積もりをした上で上長に相談されることをお勧めします。

    2008年11月18日 2:04
  • じゃんぬねっとさん、ありがとうございます。

     

    System.Data.Odbc 名前空間の存在は分かりませんでした。

     DataSetに関しては参考書を見ながら数ルーチン組んだのですが、レコード数が多い場合は

    分割表示しなければならないようで、これからこの辺のテクニックを勉強しようと思います。

     また、ActiveXControlの移行についてはおっしゃるとおり工程の余裕が出来た状態でやって行こうと思います。

     

    今回の、これらの件に関しては大変勉強になりました。

     

    今後ともよろしくお願いいたします。

     

     

    2008年11月18日 12:17