Ensuring unique trace names

I'm setting up procedures that automatically plot certain waves in each of several nested data folders. I'm using the /TN command to ensure that I can modify each trace individually, despite the fact that they will all have the same wave name.

    string yN=ywaven+foldername+subfoldername
    appendtograph /W=$chartname /L=$ywaven ywave /TN=$yN vs xwave
    modifygraph /W=$chartname rgb($yN) = (red,green,blue)


If yN happens to exist already due to plotting vs a different x-wave in a previous call, or because yN exceeds string limits, I understand that Igor will use instance notation to change the trace name from whatever yN is to "yN"#1.

Is there a way for me to know that the trace name has been modified with instance notification so that the last line modifies the trace I just appended instead of the first instance named yN?

I experimented with using the uniquename function, but I don't think there is an object type that works for traces.
I used checkname(tracename,15) for both an existing and non-existent trace name on the graph in question, and both returned -1.
Thanks! I agree, that's the way to do it, if there's not a more direct route.

I had started to write a function to run a for-endfor loop to check (and modify) the proposed trace name vs all the elements in TraceNameList, but thought that there might be a more elegant way to do so via a built-in function.

It's also worth noting that if you're using a procedure to create trace names, you need to be aware of the maximum allowable length for a trace name. When I execute this code:
function maketracename()
wave ywave
display
string tn="a000000000000000000000000000001"
appendtograph ywave /TN=$tn
       tn="a000000000000000000000000000000000001"
appendtograph ywave /TN=$tn
       tn="a000000000000000000000000000000000000000000000000000000000001"
appendtograph ywave /TN=$tn
print tracenamelist("",";",1)
end

the output from the  print tracenamelist command is the following:
  a000000000000000000000000000001;a000000000000000000000000000000;a000000000000000000000000000000#1;

Applying strlen() to each of the entries in the tracenamelist output shows an output of 31, 31, and 33: this suggests that the maximum length that you can use for a trace name request is 31 bytes, but Igor can add the "#1", "#2", etc. to the end of an identical trace name to differentiate between them and will store that difference.

Understanding that difference is important to proper handling of automatically generated trace names.
I think If (StringMatch(TraceNameList(graphNameStr, separatorStr, optionsFlag ), "*"+matchStr+"*" )) is rather elegant if it's not invoked too often.

In your example, even quotes for liberal names, e.g. '1st trace', do not work. That's an interesting point. I assumed that the #n versions just use liberal names. But obviously it works in a different way.

HJ
You can try to use the hash function with the sha-256 algorithm (displayhelptopic "hash").

So you would be generating the name strings: string trace_name = name_prefix + num2str(number)

then hashing this string:  string trace_name_hash = hash(trace_name , 1)

and hoping for no collisions (your uniqueness requirement) on the hash function. The last statement can be pretty reasonable for any meaningful set of objects to be hashed.

Good luck.

[edit] of course, you would have to keep track of which trace_name corresponds to which trace_name_hash in a separate text wave.
I would tackle the problem from a different side.

Set every trace to something unique via "T1, T2, ..." and then add some metadata using the userData keyword of ModifyGraph. Using the userData you can then access any trace you want without having to know about its name.
You can use FindListItem or WhichListItem functions to figure out if a given item is already in the list. Checking every time you add a new trace may make it work pretty slowly if you have hundreds of traces. Using the built-in functions to check if the name is already in the list will be faster because it uses built-in code, but can still be slow.

John Weeks
WaveMetrics, Inc.
support@wavemetrics.com