"Open" dialog box bypasses "on error" trap

[JWilsonny]

I have an app with a mix of forms and code. The forms have the "error event" defined and there is an "on error" statement in the main prg of the app that points to an error handler routine. The issue I have now is that on occassion, an OPEN dialog box displays (I assume that a statement is looking for a file that is not open) and halts the app waiting for user input. I belive that it is generated from a form, but my error handler is not tripped and no info is sent or recorded that would help find the problem.

Is there a way to force the an error instead of the OPEN dialog box? Can I disable the box in the compiled exe so that the error handler will always be tripped?

 

[rgbean]

Can you give the code that is causing the "Open" dialog? Strictly speaking, you should be checking to see if the file can be opened before actually opening it.

Rick

 

[JWilsonny]

That is really the problem - this happens intermittently and during some automated processes that are triggered with timers in a form. I am not sure what code is causing it to happen though. My error handler usually points to the line op code which makes it easy to find. However, it seems that instead of generating an error, the Open dialog box is displayed.

 

[DSummZZZ]

I don't think there's a way to shut that dialog off. I could be wrong, but I believe that's the default behavior from way back when...

What's happening is your app is trying to manipulate a table somehow, such as COPY TO ..., ZAP, PACK, APPEND FROM... or whatever, but there is no table open in the current work area.
You probably need to go through the code and find instances like that and make sure there is a work area selected or a table open.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[rgbean]

Good point Dave, it's not really an "error" in the cases you cited, but rather standard operating procedure, just as it's been since dBaseII!

Change my answer "... you should be checking to see if the file can be opened before actually opening it." to "Check to see if you have a properly selected workarea before issueing the command that invokes the OPEN dialog!".

Rick

 

[ramani]

JWilsonny

Are you in a network situation.. and one of the client unit doing the error ?. I have seen this sort of behaviour when the network gets disconnected and because of that, the alias() not available.. this leads to the file open dialog getting initiated.. When the system is forced out.. the server becomes available and everything goes OK. In these circumstances, the NIC is the troubler.

However, the technical reason for the file open dialog box is what DSummZZZ has pointed out - simply an alias is not available and VFP wants to open the table.

Another situation is that when an SQL is used to create a cursor, the resulting cursor may not exist in circumstances where there is no record to pick up. However, if that is not checked and the next command looks for an expected cursor, VFP starts a dialog (since no table is available). You can check for this also in your code.



____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[JWilsonny]

Yes - it does happen in a network situation while accessing a server drive. I think you are right - that the code is trying to access a file that is not able to be opened for some reason across the network. What's the best way to test for this first - [if file()]? Thanks - still wish there was a way to force it to the error handler. But - I could test first and then send it to the handler in the code.

 

[Mike Lewis]

JWilsonny,

The most common reason for this behaviour is that you are executing a command that operates on a table, but no table is open in the current work area.

For example, you would see an Open dialogue if you execute this code:

SELECT 0
BROWSE

It also happens with a SQL SELECT statement, where the SELECT is referencing a table which VFP cannot find.

My advice would be to forget about the error handling -- that's not really the issue. Instead, make sure that throughout your code, you know which work area is selected and what table, if any, is open in that work area. If you are not sure which area is selected, just select the required area anyway. If you are not sure if a given table is open, use IF NOT USED("...") / USE ... / ENDIF to open it.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[DSummZZZ]

If you are unable to open a file because it isn't there or available, your error handler should already be firing.
I think you need to check for inadvertant 'closes' of tables.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Olaf Doschke]

Hi JWilsonny,

checking if a file (table) can be found with FILE() can give you a hint, if you know where the table should be found, yes. FILE() will also find tables included in the exe, so you won't have a problem with these, too.

If your main concern is network fails, you could check IF FILE(DBC()) before a select. FILE(DBF(ALIAS())) would check if the current workarea's table is found on disk. But next to FILE() returning .T., the network could fail and you'd still get the open dialog. Okay, that's quite a seldom situation.

Still it won't work in every situation. Think about the example Mike Lewis gave:
SELECT 0
BROWSE

a) What File must be checked with FILE()?
b) Even if you know what you wanted to BROWSE (or select from etc.) if it's found with FILE() you'd still not know, if it's found by BROWSE (is it the selected workarea?) or an SQL Select (fine if the file is there, but if it isn't used and isn't part of the set database, it's not found by a SQL-SELECT).

example:
database1 contains table1 and table2,
database2 contains table3 and table4,
Both databases are in the same folder.

OPEN DATABASE ...database1
OPEN DATABASE ...database2
CLOSE TABLES ALL
SET DATABASE TO database1
CD (justpath(DBC()))
IF FILE("table3")
   SELECT * FROM table3 INTO CURSOR cursor3
ENDIF

This won't work, although FILE("table3") signals "Okay" for the SELECT.

On the other hand, if database1 and database 2 are in 2 different folders:

OPEN DATABASE ...database1
OPEN DATABASE ...database2
CLOSE TABLES ALL
SET DATABASE TO database2
USE table3 IN 0
SET DATABASE TO database1
CD (justpath(DBC()))
IF FILE("table3")
   SELECT * FROM table3 INTO CURSOR cursor3
ENDIF

This time the SQL would have worked, because table3 is open, but FILE() didn't find it, as database1 is in a different folder, not containing table3.

It may not be impossible but gives much overhead to determine if an SQL-Command or anything concerning a table will work based on the current set database, current datasession, used aliases and active workarea. At least there is no "one fits all" solution. Some commands need an (any) table in the active workarea (BROWSE, USE), others can open tables that aren't used so far (SQL).

As Mike Lewis said, you should use certain programming pragmas as:

IF !USED(cAlias)
USE cDatabase!cAlias IN 0
ENDIF

SELECT .. FROM cDatabase!cTable ...

Not using tables with different aliases if not needed (for example only with AGAIN).

Using the IN Clause:
REPLACE ... IN "Alias"
SKIP ... IN "Alias"
ZAP IN "Alias"
etc.

INDBC(), DBC(), DBF(), DBGetProp(), AUSED() and ASSERT may also be helpful, if you want to check things before certain commands, for example comparing DBF("Alias") with DBGetProp("Alias","TABLE","Path"), but if the network fails during a select you're as helpless as without a pre check. And this checks can also have errors which could make your app too cautious, not working in situations it would indeed work...

Bye, Olaf.