Thank you for this helpful report.
Strangely, it seem that this issue is effectively Mac related : i can confirm it also occurred on my Mac OS X 10.8.5 with PDF files and FileMaker 12.0v4, but the same files and database worked fine on my Windows 7 virtual environment.
Obviously, I couldn't test the "?" named file on Windows, since it isn't allowed on this platform, but both "#" and ";" named files references worked successfully.
Thank you for your post.
I was aware of this issue being Mac related. Do you think there is a workaround by changing something in the way the Macs "reserve" some characters?
I would say "occurs only on Mac FileMaker versions". Hard to believe Mac OS X is the culprit in this particular case.
I don't imagine a workaround, except prevent this error by testing your field searching an occurrence of incriminated chars and abort insertion if any, with a custom dialog box to inform enduser.
Thank you again for your post.
The custom dialog informing the user is already in place.
The problem is, this method of storing audio files is used in a search engine for sound effects (http://soundtraceapp.com). Many sound effects libraries come with "#" symbol in the filename to differentiate variations of the same sound (ex: water sound #1.wav, water sound #2.wav).
So, unless there is a solution for this, the app is really compromised.
Are theses files frequently modified ?
Because the other ""workaround"" is to store them in the database (internally or externally)…
Although it sounds like a good workaround, that is not an option for this app.
The importing sound libraries process is really fast (it uses external technologies to get the file paths and filenames). If one sound library had 5000 records, and all with a "#", ";" or "?" in the filename or file path, it would take too much time to import (and the user would just give up the app).
But anyway, thank you for your suggestions. I guess my best option is getting FileMaker looking at this and correcting it.
Knock, knock... Are your still alive?
I maybe have a workaround... but It is a bit heavy... and it only works on form view.
1. Create a global field to temporary store the file on the database
2. Create the workaround script to insert the file referenced on the global field
3. Place the local field outside the layout width boudary (on the right)
4. Place the global field on the layout
5. Modify your existing insertion and deletion scripts and adapt them for this new configuration if needed
6. Invoke your workaround script when needed like for instance : from your insertion script, and OnRecordLoad trigger
And now, see how the script looks like (to be refined) :
Set Variable [ $Path; Value: GetValue ( Edgar::LocalField ; 2 ) ]Go to Field [ Edgar::GlobalField ]Insert Audio/Video [ “$Path” ]
Now i'm tired. I go to the siesta...
Because this is a "display" bug.
The reference is stored correctly.
Just cannot be rendered with the interactive container.
I am doing nightmares...
The problem is exactly the same with FMP WebViewers with the urls like :
"file:///Users/fred/Desktop/Test_%23.pdf" (for "Test_#.pdf")
Works fine on Windows, not on a Mac, even the exactly same url works fine on Safari...
Bye (it is now true), Fred
Hum, just reedited the script on previous post because first version contained just absurd steps...