>> So I was thinking that .toString() should be kept as is for
>> simple debugging purposes, but that calling .toSource()
>> on an AEDesc should return a complete hex dump.

>The problem here is that I'm using the system's AEPrint calls,
>and somewhere along the way Apple decided to truncate long
>hex strings (happens with aliases as well). I've filed a bug with
>Apple on this, but its pretty low on their priority list.

Thanks, Mark.

I've been reading into this. It looks like when Apple "took over"
the "AEGizmo" code stuff that they never intended for their
version to produce "reversable" AEPrint strings that could
subsequently be used for building.

It is interesting that I found this in the OSX 10.1 tech note
(tn2029):

Hex data output by AEPrintDescToHandle was being
truncated at 32 bytes. This limit has been removed - hex
data is no longer truncated (r. 2672759).

It kind of sounds like they "fixed" it once, then "broke" it
again later. ;-)


>I think its a combination of things:

>1) chicken-and-eng: no easy way to distribute scripts that use JSOSA
>requires the user to install JSOSA

Yeah. Probably a silly and overly-ambitious question, but could there
ever be a way for a script application-bundle to carry and use the
JSOSA component in the same way that they can contain their own
scripting additions?

Of course, this brings up the issue of whether or not you would
allow third-party distribution. I've been working on a "first run"
applet system that would test for and install JSOSA before running
a JSOSA script, but it's buggy and no doubt ill-concieved.

>2) JSOSA isn't enough better than AS to justify the effort - AS works for
>most people

It really really really really really really is better. :)

Again, thank you for creating it. :)

I'm working on some projects, such as Clippings files listing common
JavaScript snippits, etc. As soon as I can get organized, I'll starting
posting some of my stuff to my new website, and I'll drop a note
here.

-- Arthur