Our application path is set to ibi/apps/, whereas client approot is set to ibi/apps_cln/
Therefore any procedures (fex's) in the projects folder in Dev Stu will default to ibi/apps_cln/projectname.
Is there any way of setting the default APP PATH to look at the client APPROOT (ie ibi/apps_cln) first when running from the projects folder instead of looking at the live APP PATH.
In other words, if I have a production process which calls 1.fex 2.fex 3.fex and 4.fex, I might want to amend say, 3.fex in the projects folder and for that version to be called instead of the prod version, but the others to remain being called from prod.
Sounds easy, but Dev Stu and Reporting Server seem to want to drive me down their own independent paths.
The intention is to use Projects as a test/staging area.

Have you tried using a variable holding a fully qualified path to the fex you are trying to run?
&THISDIR = F:\ibi\WXYZ\ so that it runs F:\ibi\WXYZ\THISFEX.FEX
Then call the fex using &THISDIR to make it look in the location you want it to?
Reset &THISDIR to F:\ibiPath\abc\ so that it runs f:\ibiPath\abc\THISFEX.FEX when you want it to look at ABC.'
HTH

Yes, I can get it to work if I explicitly point to the projects directory, but this means changing possibly all the prod fex's accordingly to test for which directory structure to search through.
I was hoping for a simple (aren't we all!) app path structure for projects that would point to the client approot instead of being forced thru the production search path by the prod fex's.

How about having a controlling/master fex set location variables up for you, and all your code refer to those master variables? Then you'd change the controlling/master fex to do your testing, set everything to &CLIENT when you deliver the app to them:
Controlling/Master FEX location variables
-SET &CLIENT = "F:/IBI/APPS_CLN/";
-SET &TEST = "F:/IBI/APPS/";

Controlling/Master FEX
Change these as needed during development
-SET &FEX1LOC = &CLIENT
-SET &FEX2LOC = &CLIENT
-SET &FEX3LOC = &TEST
-SET &FEX4LOC = &CLIENT

When you include a fex, always specify the location via the variables:
-SET &INCLUDETHIS = &FEX1LOC | FEX1NAME;
-INCLUDE &INCLUDETHIS

OK, it's not super simple, but you wouldn't have to change all your code, just the controlling/master fex. And you wouldn't be touching the real code just prior to delivering to the client.
----------------------------------------------
P.S. BTW when you do an include that is a variable (as I did above), you may get the following message BUT the fex will run anyway:
(FOC227) THE FOCEXEC PROCEDURE CANNOT BE FOUND: &INCLUDETHIS
To avoid seeing this message use this syntax instead of the one above
-SET &INCLUDETHIS = '-INCLUDE ' | &FEX1LOC | FEX1NAME;
&INCLUDETHIS.EVAL
Thanks to this forum for teaching me this trick!

Try this in you personal profile:

quote:

APP MAP <testapp> "<testapp-path>"
APP PREPENDPATH <testapp>

<testapp> is a dd-name of your choice
<testapp-path> is the complete path of your test project below apps_cln

This will prepend the desired test-folder on top of your app path.

If in your projects in apps_cln you have only the focexecs to be tested, WebFocus will find those versions first, but for all the rest it will find only the production versions in your servers apps folders.

Be sure not having the code above in any production version of your profiles.

It may also work putting the code at the beginning of your main driving focexec. So to be executed before anything else and therefore changing the environment before any program logic.

Hope this helps !

Clearly a cleaner and more elegant solution, Roland. Great idea!

Already attempted to put the projects dir as PREPENDPATH, but for some reason Objects wants to override this path and still look into the prod path - although this may be an issue with re defining the APP PATH within my logic.
I'll let you know

Thanks guys, as suspected, I was re defining the search path lower down in my code. I've now changed the profile to look in the projects folder first and everything looks good now.

Re-opening this one guys.
After deciding that we wanted a common path for APPROOT , we decided to amend the search path back to ibi/apps in order that Projects will be able to see objects sitting in the app directories.
However, despite having updated cgivars.wfs and edaserve.cfg and amending the webserver alias, Dev Stu Projects still wants to point down the ibi/apps_cln path !!!!!
We have attempted to re-install DevStu locally, renaming ibi/apps_cln, but still wants to load a new project into ibi/apps_cln.
Frustration - big time.
TIA
Stuart