Hi Christian,
Any news about the bug in FolderItem.TagNamesMBS?
I think you ask about the thread FolderItem.TagNamesMBS strips out EndOfLines thread.
So I tried it here:
Var f As FolderItem=SpecialFolder.Desktop.Child("test.txt")
Dim b As BinaryStream = BinaryStream.Create(f, True)
b.Close
Var BeforeTags() As String=f.TagNamesMBS
Dim BeforeFinderLabel As Integer = f.FinderLabelMBS
Var status As Integer=f.SetTagNamesMBS(Array("Test"+Encodings.UTF8.Chr(10)+"3"))
Var AfterTags() As String=f.TagNamesMBS
Dim AfterFinderLabel As Integer = f.FinderLabelMBS
Break
and in debugger I see:
Everything seems to work as documented. The label is set, the color shows in Finder (violet here). When we query it, we get back “test” as tag name and 3 as finder label color.
The trick to pass in the text with Chr(10) and number is not documented in Apple documentation. and you can’t expect reading TagNamesMBS to return you that number.
Thanks for your answer and for trying.
It almost completely fits my needs, except my original issue is to have one color per tag (a file can have several colors at once).
In AfterTags, do you still see the Chr(10)+“3”?
Just wanted to be sure that there was no bug in the plugin that could mistakenly remove the chr(10). If not, then the bug is in Apple’s API (regardless of the fact that it’s documented or not).
I know you can add multiple tags with each a color via Finder. But the thing about passing two lines there is something I don’t even find in the documentation from Apple.
No. This API by definition should only return the tags as documented by Apple.
The plugin doesn’t remove a second line. We pass through text as it is.
Ah, I see. It looks like their API is at fault (i.e. setting the tag supports one color per tag, but getting back only supports tags). I’ll keep my current workaround (which is a table of colors for each known names).
Thanks a lot for these explanations.
Arnaud
I noticed the same problem with my app. My workaround is to include the same colour number twice - once before the Chr(10) and once after.
For the number before the chr(10) I have used a lookup using hidden unicode characters - this seems to be returned OK by Apple (at the moment) and a reverse lookup allows me to find the tag’s colour. This means the numbers aren’t visible in the tag name in Finder, but my app can still read them.
Thanks for your reply, James.
Your trick seems reasonable, but how does the user search for the tag then?
Oh, well normal text goes in before the hidden text - so Spotlight can search for it easily.
1 Like