Is it possible to get the path of the calling project in a sub project? My sub project lives in a different folder (Shared Functions vs something specific to a project).
The relative paths in the sub-project are writing to the sub-project path, not the calling project path. I could pass it as a parameter if there was a function or some other special parameter that could be used
Retrieving full path of the calling (or current) project is not possible at this point.
@andrew.rybka, IIRC you had a similar problem. Did you find any workaround?
@dgudkov @joebo I wan't been able to find a good workaround.
For now I just type in subproject-relative paths to target files into calling projects and then pass those paths into suprojects as a parameter.
I got reasonably close by using powershell and enumerating the process list
powershell -command "$parent1 = (gwmi win32_process -Filter processid=$pid).parentprocessid;$parent2=(gwmi win32_process -Filter processid=$parent1).parentprocessid;(gwmi win32_process -Filter processid=$parent2)"
Then using sysinternals handle.exe, I was hoping it would turn up in a handle list, but it doesn't. Makes sense because the file isn't locked / kept open at the time.
Wouldn't it be simpler to just pass the project path explicitly as a constant or a parameter? It's not as elegant as automatic detection but it could be the simplest solution.
Yes, it would be easier. I found that there is two ways of reusing logic in easymorph - calling projects and copy/pasting tabs between projects. For example, I have a generic "Validation" tab which has a series of transformations to apply to a data set to look for extreme and missing values. I would like our team to be able to just copy/paste that tab into their project and then switch the input table (the source for the derived table).
It seems to work well. I want the history of loads to be retained and remembered between calls. This path could be a parameter, but it's better if it's one less thing to configure. A parameter is probably best for now.
This is spot-on. I've seen people create "library projects" with tabs and tables containing pre-designed calculations for various cases (mostly related to data quality checking). Such projects aren't executable per se and only used as a way to copy/paste pre-designed calculations into other projects in order to quickly construct a logic from larger building blocks.
I've created a workaround for determining the current project. See attached: getwd.morph (3.6 KB)
It works as long as the project is opened via the command line or by double clicking. It does not work and halts if there was no command line argument.
It can also be called via Call Project
