>>Or does it NOT make a difference?
>>
>>At the top of my Main.PRG, before READ EVENT, I issue this code:
>>ucRootDirectory=SYS(5)+SYS(2003)
>>ucPath=["]+ucRootDirectory+["]
>>SET PATH TO (ucPath)
>
>>My understanding is that a program like FileMon, would present a less clutered assessment of my VFP Install runtime.
>
>Terry,
>
Let's first define exactly what a "Best Practice" is. IMO, a "Best Practice" is one that somehow enhances the readability or maintainability of the program or, hopefully, both.
Thanks for the response. I am not suggesting it is a "best practice" - I was just "wondering". The code is not for readability or maintenance. The hope was that adding that code to a Main PRG would reduce the the OS "search" routines while an Installed VFP EXE was running. I have seen real time FileMon? assesments of a VFP install and I was amazed how many times the OS looked for something the app was trying to do before it finally found it. I've been reading threads related to the "App Verifier" that asses "logo" compliance - and [agian] wondered if that code would make a difference to both OS searches and logo compliance success.


>
Several questions arise here. The major one from my POV is, "What about the path set in the configuration file?" In the above case, what you're doing is either completely changing it or it isn't being set. Does this enhance the program? IMO, it doesn't.
Again - I don't know - and was just curious. As for as the path setting being changed at load, I would guess that it could be set back at unload - but again I am ignorant of those facts too!:-)

>
Another thing is that you're cluttering the main program with this code. Why not create an "Environment" object that handles something like this?
My concern was not so much how three lines of code would clutter a VFP app, but the hope that adding those three lines of code would reduce the number of registry and system searches by the OS while a VFP app was executing. My question should have been: Will this code make my app more efficient? Would this code improve a VFP app's prospects during a logo (compliance) verification test? I should have worded it differently - I guess:)
>
One of the biggest misconceptions, IMO, about programming is the, "Well, it's only a couple of lines of code". It doesn't matter how many lines it is. I've written stuff that was two lines long in their own method. What matters is that the code is re-usable, functionaly cohesive and easily maintable.
Again it wasn't so much "cluttering" a VFP sorce set, as it was "clutering" up the "FileMon" reporting window VFP application was executing. Again - I was amazed at how many times the OS failed, as reported by "Filemon" to find this or that object while my app was running. I thought it would be more like an xBase "SEEK". If it's not there - it's never there. But, if you rely on my interpretation of a "FileMon" assessment, "if its not there now, look until you find it"!


A
>
>The question for you is, "Does this meet the above criteria?"
>
>Regards,