WAIT NOWAIT 3

[sashaDG]

There is a function A. When I call twice
arg = x
DO A(arg)
arg = y
DO A(arg)

if error X occurs in A, own error handler intercepts:

wait 'wrong '+arg WINDOW NOWAIT TIMEOUT 5​

. Shows the last call (wrong y)

Same result, shows 'BB':

WAIT 'WW' WINDOW NOWAIT TIMEOUT 3​

WAIT 'BB' WINDOW NOWAIT TIMEOUT 3​

How to display all results, THANKS!

 

[Chris Miller]

I don't know if I should concentrate on wait windows or error handling.

Well, wait windows don't "stack up", you only ever have one, the nowait tells VFP to continue with code, and if that doesn't produce another wait window the timeout time tells VFP when to remove the wait window. But if there is another wait window, it replaces the one that didn't yet time out.

You don't have a clause that forces a new window to be created, so you would need a replacement that should be based on a non-modal form, which means it works like the nowait part of a wait window. Well, the only missing thing then is a timeout. That's doable with a timer.

And now I go back to the initial question I ask myself, should I really just focus on that aspect alone. It's very questionable to react to an error just with a wait window and continue to execute. Even only letting slip through some specific errors like wrong argument types, simply rejecting to compute and return a function result, you end up with a state at the caller of which you never know what it causes.

In general, continuing in an error state can cause tables to become corrupt, in the end cause fatal C5 errors hard to debug or anything. You can do controlled error handling with TRY CATCH. And error suppression and continuing with the code can work, if whatever would happen in the normal non-error case was optional anyway.

Still, usually you halt on an error. The default system error handler is a messagebox that's stopping everything and does not time out.

So, I don't see a reason to actually help you with your goal of getting multiple wait windows happening. You have a basic recipe of a non-modal form able to act as a wait window, you could use an editbox within it to display one, or if the form already runs, display multiple messages, one in each line, and automatically extend. So you'd hold on to only one extending wait window. I still don't see the use case for error handling. This could work as status messages, log display, or such things, but shouldn't be used for error handling.

Chriss

 

[Mike Lewis]

Sasha, if you do two consecutive WAIT ... NOWAIT commands, the second one will always override the first. In other words, if you do this:

[tt]WAIT 'WW' WINDOW NOWAIT TIMEOUT 3
WAIT 'BB' WINDOW NOWAIT TIMEOUT 3[/tt]

then you will never see "WW". It will be displayed, but only for a tiny fraction of a second, but it will be immediately replaced by the "BB". Adding a TIMEOUT clause makes no difference.

In this case, the obvious solution is not to use WAIT in your error handler. Either use a message box, or write the error details to a file.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Well, and the other reason to not post wait-window replacement code is, that I think you thought there's just a non-documented way to simply make wait window always create a new own window, but there isn't. The task to create a non-modal form isn't hard. Let me just point out the modality of a form is given by the WindowType property. Besides that, top-level forms (see ShowWindow) will not act modal, even if you set their WindowType to modal.

Chriss

 

[sashaDG]

Chris and Mike thanks for the quick and big explanation!!
The situation is this:

I COPY TO X.dbf files(new ) and if they are already open I get error 1102, but since I copied the same files (old, not update X.dbf) without error, the application takes them(old X.dbf)

I want to warn the user that the files are taken old

 

[Mike Lewis]

I'm not sure I understand that. According the Help, the causes for error 1102 are:

- Not enough disk space

- No permission for target directory

- Invalid file name.

Which of those applies in this case?

It seems that you are saying that you have two copies of the file X.DBF - an "old" and an "updated" copy. Is that right? Can you clarify that.

In general, if you are worried about a new file overwriting an existing file, you would use FILE() to test for presence of the existing file.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[sashaDG]

In general, if you are worried about a new file overwriting an existing file, you would use FILE() to test for presence of the existing file.

I'm worried that it won't overwrite​

 

[Chris Miller]

Seems to me ou want to copy files, then don't USE tables and COPY TO a target file name, that has always the purpose to create a new file. You copy a cursor to a file, creating the file in that process.

To copy files, there is the COPY FILE command, and that works with any files. If you want to overwrite old files of same name, then SET SAFETY OFF, that way COPY FILE will overwrite. COPY TO still won't, it will always fail if a file name already exists.

The only advantage COPY TO would have is creating a new file and not copying all deleted records out to the new file. It also creates new CDXes, if you include the WITH CDX clause. While that is a bonus of COPY TO, it takes longer to create a DBF from a workarea than to make the simple binary copy of a file.

If you want to stick to using COPY TO, then erase files you want to overwrite, that would also work. Mike gave you the hint to check with FILE, if it exists you can ERASE (filename) and then COPY TO.

If that's your problem I don't know why you even asked about WAIT WINDOW at all. Because you only ever saw a problem with one file? Well, that would also have been better, if you'd do error handling like it's done usually, by logging errors, at least, if not stopping and reporting them by a messagebox. You'd realize this happens to every file already present in the target directory.

Chriss

 

[sashaDG]

Seems to me ou want to copy files, then don't USE tables and COPY TO a target file name, that has always the purpose to create a new file. You copy a cursor to a file, creating the file in that process.

I copy two files, then create cursors and concatenate them.

I have set safety off

If you want to stick to using COPY TO, then erase files you want to overwrite, that would also work. Mike gave you the hint to check with FILE, if it exists you can ERASE (filename) and then COPY TO.

I don't need to check if the file exists.
I need verification and processing in the PROCESS of copying the file. When opening a source, I get an error 1102 if the source is already open.

I have never worked with TRY CATCH, apparently the time has come, hope this helps.

 

[Chris Miller]

Error 1102 message literally says "cannot create file".

Chriss

 

[sashaDG]

I don't fully understand TRY CATCH, but i think i got what i wanted

FUNCTION CopyFile(placeFrom, placeTo)
	PRIVATE successCopied
	successCopied = .T.
	TRY	
	COPY FILE (placeFrom) TO (placeTo)
	successCopied = .T.
	CATCH
	successCopied = .F.
	ENDTRY
	IF 	successCopied = .F.
		NameLoginForm.label3.caption = NameLoginForm.label3.caption + SUBSTR(placeFrom, RAT('\',placeFrom)+1)
	ENDIF
ENDFUNC

 

[Mike Lewis]

Sasha, you are on the right track, but you the following is a bit better:

lnError = 0
TRY
  COPY FILE (placeFrom) TO (placeTo) 
CATCH TO oError
  lnError = oError.ErrorNo
ENDTRY

IF lnError = 0
  * copy succeeded
ELSE
  IF lnError = 1102
    * copy failed; cannot create file
  ELSE
    * copy failed for some other reason
  ENDIF
ENFIF

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[sashaDG]

Mike, my appreciate for advice