Is there a way to know from fig file which code file created it?

Hello all, it may be impossible, but if the fig files contains this data this would make my life much easier. Is there a way to know from fig file which code file created it?

Thanks in Advance

[Marc]

Are you asking this because you have saved fig files with no idea where they came from? Just wondering since I have seen/heard this question before from various grad students in larger research labs

[Walter Roberson]

There was a Question asked here a couple of years ago along exactly those lines, that the user had a bunch of .fig files and a bunch of scripts and did not know which script had produced which .fig file.

[Image Analyst]

I guess you could run all the fig files and visually match what figures they created with what figures you have in advance. Not automatic but it will get the job done.

[Walter Roberson]

In the question a few years ago, the user had thousands of them (or was it tens of thousands?)

Answer 1

[dpb]

No. Bestest you can do is create a script file that will reproduce the figure from the internal data, but it wouldn't be able to recreate the data itself from some other calculation (obviously?).

Won't help with existing but going forward, if this were to be important and you can modify the creation of these figures, one could add a 'Tag' property value that did contain that information.

[Eli Borodach]

Can I do something like this:

fig = figure;
fig.code_file = sprintf('%s\\code_file_name', str_path);

And than the fig would save the code file which created it?

[dpb]

No, fig is a figure handle, not a structure; what you've shown would destroy the handle and replace it with a structure of the same name.

Note that by "create a script file that will reproduce the figure" I was referring to the "Generate Code" option under the "File" menu on the figure in question.

I was suggesting you could save the requested information of which function/script by use of the mfilename function to retrieve the function name while it was running and creating the figure to imbed that data in the 'Tag' property of the figure as part of generating it. It could then be recalled from the .fig file at a later time. Of course, nothing would say that that function would still be around and unchanged since the generation time and the (future) query from the .fig file and, if the file were moved to another system without the (assumed) user-written function available, all you'd have is documentation of which file it was, not the file itself.

You'd need to create a hyper-object containing both the figure and the m-file itself to have both, and then that m-file would need its input data also, and so on and so on...which leads to the conclusion (also obvious?) that the thing that's key is the m-file that generated the figure to begin with (along with its supporting data) instead of the figure itself.

[Walter Roberson]

I would not use the Tag property, as GUIDE relies heavily on Tag. I would suggest UserData or AppData

[dpb]

Guess that'd be true if they use a GUI, indeed...seemingly a case where a later developer wish/need came in and usurped an existing facility thereby making it less or unusable for the original purpose in all cases? Since I "don't do windows" I didn't think of that possible collision, granted.

I did wonder while writing the above (but didn't test) whether the 'UserData' could be a cellstr array which could conceivably then hold the m-file content. Not that I'd recommend it; I'd use some other archival mechanism instead, but...altho it could always be converted to an array of char() so appears would be possible.