Build in new IDE session to avoid build problems due to files in use 2

[Olaf Doschke]

In a recent thread the problem pf files in use you can sometimes face when building a project was discussed.

To be clear, it's all about comforts and convenience, as you can always do CLEAR ALL manually before build, can always restart the IDE yourself, etc. It's all juts habits each has to find himself, how important or not this is to him.

I come to the conclusion that an IDE restart before build is the simplest option. Here's a way to do so automatically and also automatically build. Proof of concept code follows. The idea is, that you prepare a build script building the active project, and let a new IDE session run this, so no loaded classes, classlibs or class instances are in the way of the build.

You might incorporate many more ideas into the build script itself, but the base idea besides an IDE reset getting rid of any eventually open files is, you even go back to the state you currently have about open project or projects, if you have VFP settings to do that. The script defends against the situation the project you want to build does not reopen automatically and then cares for opening it before build.

This conceptual script needs refinement for any other build processes you might want to do, ie building an APP instead or a DLL. But it's complex enough as a proof of concept. The only thing in your way would be when the current IDE session does not QUIT, but then you're in serious trouble, should fix that and restart for a build anyway. And the only other weakness I see in this is that it overrides your usual vonfi.fpw file for the build restart. So you might want to modify the idea to incorporate the COMMAND line used for ramping up the build automatically into the standard config.fpw you use, if any. And when you make use of COOMMAND already, also manage how to streamline to build script into whatever your startup code does.

I did not make use of _STARTUP, as that would need to be set as default and then permanently alters each following start unless you reset it. I think using the command line option for config file is the less invasive method to do that. Next time you start it'll start with the standard config.fpw again, so it's just a detour of the one restart I do for the build process.

* Restarting the VFP IDE and
* let it run startup code via COMMAND=... option in a config file

* Writing a script for the active project
lcProject = _vfp.ActiveProject.Name

Text To lcBuild TextMerge NoShow
Declare Integer Sleep in Win32api Integer dwMilliseconds
Sleep(500)
Doevents Force

Local lcProject, loProject, llFound
lcProject = '<<lcProject>>'
* look whether the project is reopened by IDE start
For Each loProject in _vfp.Projects 
   If loProject.Name == lcProject
      llFound = .T.
      loProject.Build('<<ForceExt(lcProject,"exe")>>',3,.t.,.t.,.f.)
      Exit
   EndIf 
EndFor

If not llFound
   Local lnProjectIndex 
   lnProjectIndex = _vfp.Projects.Count+1
   Modify Project ('<<lcProject>>') NOWAIT
   _vfp.Projects(lnProjectIndex).Build('<<ForceExt(lcProject,"exe")>>',3,.t.,.t.,.f.)
EndIf 
EndText

* Save build script to TEMP
lcBuildFile = Addbs(GetEnv("TEMP"))+"buildexe.prg"
Set Safety Off
StrToFile(lcBuild,lcBuildFile)

* Save config file to TEMP, which starts the build script
lcConfigFile = ForceExt(lcBuildfile,"fpw")
StrToFile("COMMAND=DO '"+lcBuildFile+"'",lcConfigFile)
Set Safety On

* quit to both shut down and let a new IDE take over the build process.
* _vfp.ActiveProject.Close()
Run /N vfp9.exe -C"&lcConfigFile"
On Shutdown
Quit

And just one remark on the code itself: I can also do without the Sleep() waiting for the case the previous IDE is slow in closing. In my case the quit is always pretty fast and the new IDE can go in straight. DOEVENTS FORCE should also help with the event order, so the new ide really gets hands on the PJX either on its own or by the mechanism ensuring it's open to use and build it via project.build() method.

Last not least: When I now prepare the unfortunate situation to have class instances, this IDE start gets rid of them. So, as said, you'd have to have a serious blocking problem to not be able to QUIT the current session while RUN /N starts up a new vfp9.exe process in parallel.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Dan Olsson]

Wow Olaf, as so often I'm amazed on your knowledge of the workings of VFP.
I suppose there are no more MVP:s appointed anymore for VFP, but I would sure vote for you

 

[Olaf Doschke]

Thanks, Dan.

Indeed Microsoft deprecated the VFP category 2010, so I lost MVP status. And I didn't make it to SQL Server MVP or any other. I went other routes.

This, by the way, I like better than the keyboard macro idea. But it's still quite an academic solution. It shouts out, simply restart VFP for build, unless your current session is clean anyway. I wouldn't restart when I know I just made some fix or change I now want to compile.

And it would be quite surprising IDE behavior when you actually build this into a project hook, for example. Too surprising, violating a SOLID principle, the POLS, principle of least surprise. So the normal solution is clearing classes and libs.

Last, not least, it's an annoyance of the VFP IDE to be that restrictive. I don't see any JAVA Or C/C++/C# IDE hinder you from compiling. The whole structure of source code is also not including any binary files like VCXes are. Visual Studio, for example, won't hinder you opening a solution (equivalent of project-hierarchy) twice. Allowing that, it handles situations about changes from a secondary session by asking you to handle it.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name