Arrggh!! Mysterious behavior...

[Bern Ertl]

I've been porting functions from my main app into DLLs.

I recently moved the following function into a DLL. Everything
compiles without errors. When I run my app, I get Error 52 (Bad
File Name or #).

If I comment out the DLL code and compile the same function as
part of the main app, it works without errors.

I've added/removed the Fn from the DLL twice now to test. I've also
added error checking to ensure that the error 52 is not generated
before the call to this function.

Does FREEFILE not work in DLLs?

FUNCTION RndFileOpened& ALIAS "RndFileOpened&" ( Dev%, BYVAL File$, BYVAL RecordSize&, BYVAL Style%, BYVAL Module$) EXPORT


   LOCAL TryAgain%, ErrorMsg$


   Dev% = FREEFILE
   TryAgain% = %True
   WHILE TryAgain%
      SELECT CASE Style%
         CASE %FOR_I_SHAREIO  : OPEN File$ FOR RANDOM ACCESS READ LOCK SHARED AS #Dev% LEN = RecordSize&
         CASE %FOR_I_LOCKO    : OPEN File$ FOR RANDOM ACCESS READ LOCK WRITE AS #Dev% LEN = RecordSize&
         CASE %FOR_IO_LOCKO   : OPEN File$ FOR RANDOM LOCK WRITE AS #Dev% LEN = RecordSize&
         CASE %FOR_IO_SHAREIO : OPEN File$ FOR RANDOM LOCK SHARED AS #Dev% LEN = RecordSize&
         CASE %FOR_IO_LOCKIO  : OPEN File$ FOR RANDOM AS #Dev% LEN = RecordSize&
      END SELECT
      TryAgain%=ERRCLEAR
      IF TryAgain% THEN
         SELECT CASE TryAgain%
            CASE 70 : ErrorMsg$ = $Permission + File$ + $Denied + $Inuse
            CASE 71 : ErrorMsg$ = $DriveNotReady
            CASE 72 : ErrorMsg$ = $DiskMediaErr
            CASE ELSE
                MSGBOX $ErrNo + STR$(TryAgain%) + $whileopening + File$ + $ReportBack, _
                               %MB_ICONERROR OR %MB_APPLMODAL,$ATCVs + " - " + Module$
                EXIT FUNCTION
         END SELECT
         IF MSGBOX(ErrorMsg$,%MB_RETRYCANCEL OR %MB_ICONQUESTION OR %MB_APPLMODAL,$ATCVs + " - " + Module$) <> %IDRETRY THEN
            EXIT FUNCTION
         END IF
      END IF
   WEND
   FUNCTION = -1


END FUNCTION

------------------
Bernard Ertl

[Bern Ertl]

I need some serious help!

I checked with MSGBOXs and before the error 52,

FREEFILE is returning 2 (seems valid enough to me!)
File$ is the correct (complete) path & filename

What else could generate error 52????????



------------------
Bernard Ertl

[Lance Edmonds]

The problem is that file handle 2 (which is _free_ in the DLL) is already _in use_ in the EXE.

Basically, the FREEFILE result in the DLL is valid only within the scope of the DLL. If you use FREEFILE in the DLL, you should do all your file I/O in the DLL too.

This is because they are separate compiled modules, and the EXE and DLL have no natural ability to share system variables within their runtime libraries, such as file handle data, etc.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Eric Pearson]

(I see that Lance has already responded, while I composed this off-line, but I'll post it anyway.)

It's hard to tell from your example. I can't compile it because of all of the missing equates,
and even if I did, I wouldn't know which values to use when calling the function, in order to
see the error. If the following general advice doesn't help, I would recommend posting a
complete, compilable example program.

1) Make sure you use ERRCLEAR at the top of your function. If an ERR value was left over from
another (earlier) part of your program, it would fool your function into thinking that it had
failed.

2) I see that you are returning Dev% BYREF back to the calling program, and that won't work
unless your function is called from within the DLL itself. PowerBASIC file numbers (such as
those that come from FREEFILE) are only valid within a module, not within a program.
In other words, if your DLL function returns "2" that will have no meaning to your EXE. It
will not be able to use "2" to do anything. In fact the EXE can have its own OPEN... AS #2
and it will not confict with the OPEN... AS #2 in the DLL. Generally speaking, if you move
some file operations to a DLL, you must move all file operations to the DLL. You can't
have an OPEN in one module (a DLL) and have another file operation like GET$ in another module
(an EXE) and expect them to understand each others file numbers.

HTH.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited May 31, 2001).]

[Peter Manders]

Eric,

1) Make sure you use ERRCLEAR at the top of your function. If an ERR value was left over from
another (earlier) part of your program, it would fool your function into thinking that it had
failed.

I recently learned that ERR is local to a function, so in my opinion this isn't neccesary.

Peter.


------------------
[email protected]

[Lance Edmonds]

There is one further possible strategy: you could use FREEFILE in the DLL *and* OPEN the file there. Then obtain the O/S file handle (using FILEATTR), and return that LONG integer handle to the EXE. Finally, in the EXE, use OPEN HANDLE to manipulate the file. You'd also have to CLOSE the file in the EXE and in the DLL. See OPEN HANDLE in the doc's for more information.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Eric Pearson]

Peter --

> ERR is local to a function

Man, this just isn't my day. You're right of course. Old (PB/DOS) habits are sometimes hard to break.

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Bern Ertl]

Aye Caramba!

OK. I'll duplicate copies of the file i/o routines in every DLL
& main app then.

Please, oh please release a 32 bit compiler which doesn't force me
to break up my app into DLLs!



------------------
Bernard Ertl

[Bern Ertl]

Wow! Didn't see all those replies since Lance's original reply.

The problem was the attempted use of the file handle across the
DLL <-> EXE chasm. I wasn't aware that was illegal, but I
understand it now.

Lance, your suggestion about passing the file handle looks like
a good workaround. In my case, I only have two small routines
to duplicate in three modules, so I'm going to take the lazy route
for now.

Thanks all for your input!

------------------
Bernard Ertl

[This message has been edited by Bern Ertl (edited May 31, 2001).]