File is in use message when starting to compile a project

[Olaf Doschke]

One more thing: When I want to use your manager finally and edit something, there are several more apps missing, so there are several related projects, I assume.

Now, I really don't want to bother for all the source code. I wanted to mainly see what makes your usage of the build method work better, and don't worry, it's doing okay, because you usually don't run instances of classes you want to compile. Even if you do CLEAR ALL I'm always cautious and suspicious there would be something luring not cleared that skews the build compared to a build from a new IDE session.

But I do see the merit of releasing classes and class libs, as that is sometimes what keeps you from compiling. It really also helps to have the setting on to compile anything with any edit before save. (IDE option "compile before save"). I don't have "file in use" notifications because of editing since I do that. You extremely rarely get into a situation the compilation fails miserably or you have a deadlock situation on the file. I added a hook method to copy files I start editing in QueryModifyFile, that can defend against losing more than the current edit session. Because, obviously, the whole file (or file pair) is at risk when something happens during compile.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

After all this I still think a restart is the best option before any build.

I'd give it a go to actually start a VFP IDE, automate visualfoxpro.application. It still has the problem of running instances, as it doesn't matter whether they run in the same IDE session or not, so you'd need to do some bootstrapping yourself and not only start the new ide, also close down your own.

Before trying that, though, let's perhaps categorize the major situation you could have:

1. You just opened the IDE to make some modification to your project and didn't start anything, just purely edited code. I have difficulties imagining a programming session without test runs, but let's keep that aside. In a purely editing session you have all reasons to be angry about IDE editor(s)/designers keeping some class definitions and classlibs dangling in memory and blocking compilation, that's pointing out an unclean IDE. And I remember wOOdy telling some quirks I found still point out an old well known bug of VFP to sometimes have dangling file handles. I regularly can't open coverage logs before restarting the IDE, for example.

2. You don't just program, you debug, maybe even use

https://github.com/VFPX/FoxUnit

to run a unit test.
After such sessions, worst case scenarios have unintentionally unreleased instances, instances left over by errors cascading to releasing most but not all and, last not least situations the IDE has som added objects you want to stay resident.

You can argue, that such situations ask for a fix of your programming and testing to always end up in a clean and defined situation, which starts by using things like the FFC _set class of _environ.vcx. I don't have an idea from the top of my head how it might fail to release and thus not reset all SET commands by it's destroy making a final reset call. But if you imagine such mechanisms to fail, the only opposite solution is to give up such ideas and tidy up by restart.

What's really missing is a CLEAR ALL EXCEPT, of you ask me. The only easily and always achievable pure state is starting up an IDE and framework of the components you do want around at design time and even, and maybe explicitly necessary also at build time, starting from logging builds to maintaining meta data about a project etc.

I implemented the idea of an IDE restart for a clean build environment and started a new thread184-1804406, if anyone is interested. I think it could also be incorporated into a project hook beforebuild in a way not causing infinite recursion. Or into your own project manager... Replacing the need to clear all or clear classes and libs. Adjustments might be made about using environment manager, make any settings before the build, care for the override of the config.fpw I do, etc. but its all feasible. And when you configure your VFP to reopen projects the new session will even be back to what you left. Plus the restart once more saves all your command window commands and some other stuff that's saved when you quit VFP and that's therefore safe against loss when any build problem would crash VFP.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name