Method is not defined or is removed from MATLAB search path

Hi, this error occurs in the new versions of MATLAB (version = 2018b)

This error occurs when you have defined a method in a separate file,

This occurs for the both static and regular methods.

When every thing is correct and even the MATLAB auto-completion finds the method,

but when you call the method, the error "Method is not defined or is removed from MATLAB search path" occurs.

Note that this error is automatically resolved when MATLAB is restarted multiple times!

I think it is a bug in the new versions.

[Jan]

R2018b is the version from the last year. R2019a is newer.

Can you post the files, which reproduce the problem and post a copy of the complete error message? Are the files stored inside Matlab's installation folder matlabroot or on a network or cloud drive? What exactly does "restarted multiple times" means? What about rehash?

[Guillaume]

Most likely, one of your script/function uses cd which changes which folders are on the path.

There are two sides to this:

• there's never any need to cd into anything, thus the current folder shouldn't change
• you shouldn't rely on the current folder, instead the class folder should be on the path

Without more details about the files/class causing the problem and what code is actually executed, we can't really help you.

[Paul Rancuret]

I've experienced a similar problem, so I'll share a bit more detail. I work in a large company, on a team which uses tools from multiple other teams. It is routine for us to add a folder containing tools developed by another team onto our path so we can access some of their useful scripts - but we would place those other tool folders lower on the path than our own tools.

For example, we could have a folder 'ourTools' near the top of our path, and another one 'theirTools' somewhere lower on the path (usually cloned from a git repo). If someone on that other team adds a file with conflicting name in 'theirTools', by default it would be overshadowed by our version of the file, since 'myTools' is higher on the path.

For a class and its methods, I've found this gets a little more tricky. For example, assume I have a class named doCoolStuff stored under the ourTools/@doCoolStuff method directory. The ourTools directory is at the top of the Matlab path, so ourTools/@doCoolStuff is also automatically searched. Inside ourTools/@doCoolStuff, assume I have doCoolStuff.m as the top-level class file, which includes public methods coolMethod1() and coolMethod2(). Those methods are coded separately and placed in the ourTools/@doCoolStuff folder as coolMethod1.m and coolMethod2.m.

This all works well and good, until somebody on another team creates a regular function file named doCoolStuff.m and places it in 'theirTools.' Ideally, since 'theirTools' is lower on the path than 'ourTools' I would have liked our version to still be used and ignore that new one in 'theirTools.' However, since our file is in a method folder, it seems to get evaluated at the bottom of the path. Thus, our doCoolStuff.m file defining the class is overshadowed by the regular function file in theirTools. In this case, which('doCoolStuff') can be used to verify this.

To fix this, I was tempted to just make myTools/doCoolStuff a regular folder instead of class folder (removing '@' from the name) and place it on our path higher than theirTools. Doing this does result in our version of doCoolStuff.m winning (as verified using which('doCoolStuff')). I can also see that the coolMethod1.m and coolMethod2.m methods are found on the path, using the which() function again. Unfortunately, they don't seem to be correctly attached to the doCoolStuff class anymore for coolMethod1() and coolMethod2(). In this case, when trying to call the methods, I get this result:

>> coolStuff = doCoolStuff(); % instantiate from the doCoolStuff class.
>> coolStuff = coolStuff.coolMethod1(); % Call coolMethod1.  Auto-complete does find coolMethod1 as I type
Error using doCoolStuff/coolMethod1
Method 'coolMethod1' is not defined for class 'doCoolStuff' or is removed from MATLAB's search path.

I've always just used method folders when separating method functions into their own files within a class. So I'm not sure if there's another way to make sure it gets attached correctly if using a regular folder in the path instead of a method folder.

For now, I think the only way around this may be to either re-name our class, or try to get the other team to re-name their function. That's a bit of a pain either way.

Is there a way to ensure 'ourTools/@doCoolStuff' would be higher on the path than 'theirTools'? If so, that would solve the problem for me.

I've experienced this in 2017b. I also have 2019a but haven't tested in that install yet.

Thanks for any help!

[Guillaume]

This shouldn't be the case, class methods take precedence over folders on the path, see function precedence order. If that's not the case, you may have encountered a bug.

Note that

which('coolMethod1')
which('coolMethod1(coolstuff)')

should return different result.

[Paul Rancuret]

Thanks Guillaume for the response.

