VB6 ClassにてEnum(列挙型)のうまい使い方

質問

へっぽこPGです。
今まで私の質問にご回答を頂いた方々、改めてお礼申し上げます。

最近VB6でActiveXDLLにて、DLLを作り始めました。
Classについて勉強を始めたばかりで、
実現できそうな機能と実現できない力量のギャップに苦労しています。

さて、いろいろと便利なDLLを作ってやるぞ！と意気込み、
ExeからDLLを参照してプロパティに値を設定する時に、
インテリセンスが出るようにしたく、ClassにEnum(列挙型)を使うやり方を見つけましたが・・・・。

その先困ってます。

VB6でデバッグをしているわけですが、
Class(Dll)とExeは別プロジェクトで生成しており、
Dllはバイナリ変換、デバッグはExeを実行するように設定済です。
これでActiveXDLLプロジェクトで「開始」をすると、Exeを実行してくれます。

Exeのプロジェクトから、
「開始」・ステップ実行して確認しましたが、
正常に動作しているようです。(記述した文がそれぞれ機能しているという意味で)

ActiveXDLLプロジェクトから、
「開始」後、「停止」をして、Dllを上書きしようとすると、
「書込みできません。"～DllのPath～"」とMsgboxのBouttonのでいうvbMsgBoxStyle=vbCriticalの形式で、
Msgboxが表示されてしまいます。
どうやらExeがDLLを離していないのでしょうか？
もちろん列挙型を設定していないDLLの場合ですと、上書きは可能です。
(他にも上書きできないパターンを見つけましたが、話が脱線するので割愛します。もしご存知でしたら、併せて教えて頂くと幸いです。)

困っている点としては、
1 デバッグする上で、Dll(書出)⇔Exe(開始)を繰り返したく、都度プロジェクトを閉じて、開いてDLL書出しするのは、非効率。
(DLLを書き出して、インターフェースを変えてしまえば、Exeはリコンパイルが必要なので、あんまり意味ないかも・・・とも)

2 読み取り専用プロパティを作って、Initializeで初期値を設定してしまう方法を考えたが、非常にかっこ悪いし、運用が大変。

3 1を我慢したとしても、作成したDLLはCOM+に登録して、WebサーバでASPから使用するつもりなので、DLLを離してくれないと、無駄なプロセス動き続けてしまう(?)→未テスト

です。

いろいろとツッコミどころがあるかもしれませんが、
忌憚なくご意見下さい。

---Class-(test_Class)----
'列挙宣言
Public Enum Chiiki
Hokkaidou = 0
Aomori = 1
Akita = 2
End Enum

'プロパティ値を格納しておく変数
dim aaa as integer

'プロパティでEnum宣言した型を引数に指定します、
Public Property Get Shusshin() As Chiiki
Shusshin = aaa
End Property
Public Property Let WindowState(ByVal NewValue As Chiki)
aaa = NewValue
End Property
---Class-End--------------------

---Exe-----------------
'Classは参照設定にて
'参照設定にしている理由としては、インテリセンスでロパティ・メソッド等を利用したいから。開発側の怠慢？

Sub a
'Class宣言
Dim a_class as test_Class
Set a_class = New test_Class

'プロパティ設定 ↓ = と打つと、Classの列挙で設定した値がプルダウン
a_class.WindowState = Aomori

'プロパティ値表示(処理自体に意味無し)
'「1」 と表示される
Msgbox a_class.WindowState

'Class開放
Set a_class = nothing

End sub
---Exe-End----

回答No.1

redfox63 · ベストアンサー

VB6が DLLを離していないためですよ
VB6のインスタンスが2つある状態なのですよね
VB6-ActiveXとVB6-TextExeが起動している状態で
VB6-TestEXEが参照設定のため DLLをつかみっぱなしになっています
DLLが開発途上なら プロジェクトグループで開発したほうが良いと思います
DLLプロジェクトとテスト用EXEプロジェクトを1つのグループにして開発orデバッグします

どちらでも良いですからプロジェクトを開いて
ファイル > プロジェクトの追加 で他方のプロジェクトを追加します
テスト用EXEプロジェクトに参照設定をして開発します

DLL側の修正はそのままコードウィンドウを開いて編集します
DLLファイルの作成し直しは
プロジェクトウィンドウで DLLプロジェクトをアクティブにして
ファイルメニューからDLL作成をします

テストEXEのデバッグには プロジェクトウィンドウでEXEプロジェクトをアクティブにしてからデバッグ実行などをします

お礼

