VB6.0を使用しています

質問

VB6.0を使用しています
VC6.0でdefファイルで宣言してDLLを作成し
VBのEXEよりDLLをCALLしています。
VBではDLLの関数をDeclareで宣言しています。
問題なのは
ちょっと前まで問題なく動いたDLLですが
新規にDLL関数を追加したら
EXEではちゃんと呼び出して処理を行なってくれておりますが
VBのデバッグ起動で呼び出すと、その新規のDLLの関数がありませんと
メッセージを通知して止まってしまいます、
EXEでは動くのにデバッグ起動ではだめなんでしょうか？？不思議です
もし、ご存知の方がいらっしゃいましたら教えてください。

回答No.4

nda23 · ベストアンサー

System32に無いので、やはりカレントを探しています。
EXEになっている方は同じフォルダ内にあるDLLを使って
いると思われますが、デバッグ中のカレントは規定では
VB自体が起動した所なので、探す場所が違っていると
考えられます。試しに、CurDirをメッセージボックスで
表示するコードを入れてみるとハッキリします。
そこで、DLLの関数を使用する前にカレントを自分の
プロジェクトのフォルダ（ここには最新DLLを置く）に
移動しておきます。これでDLLを探す場所を変更できます。

本当はDLLの定義をClassモジュールで定義し、ここを
通して間接的に呼び出す方が、より好ましいのです。
標準モジュールですと、DLLはプロセス空間にロードされる
ため、一度でも実行（ロード）されるとリフレッシュでき
ませんが、Classモジュールで定義すると、インスタンスを
作り直す（一度、Nothingをセットしてから再度、Newを行う）
ことで、DLLをリフレシュできます。特にWinSockのように、
障害で内部データが壊れると、リフレッシュしない限り復旧
しない作り（内部データを保持する）のDLLでは尚更です。

お礼

確かにVBがある場所(ProglamFilesのなかかな)に
DLLがある可能性たしかにがあります。
>CurDirをメッセージボックスで
>表示するコードを入れてみる
上記の対応で確認出来そうです。
実際の確認は客先に行かないと確認出来ないので
別途、行った際に確認します。
ありがとうございました　解決として処理します。

回答No.3

Hayashi_Trek

DLLのパスをFullPath指定していないためです。
EXEを直接起動した場合は、カレントフォルダはEXEの有るフォルダになります。
しかし、VBのデバッグ起動した場合は、カレントフォルダはVB6.0のインストールフォルダになります。
System32フォルダにDLLをコピーするか、
DLLのパスをAppPathを使ってFullPath指定にする必要が有ります。

回答No.2

tsukasa-12r

確か、標準の状態だとデバッグビルドのEXEとリリースビルドのEXEは別々のフォルダに作成されるんだったと思うのですが、デバッグビルドのEXEがあるフォルダに古いDLLが残っているということはないでしょうか？

新規の関数以外はデバッグ実行でも呼び出せるのでしたら、一度、デバッグ実行でも呼び出せる関数にメッセージボックスなどの処理を入れてみて、本当に新しいDLLを読み込んでいるのか確認してみてはどうでしょう。

回答No.1

nda23

DLLのパスが違うためじゃないですか？
Libの指定はどうしてますか？
絶対パス指定でない場合はSystem32を探し、
そこに無いとカレントを探したと思います。
実環境の方だけ新DLLを入れ、テスト環境は
以前のまま、というようなことは？

補足

>DLLのパスが違うためじゃないですか？
　パスは同じEXEの直下です
>実環境の方だけ新DLLを入れ、テスト環境は
>以前のまま、というようなことは？
　実環境もテスト環境も同じフォルダでEXEの直下
また、System32に同じ名前のDLLもしくはLibがあるかどうか確認しましたが
なかったです。
ん～　悩み中です・・・