When you say this shouldn't be the case, do you refer to the first bullet point below, or the second one (or both)?

I've verified again that both things are true:

• When doCoolStuff.m is inside the ourTools/@doCoolStuff folder (method folder), it gets overshadowed by the one in theirTools, even though theirTools is lower on the path than ourTools.
• When doCoolStuff.m is inside the ourTools/doCoolStuff folder (regular folder on path), both the class and method files are found using which(), but the error mentioned in my post above occurs, indicating that the associated methods were not found when trying to actually call the function.

Here's a printout again of me trying the second bullet-point (removing '@' from class folder name and adding it to top of path). Just note I've replaced the names of my actual class/methods/folders with the dummy names from this post, but otherwise this is how it happened.

>> which('coolMethod1(doCoolStuff)')
C:\ourTools\doCoolStuff\doCoolStuff.m  % unitTest method
>> which('coolMethod1')
C:\ourTools\doCoolStuff\coolMethod1.m
>> coolStuff = doCoolStuff();
>> which('coolMethod1(coolStuff)')
C:\ourTools\doCoolStuff\doCoolStuff.m  % unitTest method
>> coolStuff.coolMethod1();
Error using doCoolStuff/coolMethod1
Method 'coolMethod1' is not defined for class 'doCoolStuff' or is removed from MATLAB's search path.

I've also gone ahead and tested this with R2019a, with the same result (both bullet points).

If this is a bug, do I need to report it somewhere?

[Steven Lord]

Can you simplify your doCoolStuff and coolMethod1 files down to their most basic version with which you can reproduce that behavior and post them so we can investigate? It's hard to get a sense of what's really going on just from the text description; seeing the code may help clarify what's going on.

[Guillaume]

Yes, neither bullet point should be true. and I can't reproduce the issue (R2019b but while there's been some changes to scoping, it shouldn't apply to this case):

%all paths relative to current folder
classparent = 'ourTools';
classfolder = fullfile(classparent, '@doCoolStuff');  
funfolder = 'theirTools';
%create required folders
mkdir(classfolder); mkdir(funfolder);
%create class files
%ourTools\@doCoolStuff\doCoolStuff.m
%ourTools\@doCoolStuff\coolMethod1.m
fid = fopen(fullfile(classfolder, 'doCoolStuff.m'), 'wt');
fprintf(fid, ['classdef doCoolStuff', newline, '\tproperties', newline, '\t\tp;', newline, '\tend', newline, '\tmethods', newline, ...
              '\t\tfunction this = doCoolStuff', newline, '\t\t\tthis.p = randi(1000);', newline, '\t\tend', newline, '\tend', newline, 'end']);
fclose(fid);
fid = fopen(fullfile(classfolder, 'coolMethod1.m'), 'wt');
fprintf(fid, ['function coolMethod1(this)', newline, '\tfprintf(''Called class method, p: %%d\\n'', this.p);', newline, 'end']);
fclose(fid);
%create function file theirTools\coolMethod1.m
fid = fopen(fullfile(funfolder, 'coolMethod1.m'), 'wt');
fprintf(fid, ['function coolMethod1(~)', newline, '\tfprintf(''Called function, p: %%d\\n'', -randi(1000));', newline, 'end']);
fclose(fid);

disp('theirTool higher up in path than ourTool')
addpath(classparent); addpath(funfolder);
t = doCoolStuff;
t.coolMethod1;
coolMethod1(t);
coolMethod1(pi);

clear('classes'); %#ok<CLCLS>
disp('ourTool higher up in path than theirTool')
classparent = 'ourTools';
funfolder = 'theirTools';
rmpath(classparent); rmpath(funfolder);
addpath(funfolder); addpath(classparent);
t = doCoolStuff;
t.coolMethod1;
coolMethod1(t);
coolMethod1(pi);

The class method is found regardless of which folder takes precedence in the path.

[Paul Rancuret]

Guillaume and Steven Lord,

I apologize, I made a very stupid mistake. I thought the particular 'ourTools' folder I'm describing was on the path, but I had a typo in the script I used to set my path, so it wasn't actually on the path. Only the children of 'ourTools' were actually added to my path (other than the method folder described). So that was my problem all along.

Sorry for wasting your time, and I appreciate that you did look at this for me!

Regards,

Paul Rancuret

[Steven Lord]

