Confuse behaviour calling a DLL

I´m using a DLL with several readonly tables inside.

Sometimes trying to open one of these tables I got the error "File MyDBF
does not exist".

On displaying memory and status to files I couldn´t find changes at all. No
database is open. These are free tables.

What other environment changes can I compare?

Thanks.

Alejandro Fernandez

Stefan
Fri Jul 11 11:42:46 CDT 2008


"Alejandro Fernandez" <afernan@emcali.net.co> wrote in message
news:uzGIV%23v4IHA.4448@TK2MSFTNGP05.phx.gbl...
> I´m using a DLL with several readonly tables inside.
>
> Sometimes trying to open one of these tables I got the error "File MyDBF does not
> exist".
>
> On displaying memory and status to files I couldn´t find changes at all. No database is
> open. These are free tables.

Just a guess: I have seen that error with included files when an EXE
file is shared by many users in a network (as opposed to being
installed locally on each client PC).


hth
-Stefan

Alejandro
Fri Jul 11 06:03:36 CDT 2008

Thanks Stefan. But this is only a desktop application.

Don´t run in network.

Alejandro Fernandez

Christof
Sun Jul 13 01:21:34 CDT 2008

Hi Alejandro,

> What other environment changes can I compare?

The current directory and Windows search path. In some cases VFP searches
for the files externally. It might under rare circumstance happen that an
API function reports that the file physically exists, but trying to open it
fails with an error. In this case, VFP would skip the embedded file and
attempt to open the external one reporting the error you see.

A more likely case, though, is that your code is changing the project scope.
Embedded files are only visible to code running inside the same project
scope or application context. External code doesn't belong to the same
project scope as doesn't EXECSCRIPT(). Hence, if you are using EXECSCRIPT()
to open the table, that would cause the same error.

Finally, you might actually see a different error. For instance, some field
validation error might call the error handler which in turn tries to create
a file and fails. In this case you could end up with the error message from
the error handler, but the name from the previous error. The same is true
the other way round. You have a file not found error on a different file,
but the error handler uses some code that accesses the table but changes the
global error parameter. TYPE() is such a function that impacts the error
value.

If you can somehow make this error reproducible, turn on FILEMON or PROCMON
to see what file access is actually performed. This should give you a
definite answer on what is happening.

--
Christof

Alejandro
Sun Jul 13 17:30:45 CDT 2008

Hi Christof !

Thank you for your memorable patience. I find your analysis very focused.
Indeed I´m using as you said EXECSCRIPT(cmd), but for a few times it works
fine.
The procedure that call the DLL to open a table is:


PROCEDURE use3 && Open tables in MDATA.DLL
PARAMETERS mtable,mindex
#DEFINE EXPRZ0 "DO "
#DEFINE EXPRZ "tablasmain3.prg IN "+xpath+[mdata.]+[dll]
#DEFINE EXPRZ2 " with "+"mtable, mindex"
commd=EXPRZ0+EXPRZ+EXPRZ2 && These strings create an expression as you
said.
EXECSCRIPT(commd)
ENDPROC
**********************************************************
But, I realized this application don´t work in spite of receiving the
fullpath of the dbf. The statement:

DO tablasmain3.prg IN "mdata"+".dll" with
"f:\proyectos\wtriv48\dbf3c\nuevos\autor", "0"

displays the error "File <mydbf> does not exist". The main program of
this DLL is:

**********************************************************
PROCEDURE TABLASMAIN3

PARAMETERS mtabla,mindex <--- takes dbf name and index
PUBLIC xpath
LOCAL lcSys16, lcProgram
lcSys16 = SYS(16)
lcProgram = SUBSTR(lcSys16, AT(":", lcSys16) - 1)

CD LEFT(lcProgram, RAT("\", lcProgram))
IF RIGHT(lcProgram, 3) = "FXP"
CD ..
ENDIF

xpath=FULLPATH(CURDIR())

SET DEFA TO (xpath)
SET PATH TO dbf, class, dbf3c\nuevos, prg
SET CLASSLIB TO xtablas addi
&& Now I create an instance of my opener class with the same 2 parameters
otabla=CREATEOBJECT("basetablas",mtabla,mindex)
ENDPROC
**********************************************************

In the class Basetablas the code is:
**********************************************************
PROCEDURE Init
PARAMETERS mtabla ,mindex

IF NOT USED(mtabla)
USE (mtabla) IN 0 <----- Here comes always the error "File <mydbf>
does not exist". So I think this is not a different former error.
ENDIF

SELECT (mtabla)
IF mindex <>"0"
SET ORDER TO (mindex)
endif
**********************************************************

Thank you for your valuable opinion.
Alejandro

Christof
Tue Jul 15 00:37:23 CDT 2008

Hi Alejandro,

> otabla=CREATEOBJECT("basetablas",mtabla,mindex)

Is basetablas a class that is embedded into the DLL? Also the class name
must be unique to the DLL. If not you would see the error you are seeing for
two possible reasons:

If the class is stored in the main EXE and not in the DLL or is an external
file (VCX, FXP), the object is switching the project scope. Even if you
instantiate the class inside the DLL, the class would belong to the EXE and
only look for files embedded in the EXE.

If the class is embedded in the DLL, but the name is not unique, VFP would
use the cached class. This can be the one in the DLL, but it can be any
other, as well. This depends on what code has been executed first.

Hence: Class name must be unique and the class part of the DLL.

--
Christof

Alejandro
Mon Jul 14 23:36:26 CDT 2008

Yes Christof, this class is embedded into the DLL and has an unique name.

I´m begining to know a new tool with the features of PROCMON called
PROCESSMONITOR.

Indeed it´s a hard subject beyond my usual field of work in VFP.

Thank you,

Alejandro

Christof
Tue Jul 15 07:42:05 CDT 2008

Hi Alejandro,

> Yes Christof, this class is embedded into the DLL and has an unique name.

Strange... What happens if you don't use the class, rather but the code to
open the table into the main prg of the DLL?

> I´m begining to know a new tool with the features of PROCMON called
> PROCESSMONITOR.

Yes, Process Monitor is the full name, PROCMON the name of the EXE. I'm
referring to this tool:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

--
Christof