User-interface operation not allowed at this time. 1031

[grahamrhind]

I note that this error gives problems to others, but I'm getting it in different situations to others in other threads, so here goes:

I'm getting this error "User-interface operation not allowed at this time. 1031". This is in a VFP 6 DLL COM component being accessed by Visual Basic 6.

The error is appearing in lines starting:

USE path\database name

The program is using dbfs directly, not a cursor as in other threads. Only one database is open at a time. The program is not trying to send a dialogue or any other message to the user, nor open a report. The data is there in the right place. The database is closed after each call of the process in the dll. More worryingly, on my PC, with VFP installed, there are no errors. On the test PC without VFP, the error occurs.

Any bright ideas? Thanks in advance!

 

[rgbean]

Are you sure that the path (and table) exist on the other system? If it doesn't, VFP will try to pop up a "Locate" table dialog, which isn't allowed in a .DLL.

Rick

 

[alvechurchdata]

VFP will try to pop up a "Locate" table dialog, which isn't allowed in a .DLL.

Rick's suggestion is the most likely scenario; another possibility is that you've a sharing conflict between the DLL and another user when you install on the user's PC. You can't have any user interface in a DLL so you do have to be very careful about error handling.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[grahamrhind]

Yes, that was the first thing I checked - the files are there, in the correct place.

 

[grahamrhind]

There is only one user using both the DLL and the file. There are no UI commands anyway in the code that I can find (and, as mentioned, it's at USE that the problem occurs ...)

 

[alvechurchdata]

it's at USE that the problem occurs

It's got to be Rick's Locate dialog or some form of error message. Can you add a Try-Catch structure and write something out to a disk file?

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[grahamrhind]

Hi Geoff,

I'm bamboozled - what's a "Try-Catch" structure?

 

[Mike Lewis]

Graham,

Don't forget that even an error message counts as "user interface" for this purpose. Unless you are specifically trapping any errors, the DLL will try to display the error message on the screen.

Geoff's suggestion was to avoid that possibility by using a TRY/CATCH/ENDTRY construct. This will only work if you have VFP 8.0 or above.

All you have to do is to put TRY before the suspect line, and ENDTRY after it:

TRY
USE path\database name
ENDTRY

If the USE statement was indeed causing the error, the above code will prevent the error from being reported. Of course, the problem is still there, but at least this will tell you if it was indeed an error in the USE.

By the way, I see you are are using USE to open a database. I assume your "database name" is in fact a table. If not, you need OPEN DATABASE rather than USE (which would explain the original error).

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[grahamrhind]

Thanks Mike. I'm using VFP 6, which is why I can't use TRY (and didn't know of its existence - time for an upgrade, perhaps :-( ). And apologies, I'm still use DATABASE to mean TABLE from when they were the same things. I'm trying to open a table.

I'll try to create an error handler to see if I can catch the true error ....

 

[craigber]

Just to make sure...

do you have SET EXCLUSIVE OFF?

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[grahamrhind]

Hi Craig,

I don't have any SET commands in the program at all except SET TALK OFF because we're still testing the processes themselves and haven't built any "skin" on top of them in terms of catching unexpected user input etc. It's virtually impossible that anybody or anything else is using the tables (the test site doesn't have VFP and can't access VFP tables in any other way except through the DLL), but I'll check that out.

 

[Mike Lewis]

Graham,

Although you have VFP 6.0, you can still avoid the error message, although it's not quite as easy as with TRY/ENDTRY:

LOCAL lcOldError
lcOldError = ON("ERROR")
ON ERROR *
USE path\database name
ON ERROR &lcOldError

The effect of this is to temporarily switch off error processing (and switch it back on again). As before, the aim is merely to see if there was an error in the USE. Once you've solved that problem, remove the above code.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[grahamrhind]

Thanks Mike - I'll try that

 

[alvechurchdata]

I'm bamboozled - what's a "Try-Catch" structure?

Apologies for dropping it in without explanation and thanks to Mike et al for picking up the pieces. I've not been ignoring you, it's been night in this part of the world<g>.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[craigber]

No SET commands? Then that could be the problem. SET EXCLUSIVE ON is the default.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports&quot;

 

[Olaf Doschke]

Hi,

EXCLUSIVE ON might cause an error, but only if there would be a second user/process trying to access the same table.

My guess it's a table being used that is already open. Reusing the same alias would then raise an error "alias already in use" which would raise that error "User-interface operation not allowed at this time".

It might be much easier to find out what goes wrong, if you start by making your comserver an EXE, then that original error message could pop up as user interaction/interface then is allowed and you'd know what goes wrong. If the EXE is debugged you could recompile as DLL. Also take a look at the help chapter about Sys(2335) for turning on or off unattended server mode.

You may also use a very simple Log-Errorhandler:

on error strtofile("prg:"+program()+", error:"+transform(error())+"="+Message()+", caused by:"+Message(1)+Chr(13)+Chr(10),"d:\errors.log",file("d:\errors.log"))

Bye, Olaf.

 

[grahamrhind]

Hi Olaf,

In theory the table is only opened once and is closed again at the end of the loop. The failure occurs on the first run of the loop, so the database cannot be open from a previous loop. Furthermore, the program works prefectly in VFP, perfectly as an exe, and perfectly when called as a DLL from VFP, so debugging in any of those environments can't help. The problem is only occuring on a machine without VFP where the DLL is being accessed by Visual Basic. All procedures which run without opening files work. Only those with USE fail, and all on the USE line.

Very vexing ....

 

[craigber]

Have you verified that the proper VFP runtime is installed on the PC running the DLL?

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports&quot;

 

[grahamrhind]

Hi Craig,

The distribution was created with the TOOLS->WIZARDS->SETUP option in VFP, with the RUNTIME box checked. Again, other processes are working, the program just falls down when it finds USE. I can only assume that the runtime is correctly installed, otherwise the other VFP processes wouldn't run. You answer does return me, though, to my previous (still open) thread which was to try to ascertain a list of all the VFP files required on a machine to correctly run a VFP DLL (thread184-1092760). I am wondering if a file is missing, but as I can't find a list of files required, I can't check ....

Graham

 

[Mike Lewis]

Graham,

I doubt if a missing runtime file would cause this particular problem. If the runtime was missing, you wouldn't have got as far as you had.

I still think this is most likely either a pathing or an exclusive use issue. I think your best bet would be to follow Olaf's suggestion, of setting up an error handler that outputs the error details to a text file.

A simpler possibility might be to temporarily disable unattended mode. To do so, execute SYS(2335,1) at the start of the routine. This will cause the actual error message to be displayed on the screen. Make sure you remove the command after you have solved it, because you don't want a production COM server to run in that mode.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)