Experiment Recreation Procedures

Share icon

Hi all,

I was just wondering if there is any way to intercept the experiment recreation procedures. My problem is that I'm trying to create a function to automatically update paths in old experiments when the experiment is opened. This should avoid all the dialogues asking for the new path, but the AfterFileOpenHook isn't called until after the experiment recreation procedures.

Ideally I'd be able to put this function into the experiment recreation procedures(?)
My other option, I guess, is to delete paths before saving, using the BeforeSaveHook, but then how to recreate the paths after the save is complete? I could save the paths as strings, but how does the system know when a save has just been completed?

May 26, 2009 at 11:40 pm - Permalink

I'd need to know more about the problem you are addressing to provide an informed answer.

Note that when an experiment is recreated, Igor does not ask to find a symbolic path which is not needed to recreate the experiment. If the term "symbolic path" is not familiar to you, execute this:

DisplayHelpTopic "Symbolic Paths"

May 27, 2009 at 07:54 pm - Permalink

This is something that I have wondered about as well. Here is the problem I have run into:

All of the Igor code that I use in the lab (and that my lab colleagues use) is stored in a Subversion repository. When I first set this up, I was new to Subversion and fairly new to Igor, and things were not set up optimally. So my directory structure looks something like this:

Subversion Working Copy --Acquisition ----trunk ----branches ----tags --Analysis ----trunk ----branches ------branch1 ----tags

A shortcut to Subversion Working Copy is in my Igor User Procedures directory so that I can easily include any procedure file within that directory. To start a new analysis, I create a new experiment, load a single procedure file in the Analysis/trunk directory, and compiled. This single procedure file then included all of the other necessary procedure files, most of which were in the same Analysis/trunk directory.

After having created maybe 100 experiments, I decided to branch the Analysis portion of my code (thus creating the branch1 directory shown above). At this time, I used the svn switch command to make is so that the contents of the branch1 directory were now directly within the Analysis directory. So when I loaded all of the experiments I had already created, Igor freaked out and I had to manually set the real directory target of one of the paths from Subversion Working Copy/Analysis/trunk to be Subversion Working Copy/Analysis. Now, in the future, if I decide I want to go back to using the old version of my code for analysis, I just need to quit Igor and use svn switch to switch my Analysis directory to contain the contents of Analysis/trunk. But it was pretty laborious to manually select the new directory in each of those 100 experiments, and it would have been great if there was some way to do this automatically.

May 28, 2009 at 04:21 am - Permalink

I did not follow all the in's and out's but I get the gist of the issue - you have moved some procedure files and Igor is asking where they are.

I think the problem occurred because you explicitly opened some of the files (using File->Open->Procedure file or equivalently by double-clicking the file) rather than #including them.

If you do #include "file", Igor searches for the file in the User Procedures folder and recursively in any subfolders and in any folders referenced by aliases/shortcuts in User Procedures. Thus, if you move a #included file, it will still be found so long as it is in one of those folders.

On the other hand, if you explicitly open a procedure file, Igor creates a symbolic path for it and remembers its location relative to the folder referenced by the symbolic path. If you move the folder, Igor will ask where it went when it tries to recreate the symbolic path.

Since symbolic paths are stored on a per-experiment basis, you might have the same symbolic path in 100 different experiments, all of which will need to ask you where the folder went.

There is no easy way to fix this latter situation. The solution is to avoid it by using #include. However, it is rather easy to create the situation - by merely double-clicking the file and saving the experiment.

In an unpacked experiment, you can open the experiment file as a notebook and edit it. You can't do this in a packed experiment. You may find examining the recreation procedures in an unpacked experiment file (.uxp) instructive.

Note however, that if you open an unpacked experiment file as a notebook, Igor will henceforth open it as a notebook when you double-click it until you change Igor's notion of how you want to open it using File->Open Experiment.

May 30, 2009 at 06:58 pm - Permalink

hrodstein wrote:

I think the problem occurred because you explicitly opened some of the files (using File->Open->Procedure file or equivalently by double-clicking the file) rather than #including them.


Yes, in my case at least I would have explicitly opened at least one file, the main procedure file. This main procedure file then includes the rest of the necessary procedure files and also provides some macros and menu items that make the code easier to use by the user.

Based on what you said, it seems that you are saying that the ideal way to do this would have been not to explicitly open the main procedure file, but to instead type into the procedure window of a blank experiment #include "MainProcedureFile". The downside to this is that I either have to type this in for every new experiment, or keep that text somewhere and copy/paste it in. That's less user friendly then just opening the procedure file and then compiling.

I suppose I could create a new experiment, add this #include line, and then save the experiment. Then, to analyze new data, I could open that experiment and immediately re-save the file under a new name.

May 31, 2009 at 07:08 am - Permalink

aclight wrote:
Yes, in my case at least I would have explicitly opened at least one file, the main procedure file. This main procedure file then includes the rest of the necessary procedure files and also provides some macros and menu items that make the code easier to use by the user.


Possibly the right thing for you would have been to put a shortcut for your main procedure file in Igor Procedures. This would cause your procedures to always be loaded but not referenced from any experiment.

aclight wrote:
Based on what you said, it seems that you are saying that the ideal way to do this would have been not to explicitly open the main procedure file, but to instead type into the procedure window of a blank experiment #include "MainProcedureFile". The downside to this is that I either have to type this in for every new experiment, or keep that text somewhere and copy/paste it in.


Another possibility would be to create a template experiment containing that #include.

Given that you wound up with a lot of experiments referencing a missing procedure file, I can think of some ways to ease your pain.

1. Have Igor automatically search for missing procedure files.

2. Have Igor keep track of where missing procedures were located and reuse that information later.

June 1, 2009 at 07:22 pm - Permalink

hrodstein wrote:


Given that you wound up with a lot of experiments referencing a missing procedure file, I can think of some ways to ease your pain.

1. Have Igor automatically search for missing procedure files.

2. Have Igor keep track of where missing procedures were located and reuse that information later.


Unfortunately, we send out a group of folders containing a lot of different procedure files. Which one the user will open will depend on how they're using our package. But when we update our "group of folders," a new group is created, and its location is not related to the old, so Igor can't find them.

I'm thinking the best way to do it is to save all paths to strings, then kill all paths, then save the experiment, then remake the paths. When the experiment is opened, the correct paths are there anyway, so they don't need to be saved with the exp.

Does that sound fair enough?

June 2, 2009 at 09:03 pm - Permalink

I'm having a hard time understanding what you are doing.

Bones wrote:
But when we update our "group of folders," a new group is created, and its location is not related to the old, so Igor can't find them.


Why? Are you using version numbers in the folder names?

Bones wrote:
I'm thinking the best way to do it is to save all paths to strings, then kill all paths, then save the experiment, then remake the paths. When the experiment is opened, the correct paths are there anyway, so they don't need to be saved with the exp.


I'm not sure what you mean by "paths". Symbolic paths? If so, this seems to defeat the purpose of the symbolic path which is to have something the user can find once instead of once for each file loaded relative to that path.

It might be best if you explained again in a bit more detail what you are trying to do.

June 3, 2009 at 05:57 pm - Permalink