Identifying the source (matrix) wave from a contour trace name

How about ContourInfo? The output includes keywords for each of the three waves that might or might not be present on your graph.

Also, can you expand on "But the name gets truncated to 17 characters anyway." What is truncating to 17 characters? Surely not Igor- there has never been a time when a name would be truncated to 17 characters.

Hi Chozo,

I think you are a bit confused between wavename and tracename (including trace, image, and contour). Very often, with a relatively short wave name, this tracename string happens to be the same as wavename.

In order to figure out the underlying wave of an object in a graph (again either trace, image, and/or contour), you first use the corresponding XXNameList function (TraceNameList, ImageNameList, ContourNameList). From this list, get the tracename of the object you want using StringFromList function. Using this name, call the corresponding XXNameToWaveRef function (TraceNameToWaveRef, ImageNameToWaveRef, ContourNameToWaveRef) to get the wave reference to that underlying wave. Finally, call GetWavesDataFolder function to get the full name or partial name of the underlying wave, depending on the parameter fed to the function.

John, thanks for your message. But here is the thing: ContourInfo() requests the source wave name as input and then ... tells me the source wave name (via the ZWAVE key). So this is kind of moot. Also, you will see this for TRACESFORMAT: "%.17s=%g", so truncation to 17 characters (but I assume this depends on the string length of the levels indicators). As far as I can see, there is no function or operation which does 'contour trace/wave name' => 'source wave name', which was very surprising to me. I can maybe do 'source wave name' => 'contour trace/wave name' using the stuff ContourInfo() gives me, but not the other way around.

@BuntCake: No, I am not confused. It is likely that you have not realized that contour traces are constructed a bit differently. Namely, contour traces are constructed from special waves which are hidden to the user, and do not directly reference back to the source wave (at least not in an accessible way to us). I don't want access to these internal waves for each contour trace. Instead I want to refer back to the source given a single contour trace name. Yes, I know the trace name is in some way constructed from the source wave name, but this is the reason I wrote about long wave names, since the contour trace name has its limits.

When you append the contour traces to your plot, you can specify the format using the /F flag, e.g.

which should guarantee unique contour trace names, but that won't help if that flag wasn't used when making the graph. 

If you append MyLongNamesSourceWaveA and then MyLongNamesSourceWaveB, the contour trace names would be 'MyLongNamesSource=100' and 'MyLongNamesSource=100'#1, so maybe you could hack it by getting the list of contours and then using the trace instance to determine which contour the trace goes with?  The code below seems to work, but I'm not sure it's 100% reliable.  If the user does something crazy like reordering the contour traces then all bets are off.  

Adding a function to do this, or maybe easier, adding a field to TraceInfo if the trace type is 1, seems like a useful addition.  With longer names now allowed, it would also be nice if the default trace name format was longer than %0.17s.  

Thanks! Yes, this is probably the best idea in lack of a direct (official) conversion method. The instance should indeed indicate the order in which the source wave appears in CountourNameList(). Here is what I have in my code now (I really like to use regex lately):

@chozo, that's really nice code, and way more elegant than what I came up with!  I'm glad my suggestion was helpful.  When I tested your code, tracebase still had a leading single quote that needs to be removed.  Maybe this would work:

Yes, I think my issue is solved thanks to your idea. Note that ContourNameList() reports the names including single quotes, so parsing this is actually intended. Your SplitString command is of course good for other things like constructing custom wave names out of the input contour trace.

@chozo I misunderstood your original posting, clearly. Now that we have a solution, can you let us know what you are trying to accomplish? Altering the appearance of contour traces can be a frustrating experience- the contour itself tends to wipe out customizations.

John, thank you for offering your help. You were not the only one who misunderstood my post. But I couldn't think of a way to explain myself better. Anyway, my reasons are very simple: I want to offer all and everything Quick Fit can do in my Super Quick Fit package, so that there is no reason not to use it. :) For this I need a way to construct the fit call when someone clicks on a contour trace. Even if nobody uses this in the end, it has been certainly a learning experience.

Ah- apparently another way around this would be if we had a way to tell you which contour plot you clicked on. But I have a funny feeling that TraceInfo() might have the info you need in Igor 10.

Aha! Would be really great if your funny feeling turns out to be right. (Still, I will likely be supporting the old way of doing things for a while until this mysterious Igor 10 I keep hearing about will materialize for the masses, i.e., my users. ;-)