In you "non-working" example, I'm pretty sure sprintf is spitting out a single string with an embedded escaped comma. line~ doesn't know what to do with embedded escaped commas.
In the second example, [prepend set] receives a message with an embedded, escaped comma and does it's thing, sending a set message with an atom list including an embedded, escaped comma to your message box. The message box interprets the set message (including the embedded, escaped you-know-what), to set its content and then recieves a bang to pass its content on. It is at this point--and not one picosecond sooner--that Max message parsing kicks in, the comma (now un-escaped) signals end-of-message/new-message-begin and you get the expected behavior.
Why you go through the palaver with sprintf when you could just do the following escapes me
As Olivier is reputed to have said, it's much easier…
The Max clip you included is very instructive about one point that occasionally comes up on this list/forum:
Everyone look carefully at how Max escapes the comma in order to make sure you'll get the sprintf arguments you want. A triple-escape! One backslash to escape the backslash character, another to escape the comma.
>Why you go through the palaver with sprintf when you could just do the following escapes me
Well... in the real patch my example was taken from, the two times come from different sources, and message boxes don't lend themselves to that as well.
I'd like to thank everyone who chimed in on this thread. I particularly like Volker's suggestion, earlier in the thread, of just using "0 0" instead of "0," in my sprintf format string. I had a forehead slapping moment with that one.
Chris Muir | "There are many futures and only one status quo.
email@example.com | This is why conservatives mostly agree,