Open tobiasbecher opened 5 months ago
These checks are implemented already almost everywhere using license('test,...')
and license('checkout',..)
else (e.g. DICOM import, parallel toolbox uses, fmincon, etc.).
I do not see this as critical, though. It throws an error when the license is not available, and the error message is quite comprehensive. We can now check and throw a different customized error (is that more comprehensive?)
I think that it makes most sense to explicitly check when there's an alternative to use instead or if we request availability (e.g. for listing available algorithms to the GUI). But you are very welcome to implement the check in the respective code fragment run by example 10 and make a PR onto the dev branch, if you think that it is more comprehensive.
The specific error shows up in matRad_addMovement. I don't know for sure if a custom error, telling the user that the imaging toolbox needs to be installed for this functionality, is more comprehensive, but if someone without much Matlab experience tries to run the example, they might not directly think that the error is because of a not-installed toolbox.
Some parts of the code require the imaging toolbox, which when not installed throw some errors. E.g. when running the tests I get an error in example 10 since it uses the "imwarp" function. The error thrown is:
Undefined function 'imwarp' for input arguments of type 'double'.
We could add some check for imaging toolbox functions when calling these functions.