Error with SetDataFolder while starting up

Share icon

Hi all,
I received a new error this morning while opening an experiment. The diagnostic notebook is below. My data seems intact, although I had to reopen procedures/notebooks and the default notebook appears to be lost. To be safe, I saved the 'recovered' experiment under a new name. The default notebook only had a few lists in it but I would prefer not to recreate it, if possible. Is there some way to get around this error? It looks like it might be trying to switch to a free data folder at start up? Which I thought were saved in packed experiments...? But might get a new address during start up?



*** Igor was unable to fully recreate the experiment. ***
This notebook contains diagnostics to help you understand the problem.
You can kill this notebook when you no longer need the diagnostics.

IMPORTANT:
Some waves, procedures or other data were not loaded into the current experiment.
Therefore, if you save the current experiment DO NOT OVERWRITE any existing files.
It is OK to save the experiment. Just use a new name for the file.

While executing the restart procedures the following error occurred: ill-formed name.

The command being executed was:
>> SetDataFolder 0x688E3FB0:


For reference, here are the complete experiment restart procedures:
// Platform=WindowsNT, IGORVersion=6.222, architecture=Intel
Silent 101 // use | as bitwise or -- not comment.
NewPath/Z data "::"
NewPath/Z WaveMetrics "C:"


SetDataFolder 0x688E3FB0:

DefaultFont "Arial"
MoveWindow/C 6.75,413,1026.75,687.5
OpenNotebook/N=Notebook0/W=(414,56.75,1019.25,523.25)/J=1200899422 "Notebook0"
MoveWindow/P 211.5,143.75,765.75,658.25
That's very strange and clearly a bug in Igor. I'm not sure why Igor generated a SetDataFolder command at that point at all and even less sure of why it has a bogus parameter.

It must have been caused by something about the state of the experiment when you saved it.

First, when this error occurs, you should be able to comment the line out in the error dialog and continue loading the experiment. To read about this, execute:
DisplayHelpTopic "Errors During Experiment Load"


Whether it works or not, it would be good if you could send the experiment (zipped) to WaveMetrics support so I can see if there are any clues. I can also probably recover your notebook if you can not. Also please let me know if you have any clue as to what might have caused this.

September 8, 2011 at 01:42 pm - Permalink

Excellent, thank you! I hadn't thought to simply comment it out in the dialog and retry. I was able to successfully open my experiment, including notebooks.

I'm learning to use free data folders right now but I generally forget to return users to their original data folder. If a function which set the current DF to a free DF returns without setting the current DF back to a 'real' DF and I save at this point, would it cause this behavior? I couldn't come up with a more plausible explanation.

As for sending it to WaveMetrics support, the experiment is >1Gb since it has ~11 days of 10hz data. Compressed as .zip it is 120Mb. Is there an alternative to submitting it by email?

September 8, 2011 at 04:19 pm - Permalink

Quote:
If a function which set the current DF to a free DF returns without setting the current DF back to a 'real' DF and I save at this point, would it cause this behavior?


It's possible. We will investigate.

Quote:
As for sending it to WaveMetrics support, the experiment is >1Gb since it has ~11 days of 10hz data. Compressed as .zip it is 120Mb. Is there an alternative to submitting it by email?


OK. Don't bother. I think we can figure it out based on the information you provided.

September 8, 2011 at 06:12 pm - Permalink

Ok, I've been a little more observant. Last night I hit a run-time error while in a free data folder and after closing the debugger, noticed a similar hexadecimal address displayed in the CDF field of the data browser. Maybe the error is required.

Thanks again for the help.

September 9, 2011 at 10:10 am - Permalink

The hexadecimal address references a free data folder.

It is possible for a free data folder to be the current data folder.

I thought that the current data folder should never be a free data folder outside of a user-defined function but experimentation shows that I am wrong about that. Our expert on data folders is out of the office so I can't get straightened out right now.

It is possible to store a DFREF for a free data folder in a DFREF wave. This would cause the free data folder to not be killed because something is referencing it.

September 9, 2011 at 11:55 am - Permalink