How can I call external functions in different paths within App Designer

I am constructing a GUI using APP Designer from a .m script, which calls some developed functions. My .mlapp file is in C:\GUI_files.

The problem is simplified as:

Within the main body, the main function A is called in a callback function for a button, A is in the same path with .mlapp (C:\GUI_files). Within function A, another function B is called which is in path C:\GUI_files\toolfunc, it is accessed in A by command 'addpath[C:\GUI_files\toolfunc] '. Within function B, function C is called, which is in a .p file and not readable. Function C is in path 'C:\GUI_files\toolfunc\toolfunc\tolls', which is a subfolder of B's path. Within B, the func C is accessed by command 'add path[C:\GUI_files\toolfunc\tools] '. That means the function will call another function in a different path.

It works well in the MATLAB environment, however, it shows error when I make it to a standalone Desktop APP. I assume that maybe the path changing command does not work within a packed App, because with the Compiler no folder can be chosen but only files. Because of the .p file, I cannot see the complete function, so I am not sure if the problem is it. So I want to ask, if the different paths of the called functions/ 'addpath' and 'cd' commands matter the standalone Desktop application?

Answer 1

[Arthur Roué]

You should use relative path instead of absolute one, especially if you make your app standalone.

For instance, you can get parent folder path of a running function with :

ParentFolder = fileparts(mfilename) 

If you write this line in your main function, the output will be C:\GUI_files. You can also use pwd function.

I also prefer to define my environment path in a startup function instead of adding new folder to path throught programm execution.

It's also possible that the function in a p file call another function which is not package in your standalone because MATLAB can't detect dependencies of P-Files. In this case, you have to manually add the required function to the standalone.

[Tian Zhao]

Thank you for your answer, that helps me a lot.

After checking the paths and required functions, I found the Problem: By executing the .p file, a .txt file will be created and it is the input file for an .exe file, which is also called within the same .p file. The situation is, when the app under Matlab executing, the .txt file is created and saved under the same path with the functions so that it can be found by the .p and used by the .exe. However, when it turns to a standalone app, the dynamic created .txt is saved in the folder for the app but not the path of the packed function, so the .p file cannot access to it, executing the standalone app is also broken down. I have read many questions to find a way that can either

find the path for the compiled functions in the apps and join the dynamic created .txt data to it

or

access to an external path, where the .p file and .exe is saved and the .exe is called and executed in this path, so that the .txt can also be saved in the same place and accessable.

These are two possible solution I can imagine, however, I did not find any helpful idea and am stuck for weeks. Could you please give me some advice of the problem? Thanks a lot!

[Arthur Roué]

It seems that your problem is due to the impossibility to chose the location where *.txt is located because of the p-file (content-obscured). If you can't rewrite it, maybe you kind find a workaround with the function cfroot. This function return the location of files related to deployed application, it may be the location where p-file generate the text file.

[Arthur Roué]

Did you find a way to fix your problem ?

[Tian Zhao]

Yes. Thanks a lot for your suggestions! ctfroot can find the path where the functions for App are deployed. However, it does not work since maybe there are codes for path changing within the .p file. I shifted the .p file and all of the relevant functions to a public drive, so that it and the dynamically generated .txt data can be accessed during the execution. In any case, thanks for your kind help :)