いつもお世話になっております。
VB.NETで今現在いろいろやっているのですが、
以下のようなスクリプト(エラーチェックや例外処理は割愛)で
Option Explicit On
Option Strict
Public Module FileOpen
Public Function intFileOpen(ByVal strFileNm As String) As Integer
Dim intFno As Integer
intFno = FreeFile()
MicroSoft.VisualBasic.FileSystem.FileOpen(intFno, strFileNm, OpenMode.Input)
intFileOpen = intFno
End Function
Public Sub nFileClose(ByVal intFno As Integer)
MicroSoft.VisualBasic.FileSystem.FileClose(intFno)
End Sub
End Module
1: dll化して、プロジェクトの参照設定で取り込んで使用
2: プロジェクトのモジュールの追加で上のロジックを使用
とした場合で、intFileOpenを呼びだして使用した時、
1はFileCloseする場合にnFileCloseを呼び出してFileCloseしないと
FileCloseされないのはなぜなのでしょうか。
環境は、
Visual Studio 2003、WinXP Pro SP1
です。
ぼーっと考えた限りでは、
・"ファイル番号とファイルを関連付けている情報"
を持っているのは、
"Dll側にしかおいていない"
から、
・1に関しては、
"Dll側でしかファイル番号に関連付けられたファイルを閉じることが出来ない"
…かな?
識者プリーズ(TT
>ガッ様
回答ありがとうございます。
なぜdll側でしか情報を持てないのでしょうか。
そのへんを詳しく教えていただけませんか。
私は.NETをほとんど触ったことがないので、
メチャクチャな想像をしている場合があります(ぇ
> なぜdll側でしか情報を持てないのでしょうか。
dll側でしか情報を持ってないだけで、
dllの外側でも、Microsoft.VisualBasic名前空間 が利用されていれば、
その外側でも、「別物の」 ファイル番号を保持していると思われます。
※外側(=今回はDLL)で"Open"したものは、必ず外側で"Close"する。
それが普通だと思うのですが…
System.IO.FileStream のオブジェクト参照を渡せばいいのかも…
返信遅れまして、申し訳ありません。
無理矢理解決させました。
強いていうならば、Openはいろいろテキスト、バイナリ、或いは読込、書込などの設定が必要なので、共通関数にしてあまり変なことはさせたくなかったという思いがありました。
反面、CloseはFileNoさえ渡せば行えるのでそれなら各人がローカルでやっても問題ないかなと思っていました。
しかし、冷静に考えると問題がありますね…
ということで、共通関数側でCloseすることにしました。
ありがとうございました。
ツイート | ![]() |