In that case, would it be fair to eliminate the "bug in matlab [sic] path" tag from this question since it didn't turn out to be a bug with the search path?

[Danny Kumpf]

I experienced what I think might be the same issue today.

I have a class folder, say @MyClass, that has various methods; some defined within MyClass.m, and some defined in separate files in the @MyClass folder. Trying to call one of the externally-defined methods on an instance (ie instance.myExternalMethod()) gives me the error, even though the parent directory of @MyClass was on my path:

Error using MyClass/myExternalMethod
Method 'myExternalMethod' is not defined for class 'MyClass' or is removed from MATLAB's search path

The strange parts are that:

• I've been using the same class, methods, and matlab path for months with no issues. The only potential difference this time was that I was running another MATLAB instance in the background in the same working directory as the one in which I was seeing this problem
• Methods defined within MyClass.m are working just fine
• Matlab IS able to auto-complete the names of the class methods that it supposedly can't find. Ie, typing instance.myEx and hitting tab correctly auto-completes to instance.myExternalMethod
• Examining the path variable shows nothing amiss. The directory containing @MyClass is on the path, and there doesnt seem to be anything on the path that might be confounding things
• Performing which('MyClass') shows what I'd expect: \\server1\...\@MyClass\MyClass.m % MyClass constructor
• Performing which('myExternalMethod') shows: \\server1\...\@MyClass\MyClass.m % MyClass method (note: there is a method stub of myExternalMethod in MyClass.m)

So it really looks like MATLAB is finding the method, but for some reason can't call it.

The issue ended up fixing itself, and here's what happened:

• Since the which() call on the external method returned MyClass.m instead of @MyClass/myExternalMethod.m, I wanted to see what would happen if I commented out the function definition stub in MyClass.m. That is, MyClass.m contains the line "myExternalMethod(obj)", and I commented this out
• After that, the call to which('myExternalMethod') showed: \\server1\...\@MyClass\myExternalMethod.m as I might expect
• And now, suddenly, everything was working again. I could call instance.myExternalMethod() without throwing an error.
• I then un-commented the function stub, reverting the file to its original state, and everything was still working fine. So essentially the issue fixed itself somehow. All of the other external methods also started working (they had all been causing the same error).

So the issue seems to have fixed itself for me, but I have no idea what caused it in the first place, or why it was fixed. Figured I'd add my experience here in case it helps anyone else or helps figure out the cause of the issue.

[Informaton]

I was seeing the same error yesterday, and it also turned out to be a mistake on my part.

I had organized my code INCORRECTLY like this at first:

• /parentFolder/myClass.m
• /parentFolder/@myClass/foo1.m

It should have been like this:

• /parentFolder/@myClass/myClass.m
• /parentFolder/@myClass/foo1.m

In both cases, I added the parentFolder to the MATLAB path (i.e. addpath('parentFolder')), but it made it difficult to troubleshoot. The problem went away once I moved myClass.m into the @myClass/ subfolder.

Here are some helpful references:

1. https://www.mathworks.com/help/matlab/matlab_oop/methods-in-separate-files.html
2. https://www.mathworks.com/help/matlab/matlab_oop/organizing-classes-in-folders.html

[Walter Roberson]

Ralph comments to @Informaton

This is not accurate. It only resolves the issue intermittently - precisely the problem alluded to by the OP.

[Walter Roberson]

Ralph :

Informaton's posting was an accurate description of the cause of their problem, and so is useful to inform people about things to check that might turn out to be valid for them. People are not required to know and describe all causes of similar symptoms.

[Pavitra kumar]

I had the same error. I was designing an app which was supposed to use two separate window (one the welcome window and other the calculation window). I had designed in such a way that if the user pressed the "Proceed" button on welcome window then the welcome window was closing and the calculation windows was poping up. It was working fine when run from the app designer. But when it was complied as "Matlab app" it was woking fine for welcome window, but once proceed button was pushed and the welcome window was closed, then nothing was working. I was given this errors whenever I pressed any of the buttons.

"Method 'ComputeButtonPushed' is not defined for class 'predict_compute_app' or is removed from MATLAB's search path."

I digged deep into it and found that I was compiling the app using the welcome window, which was fair enough. But the problem occurred when the program closes the welcome window, as per the app design. When I compiled the app using welcome window as the main app, then welcome window needs to be open thorughout the running time of the program. I resolved this error by restructuring the code that does not close the main window.