solved the problem by sending variables to the [seek $1( message in the [unauthorized/playlist] object and feeding that to the [open $1( of [pix_film]
don't why that works and the other one doesn't though.
bug submitted.
Sofy
On Fri, Mar 18, 2011 at 10:15 PM, Mathieu Bouchard matju@artengine.cawrote:
On Fri, 18 Mar 2011, sonia yuditskaya wrote:
[time]
[][-2][] [set open $1.mov(
I don't know what you mean when you write [][-2][].
and pipe that to pix_film, but pix_film tells me:
error: [pix_filmDarwin]: unable to find file: ÿAK I can see its a type casting issue but from what to what?
I first thought that there might be a bug with printing the error message, because I found that Gem has one or more similar bugs. Inside of the source code of [pix_filmDarwin] the error message above is printed by this command :
error("unable to find file: %#s", theFSSpec.name);
But when looking at the programming manual of MacOSX 10.4 for what %#s means, it says that %#s has no meaning ("#" would mean nothing when used together with "s").
So, I don't know what %#s is supposed to be doing there, and whether it means that theFSSpec.name is printed in the console in the wrong way or what.
I know that in some places, Gem does (or used to do) :
error("blahblah: %s", name);
instead of :
error("blahblah: %*s", *name, name+1);
and that it caused weird stuff to appear in the console when I got those errors, but it's normally a lot less garbled than what you've got : I could really see the filename, prefixed by one unwanted character, and suffixed by possibly a bunch of unwanted characters.
However, when I look at what theFSSpec.name is supposed to be in the error message, it looks like it's part of the same problem.
You could write that in Gem's bug tracker, with the title : « Gem tries to print Str63 and/or Str255 as if they were ordinary C Strings » and then write that one example of this bug is in "Unable to find file".
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC