Where is the recreation macro saved? Could it be changed (unintentionally?)
Fri, 06/05/2020 - 06:51 pm
Since Igor 3, I believed that the recreation macro for a graph generated either by 1) closing the graph window (and choosing "Save" or "Replace"), 2) Windows > Control > Window Control > Update Window Macro, or 3) DoWindow /R was automatically saved in the Procedure Window.
I have experienced a never-encountered strange behaviour with Igor Pro 8.0.4.2/Windows 10: The recreation macro that I created through any of the methods above was unexpectedly made in a procedure, which was made before, saved as a separate ipf file and automatically loaded from the "Igor Procedures" folder.
A bad thing is when I "update" the graph recreation macro, say graph2, in a new experiment that I was working, it replaced (i.e., overwrote) the original graph2 macro in this separate ipf file with the one for the graph2 that I was handling.
The question is 1) is there any way to explicitly change the target procedure file where the recreation macro is saved? and 2) would there be a possibility that this destination procedure is unintentionally changed to a separate ipf file by chance or by unallowed manipulation?
I am sure that if 2) could happen under a specific situation, this would be a severe bug. Did I do anything wrong that might have allowed Igor to behave like this? I am sorry I cannot identify the situation where I can reproduce this phenomenon. I wish you check if there's such possibility.
Thank you!
Fusao Kato
Hmm, I haven't tested this, but I would suspect that the graph recreation macro function searches in the procedure window and any open procedure file for a macro with the same name. If it finds the graph macro somewhere and you 'update' the macro it overwrites its contents, wherever they may be. The macros are usually saved with the graph name as function title unless you specify otherwise. If you have graph macros in a separate file with you would like to keep safe from overwriting, make sure they are named differently than any normal graph name, so you cannot accidentally 'update' them.
If you instead want to point out that the recreation macro is somehow created in an external file instead of the internal procedure window, then I have no idea. I have never seen such behavior. Do you have simple steps for reproducing this strange behavior and/or a minimal experiment file to share?
June 5, 2020 at 08:25 pm - Permalink
I am not sure I understand the bug here. This seems to me expected behavior - or I may have misunderstand the description. If graph was created using macro "Graph2" from some ipf file and then you use any of the above methods to "replace" it, macro in that ipf file will be replaced. If you create graph with name same as existing graph macro, it will be associated with that also and replaced if you generate new macro with that name - in the ipf file, where the original is. If there is no macro with the same name (Graph2), new macro will be created in main Procedure file.
To create a new macro for that graph, you need to verify the name is available and if needed, rename that - ctrl-Y open GUI to do that - and then create a new Window macro.
You cannot have two macros with the same name (well, it can get complicated).
There should be protection in the fact, that normal users should have procedure files opened as read only by default.
June 7, 2020 at 12:22 pm - Permalink