早々のご回答ありがとうございます。

ご助言の通りグループプロジェクトを作成しましたが、
DllプロジェクトにてExeを起動させる設定をしないと、
何も実行されません。
(Exeプロジェクトウィンドウをアクティブにして「開始」しても、
どうやらDLLプロジェクトの設定しか有効でないようで)

設定をしてしまうと、
DllプロジェクトでExe起動するパターンと同現象が発生します。

私自身、
グループプロジェクトは、
Dllプロジェクト単体でEXE起動設定をした場合と、
同じ状態にしかもっていけなかったので、
グループプロジェクトを使っていなかったという経緯があります。

＞もちろん列挙型を設定していないDLLの場合ですと、上書きは可能です。
の通り、列挙型をPublic設定しているからが要因かと思っていましたが・・・。

申し訳御座いませんが、
グループプロジェクトについて、もう少しご説明頂けないでしょうか？

回答No.3

Asarima

列挙型だけを記述したDLLを別に作成するのがおすすめです。
ExeからもDLLからも、そのDLLを参照設定しておけば、
どちらからも同じ列挙型が使えますし、インテリセンスも効きます。
以前、そのような構成の開発を経験したことがあるので。

お礼

ご回答ありがとうございます。
なるほど、スマートな方法ですね。

DLLとExeの関係(クラス構造?)がなるべく煩雑にならないように・・・
と考えましたが、甘い考えかもしれませんね(笑)

どこまで部品化するか・・・、考えればキリがなさそうです。

今の業務は、システムが幾つも散在していて、
無駄だらけです。

コーディング技術というよりも、
詳細・概要・・・その上の設計を学ぶべきところでしょうか。

余談ですが、
回答には回答日時がありますが、
お礼にはお礼日時がありませんね。

運用でカバーしましょう(笑)

2007/10/05 9:45:16

尚、ANO2のお礼は、上記数分前です。

回答No.2

redfox63

テストEXEプロジェクトをアクティブにすると プロジェクトウィンドウのテストEXEプロジェクトが太字になるかと思いますがなりませんか？

そのプロジェクトを選択して右クリック　> スタートアップとして設定で出来ると思います
ここが太字になっていないと DLL側のデバッグ設定が使われると思います

お礼

何度もご回答本当にありがとうございます。
Exeプロジェクトが「開始」していることを確認しました。

が、やはりDLLは上書きできませんでした。
このパターン(列挙型使用)だと、
Exeが参照設定でDLLを離さない理由がわかりません。

・・・というか、たった今解決してしまいました。
(?暫定対応?代替案?)

DLLのコンパイルを、
バイナリ互換でなく、プロジェクト互換でやると、
問題なく上書きできました。

(以下、こちらのサイトで「プロジェクト互換」で検索した結果の一部)
　VB　DLLプロジェクトについて　
　http://oshiete.nikkeibp.co.jp/qa1648268.html
　インターフェイスＩＤを変えずにVBのＤＬＬをリコンパイルするには？
　http://oshiete.nikkeibp.co.jp/qa13566.html

プロジェクト変換
インターフェースIDが変更されるから、
参照設定しているVBのAPは、リコンパイルが必要。
　→運用を考えると、好ましくない。
　　(APが増えれば、作業は甚大だし、管理が煩雑になる恐れ有・・・。
　　しかしながら、DLLとAPの関係を把握していないわけはないので、
　　作業面だけが問題か？)

バイナリ互換
インターフェースIDが変更されないから、
参照設定しているVBのAPは、リコンパイルが不要。
但し、(下記「VB　DLLプロジェクトについて」抜粋)
　1.実装済みメソッドの戻り値の型を変更できない。
　2.引数の型及び個数を変更できない。
　3.メソッドを追加した場合、COMクライアントの再コンパイルが必要。　　(CreateObjectは別)
であるので、結局はリコンパイルが付き纏う。
　(COMクライアントが、
　COMを使っているAPのりコンパイルを指すのか、
　コンポーネントサービス＞COM+アプリケーション＞コンポーネント　の　再設定を指すのか、不明。)

上記と、今回の現象と、開発のし易さを考慮すると、
　DLL・・・開発中はプロジェクト互換で、リリース時にはバイナリ互換で。
　DLL使用するAP等・・・開発中は参照設定で、リリース時にはCreateObjectで。
という結論に落ち着くでしょうか。

「理由は何だかわからないけど、こうすればうまくいく」
という危ない状態でしょうが、方向が間違ってなければ良しとする。
・・・悪い傾向です。