Inconsistent Return String from WinRecreation

Share icon

I am a bit confused by why WinRecreation generates two different code sequences to capture a graph. Here are the openings to the two different sequences.

Window Ba_IBAW_plot() : Graph
	PauseUpdate; Silent 1		// building window...
	String fldrSav0= GetDataFolder(1)
	SetDataFolder root:Ba_IBAW:
	Display /W=(56,385,585,885) theta vs tau as "Plot for Ba_IBAW"
	AppendToGraph :::Ba_IBAW:Ba_IBAW_results:fitvH,:::Ba_IBAW:Ba_IBAW_results:fitpl
	SetDataFolder fldrSav0
Window Cr3O4_IBAW_plot() : Graph
	PauseUpdate; Silent 1		// building window...
	Display /W=(41,253,578,753) :Cr3O4_IBAW:theta vs :Cr3O4_IBAW:tau as "Plot for Cr3O4_IBAW"
	AppendToGraph :Cr3O4_IBAW:Cr3O4_IBAW_results:fitvH,:Cr3O4_IBAW:Cr3O4_IBAW_results:fitLa,:Cr3O4_IBAW:Cr3O4_IBAW_results:fitIs

In the first case, the recreation moves into the source folder before Display. In the second case, the Display step references the files inside their source folder from root:.

I am creating the WinRecreation string using the method below.

	SetDataFolder root:
	DoUpdate // assure that all is updated (based on current data folder setting)
	wrec = WinRecreation(rgraph,0)

What is most confusing is that I can consistently obtain the second format for WinRecreation for two different starting folders (Cr3O4_IBAW and Fe2O3_IBAW). But I always obtain the first format when I start with the Ba_IBAW folder (and even renaming it to Ba3bbb_IBAW).

Am I missing a step to force a consistent code sequence approach from WinRecreation? Is it perhaps due to appending two waves in the first case but three in the second?

IP 9.06B01 (Build 56648), macOS 15.7.4

EDIT: Yes!!! It appears to depend on how many additional waves are appended to the graph. I redid a graph from Ba_IBAW with three appended waves instead of two. The WinRecreation string became as below.

Window Ba_IBAW_plot() : Graph
	PauseUpdate; Silent 1		// building window...
	Display /W=(65,376,594,876) :Ba_IBAW:theta vs :Ba_IBAW:tau as "Plot for Ba_IBAW"
	AppendToGraph :Ba_IBAW:Ba_IBAW_results:fitvH,:Ba_IBAW:Ba_IBAW_results:fitLa,:Ba_IBAW:Ba_IBAW_results:fitIs

The question remains ... Outside of appending a dummy wave (and removing it later), can WinRecreation be forced to return a string that takes a consistent approach in referencing the waves on the graph?

The answer to the question is most likely no.

I looked up the code that generates the SetDataFolder command, and it was to complex for me to understand without quite a bit of effort. So I asked Claude... Apparently whatever data folder has the largest number of waves will become the "common" data folder that SetDataFolder refers to. If it's root, then no SetDataFolder is needed. If two folders have the same number of waves, the first one encountered "wins". That is the origin of your 3-wave observation, and counting on 3 waves as the answer is not actually what happens. The addition of another wave from `:Ba_IBAW:Ba_IBAW_results:` causes that folder to have more waves than `:Ba_IBAW:` and moves the "common" folder to that folder.

The complexity of that algorithm is the reason that I say "most likely no."

The idea here is that partial paths make shorter commands than full paths. For a very long time, we have tried to keep command length minimal. That attitude is fading some, but it is still a consideration.

May 4, 2026 at 11:47 am - Permalink

Thanks. I figured as much.

For further background, I am creating a routine to work through about a dozen or so data sets. I use a graph with a control bar to set parameters for curve fitting. I generate the WinRec string just before I close a graph. I pull out the control bar code portions and reconstruct everything back to create the WinRec for a "clean" graph.

In the meantime, I decided to generate the clean graphs manually rather than parsing out the "dirty" portions of the WinRec (which is probably what Claude would also recommend in my case :-))

May 4, 2026 at 01:51 pm - Permalink

I'd considered this. However, I am now on the path of hard-coding the graph commands and using if-then-else-endif constructions to handle variations in what exists to be appended. The hard-coding was surprisingly easier than I thought and will likely be more robust in the long term.

May 6, 2026 at 10:25 am - Permalink