File access is denied 1

[Koen Piller]

Hi,
I have built a small project, works OK. The project uses one dbc with one table only.
I have than built an exe - no errors. But mainform is not shown.
When I than return to my VFP development and try to run the pjx again, it errors Database ~full path database : "File access denied".
Quit VFP and restart the PJX - again the error.
Restart PC and voila pjx working.
The files (DBC and the DBF) all have write and read a.s.o. permissions.
So the error occurs only on starting the exe and remains there untill a restart of the pc.
Do we have a hint how to solve this?
Regards,
Koen

 

[bborissov]

After running the EXE check if the name of the EXE is in running processes in Task Manager.
You can kill it from there, no need of restarting PC.


Borislav Borissov
VFP9 SP2, SQL Server

 

[Mike Lewis]

Koen,

Are you sure you are excluding the database and the table from the build?

In other words, are the names of the database and table visible on the Data page of the project, and if so, do they have an "excluded" symbol against them? This is a little circle with a diagonal line through it? If you can see either of the files but not the symbol, then that might be the cause of the problem. The easiest solution is to remove the files from the project (but don't delete them for the drive, of course).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

@Boris,

The exe is not running in the upper part but in the back ground process. Which I overlooked. After killing that background process, I could run my PJX file.

@Mike,
The Database is excluded, the Ø symbol is in front of the database name and the dbf name. Validate Database informed "Valid".
The mainform runs correctly in my PJX file, and never shows in my Exe.

Very sorry to have bothered you.
This was a basic error. Since it is a small pjx with only one form and without a menu, I had never noticed during development: the one and only form had ShowWindow = 0, which does not work in an exe, changing it to 2, and voila.

Regards,
Koen

 

[Mike Lewis]

Glad you have solved it, Koen. But just to put the record straight, it is not true that forms with ShowWindow=2 do not work in an EXE. On the contrary, that is the normal setting for most forms.

I suspect that the real cause of the problem was that you are making _SCREEN invisible, either by setting its Visible to .F. or with SCREEN = OFF in your Config.FPW. That would make the whole application invisible, except top-level forms (which exist outside _SCREEN).

Because you couldn't see the application running, you couldn't close it down. So there was an instance still running the next time you ran the app, which caused the File Access Denied error.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Mike,
You are 100% correct. In my haste to produce this small .exe I had copied and pasted from other working projects some coding and indeed there it was:

_Screen.Visible = .F.
_Screen.WindowState = 2

Thanks for pointing me in the correct direction and thanks for correcting my wrong conclusion.
However, when I do that, mind you there is no config.fpw in the .exe directory, the exe runs perfectly on my desktop and when closing (clicking the Redcross (Query Unload) I get a big white DOS-like VFP box with a minimal working menu, see screenprint attached. Closing this menu by clicking its red cross is impossible.
F.i.w. the coding in my QueryUnload of the frmMain.scx

CLEAR events
thisform.Release()

Please note this white DOS-like VFP box there must be some code running since it flickers continuously until I activate a menu bar of this box.
Any idea what is wrong in my case?
Thanks,
Koen

 

[Dan Freeman]

Your problem here is that CLEAR EVENTS is being blocked from properly exiting your application.

You've somehow created an object reference to a form or some other object (in a public variable, member of _Screen, whatever) that cannot be released when CLEAR EVENTS tells all programs to stop executing.

This is structural and can only be solved by fixing the structure. Some object somewhere is holding your EXE open even after you've told it to drop dead.

 

[Olaf Doschke]

Dan might be onto something.

But I can reproduce a situation like yours with a project as simple as only having a main.prg with this code:

On Shutdown Clear Events
Read Events

No embedded config.fpw.

This EXE will do nothing but READ EVENTS. The ON SHUTDOWN beforehand is there to be able to cause the CLEAR EVENTS, in itself it is not running CLEAR EVENTs, just like ON ERROR errhand() does no call to the error handler, it just says to do so in case of an error. So here a shutdown of either Windows itself or the process will cause the CLEAR EVENTS necessary to break out of the READ EVENTS.

If you start this I get a message about an invalid resource file (that's foxuser.dbf) and whether I want to overwrite it with a new empty one. It doesn't matter if you say yes or no, the app starts and what you'll see is the _SCREEN, and it has exactly the minimum menu you show in your screenshot, that's what the runtime offers as sysmenu, it lacks items that are only part of the IDE vfp9.exe, not in the runtime screen, but it simply is the full sysmenu.

Exiting by clicking the upper right _screen close button the app gives another message about foxuser.dbf, this time saying it can't write into the file C:\Windows\System32\foxuser.fpt. And if you confirm this you get into the flickering to the _screen and are only able to kill the process.

This is similar what you show and so I guess you get to this base situation, you're quite near to a final exit, but you're stuck, just not seeing these error messages. Maybe you have ON ERROR set to log errors or even suppress them in this phase. But also maybe - as said - Dan is onto something and your problem isn't about the foxuser.dbf at all.

It seems to me Windows UAC causes VFPs legacy use of System32 to not be redirected to SysWow64 all the time and that causes trouble it seems both at start and exit of a VFP process about the foxuser.dbf it manages. To avoid such problems one straight forward solution is to avoid using any foxuser.dbf resource file for your apps, so include a config.fpw with RESOURCE=OFF. I would also say this whole situation is awkward as the foxuser.dbf usually would be created in the folder of your EXE, neither in System32 nor SysWow64, so UAC would never be involved. But I've seen this message about invalid foxuser.dbf in a newly installed or built EXE with no foxuser.dbf present earlier, too, even under XP. So it's not the first time the foxuser.dbf resource file of an application was more destructive than constructive.

Test it for yourself, it might still be something completely different in your case. Dangling object references, anything still on the call stack that keeps VFP stuck in it can cause CLEAR EVENTS to never become effectively going to the line after READ EVENTS. Here it surely does. Still, the stub of any EXE VFP creates and/or the runtime initialization and initialization has and/or causes trouble with foxuser.dbf handling.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Hi,
The exe did not closed in my case until I put following line in my SetSettings ( the procedure which sets all the VFP settings)

ON CLOSEDOWN CLEAR EVENTS

Anyway for me the problem was solved.
Happy Easter.
Koen
"Stay Corona away" -> 1,5 mtrs

 

[Olaf Doschke]

Hi Koen,

Happy Easter to you, too.

I also could fix my own problem and can cancel the general alarm of foxuser files corrupting every time when using my minimal exe code. After deleting a broke foxuser.dbf from AppData\Roaming no foxuser was created in system folders anymore, but in the application folder, as expected. I can still recommend embedding a config.fpw with RESOURCE=OFF so no such corrupt dbf can cause trouble unless there is specific usage of foxuser.dbf in an application.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name