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!

 

[grahamrhind]

Hi Mike,

I've tried the error handler - surprise surprise, the error which comes out is "User-interface operation not allowed at this time. 1031". I'll try the SYS(2335,1) and see what happens, though I expect the same result. The user is on Windows 2000 and I was wondering whether permission limitations were preventing VFP from writing temporary files (I've come across that before) - we're still investigating that possibility.

 

[Mike Lewis]

Graham,

I was wondering whether permission limitations were preventing VFP from writing temporary files

Yes, I've come across that as well. In this case, it doesn't look like it's the issue, because the USE doesn't create a file. But it could be that the user doesn't have any permission for the directory in question.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

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

 

[Olaf Doschke]

You should first try my first suggestion in compiling your com server as EXE instad of DLL. That would allow the real error popping up.

Bye, Olaf.

 

[grahamrhind]

Hi Olaf,

You may have missed my comment on that earlier in this thread - the exe has been tried and works without error, also on the test machine.

 

[craigber]

You would get a runtime error if the proper runtime files are not installed. A MTDLL requires a different runtime than the EXE.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

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

 

[Olaf Doschke]

Hi Graham,

There are 2 Runtimes of VFP, one for EXE, one for DLLs.
If the EXE works without any error at the test machine, you may use a command not allowed with the Runtime for DLLs. There is a chapter on which commands are allowed with each runtime. I guess the error then doesn't really come from the use but by something triggered through that.

Hmm, as you are using VFP6 you can't have database events (OpenTable). Please post the code around the line of error, then we'll perhaps see...

Bye, Olaf.

 

[grahamrhind]

Hi Olaf

Are you saying that a VFP 6 DLL cannot open a table? If so, and if the solution is upgrading, then that would be easy - but I would be surprised at such a fundamental limitation.

The code where the error occurs is very simple:

USE lu\punc

where lu is a directory and punc is the table ....

An example of the full code where the program falls down is:

LPARAMETERS m.fieldcontents, m.countrycode
_FTEMP=m.fieldcontents
use lu\punc
set filter to coun_code=m.countrycode
go top
scan
M.PUNCTMP1 = ALLTRIM(altern)
M.PUNCTMP2 = ALLTRIM(correct)
M.PUNCTMPA = STRTRAN(M.PUNCTMP1,'s',' ')
M.PUNCTMPC = STRTRAN(M.PUNCTMP2,'s',' ')
_FTEMP = STRTRAN(_FTEMP,M.PUNCTMPA,M.PUNCTMPC)
endscan
GRCReturnedString=_FTEMP
close data
RETURN _FTEMP


Graham

 

[grahamrhind]

Oh, by the way, I should repeat again - the DLL works on my machine, which has VFP 6 installed. The problem is on a machine without VFP where the DLL is being accessed by Visual Basic.

 

[alvechurchdata]

the DLL is being accessed by Visual Basic.

Is VB passing the path and table name across to the DLL and is there any chance that VB is scrambling these parameters somehow? Are there spaces in the names?

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[grahamrhind]

Hi Geoff,

No, the only parameters being passed are the string being processed and the country code. The table is being opened from within the DLL. I also thought that the path might be a problem, but the user has a path on the local disk and without spaces, correctly named and with the correct contents. I've tested the VB program on my machine (which had VFP installed) and it works fine. It just doesn't work on the test machine that doesn't have VFP installed.

 

[Mike Lewis]

Graham,

Sorry to keep labouring this point, but ....

Where is the folder named lu? For your USE to work, it must be a sub-directory off your VFP default directory. If you don't explicitly issue a SET DEFAULT or CD command, the default directory will depend on where you launched the DLL from.

I suggest you temporarily replace the path in the USE statement to a hard-coded absolute path, not a relative path, pointing to the Punc table. If that works, that will tell you exactly where the problem is.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

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

 

[grahamrhind]

Hi Mike,

No, I'm happy for you to labour the point because I must have missed something along the way! I've already tried what you suggest - the error remained.

Graham

 

[Mike Lewis]

Graham,

Oh, well. It was worth a try.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

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

 

[jrajesh]

Graham,

just in case, you may want to check the existence of the file using -
if file("lu\punc.dbf")

or

perhaps try and read the file using Fopen().

Rajesh

 

[Olaf Doschke]

Hi Graham,

of course VFP6 can open tables. I was talking of the Database Event OpenTable, which is triggered as stored procedure, if you are opening a table of a vfp7 or higher dbc with database events activated. OpenTable is the name of a stored procedure within such a database, which is automatically triggered by use of a table of that dbc.

That is a thing which could cause an error, if it is not caused by the USE itself. Did you not only put the VFP6 runtime DLLs in the system folder or the folder of your DLL, but also registered it? Especially vfp6t.dll for support of a multithreaded COM server DLL?

How does VB use the DLL? Can you post the VB code?

Bye, Olaf.

 

[grahamrhind]

Hi Olaf,

I know this thread is very long and not very easy to follow, but I'm using VFP 6 and a (VFP 6) table and not a database container.

In any case, I've decided to upgrade to VFP 9 to see if this will resolve the problem. I'll report back to this thread once I've made all the necessary adjustments to the code and retested.

Graham

 

[Olaf Doschke]

Hi Graham,

I don't think VFP9 will solve your problem. I've seen you are using VFP6, but you give away so little information that I was just checking point for point what could be reasons. Just because you did the DLL (with VFP6) the database or table needn't be done with VFP6.

As you are so sure you are in the correct path and use the correct table name I really can't imgine any other things that could raise that error despite of all the things me, you and others suspected - wrong path/alias,table already being used/locked, insufficient user rights or some code in an OpenTables()-Event raised by the USE. From the help about that error one learns, that it can only come from commands displaying something - including an error rasing an error messagebox.

Just one final thought. Maybe you think the error is in the USE line, but in fact it's at another line in your code. Under circumstances message(1) may not give you the real code raising the error, especially if it isn't raised by executing code but by some faulty behaviour during the event loop, then you may simply get the last line executed sucessfully beforehand. Maybe logging lineno() will tell you an absolute line number of the whole prg file and lineno(1) will tell you the number within the faulty method. So try additionally outputting transform(lineno()) and transform(lineno(1)) in the little error handler I gave you and see which line (number) throws the error.

Bye, Olaf.

 

[Mike Lewis]

Graham,

I have to agree with Olaf.

Although I would definitely not discourage you from upgrading to VFP 9.0, I don't see how the upgrade on its own will solve this particular problem.

There is no evidence that the problem is caused by a bug in VFP. My guess is exactly the same problem will occur after you have upgraded. Better to focus your attention on tracking down the cause of the error.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

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

 

[grahamrhind]

Hi,

Two comments about the upgrading. First of all, we've had numerous issues and failures because VFP 6 wasn't creating a distribution containing the correct VFP dlls, and I hope VFP 9 will have sorted it out.

Secondly, I cannot get to the reason why the error is occuring in VFP 6. VFP 9 seems to have better debug possibilities with things like TRY/ENDTRY. Without those, we could continue discussing in circles. Also, certain bugs such as one where the language settings of a PC affected the ability to run a VFP 6 dll will have been resolved.

In other words, I'm upgrading to enable me to be able to locate the problem so that I can get further with this. I'll report back when I have been able to create a new VFP 9 version and to test it.

Graham

 

[Mike Lewis]

Graham,

... VFP 6 wasn't creating a distribution containing the correct VFP dlls, and I hope VFP 9 will have sorted it out.

With VFP 9.9, you will be using the bundled InstallShield, which is much more robust (but also more complex) than the old setup wizard.

VFP 9 seems to have better debug possibilities with things like TRY/ENDTRY.

That is definitely true.

I hope you will be able to track down the problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

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