I've been using a text file containing every jsosa object,
method, and property that I am aware of; as an "aid to
memory". It doesn't explain what things do, but it helps
to have such a listing to remind one of the available
aspects of the language. It has been updated to include
the changes made in version 2.0. Just thought someone
else might find this useful.

-- Arthur

I've figured something out, and wanted to share:

SD has a preference setting for "path to me", causing
that AppleScript command to refer to the document
file itself during debugging, so that it will mimic
its applet/droplet behavior. Unfortunately, this
has never been honored for JSOSA:

	 Core.me;
		 //
		 //=> "/Applications/Script Debugger 4/Script Debugger 4.app"

	 MacOS.pathToMe();
		 //
		 //=> new MacOS.FileSpec("/Applications/Script Debugger 4/Script
Debugger 4.app")

	 MacOS.appSelf()._file;
		 //
		 //=> new MacOS.FileSpec("/Applications/Script Debugger 4/Script
Debugger 4.app")

	 Note: "._file" replaced the "._path" getter for AEApp
	       instances in version 2.0.

The key is to make sure you are sending yourself
the actual "path to" AppleEvent, with a "null"
direct parameter:

	 Me = MacOS.appSelf();
	 Me.__defineGetter__( 'fspec',
		 function() {
			 var ae = new MacOS.AEDesc();
			 ae.build( "'null'()" );
			 return this.sendAE( 'ears', 'ffdr', ae );
		 }
	 );

	 Me.fspec;
		 //
		 //=> new MacOS.FileSpec("/Users/arthur/Desktop/blah.scpt")

OK, goodnight all.

-- Arthur

>> 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

Hi,

> When the .toString() or .toSource() method is used on an AEDesc value, the
> string data
> returned is truncated with an ellipsis, as in:
>
> Me.the_clipboard( 'ustl' ).toString(); // when styled unicode is on the
> clipboard
>     //
>     //=>
> "ustl($000000020000008C000000000000001400000020000000010000000100000000\
> xC9$)\x00"
>
> where \xC9 is the MacRoman ellipsis character. The hex codes are cut off after
> the 32nd
> byte. This is problematic, both in that it means the value cannot be reused
> with the .build()
> method of AEDescs, and in that a scripter can't work with the data in any
> other way, ie: I
> tried using the .as() method to get at the data in other ways, but without
> success.
>
> 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.

> P.S. Am I the only one who is shocked that JSOSA hasn't caught on more in the
> Mac
> scripting community??? It's such a brilliant language, and Mark's integration
> with OSA is so
> brilliantly done. So why aren't more people using it???

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
2) JSOSA isn't enough better than AS to justify the effort - AS works for
most people
3) JavaScript is for the Web in people's minds

Cheers
-Mark

------------------------------------------------------------------------
Mark Alldritt                      Late Night Software Ltd.
Phone: 250-380-1725                Script Debugger 4.0 - AppleScript IDE
WEB:  http://www.latenightsw.com/  FaceSpan 4.3 - AppleScript RAD
                                    Affrus 1.0 - Perl Debugging

Hi, Mark.

When the .toString() or .toSource() method is used on an AEDesc value, the
string data
returned is truncated with an ellipsis, as in:

Me.the_clipboard( 'ustl' ).toString(); // when styled unicode is on the
clipboard
     //
     //=>
"ustl($000000020000008C000000000000001400000020000000010000000100000000\
xC9$)\x00"

where \xC9 is the MacRoman ellipsis character. The hex codes are cut off after
the 32nd
byte. This is problematic, both in that it means the value cannot be reused with
the .build()
method of AEDescs, and in that a scripter can't work with the data in any other
way, ie: I
tried using the .as() method to get at the data in other ways, but without
success.

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.

Just a thought, thanks.

P.S. Am I the only one who is shocked that JSOSA hasn't caught on more in the
Mac
scripting community??? It's such a brilliant language, and Mark's integration
with OSA is so
brilliantly done. So why aren't more people using it???

-- Arthur

> I couldn't find any way of loading script files that's
> analogous to the way they're loaded in web pages. The
> Core.load() function seems to load each separate script
> file as its own object, which, while an excellent idea,
> doesn't mesh well with how script files are loaded in
> all the other environments.
> Is there another way of loading script files in JSOSA,
> in the same inline fashion as web browsers do?

Not built-in, but you can read in a source file and eval()
it, which gives you the same thing, ie: the source file is
evaluated in the same context as the main script:

		 // text file 'jslib.js'
		 //
	 function DoSomething() {
		 MacOS.message( 'Hello World' );
	 }


		 // main script file:
		 //
	 function Include( sourcePath ) {
		 var fileSpec = new MacOS.FileSpec( sourcePath );
		 var sourceCode = MacOS.appSelf().read( fileSpec );
		 return this.eval( sourceCode ); // 'this' needed for top-level context
	 }

	 Include( MacOS.homeFolder.path + '/jslib.js' );

	 DoSomething();


-- Arthur

I'm a Javascript programmer, doing much of my coding at work in a
Windows Script Host environment, writing scripts to accomplish various
repetitive tasks. I also use the same codebase on my home computers,
with a series of cross-platform Javascript libraries designed to work
under WSH, web browsers, and Rhino Javascript for Java. (It's still
very much a work in progress, as you can imagine!) I'm very excited to
see that I can write OS X native Javascript now as well!

I do have a few questions though. Looking through the online
documentation (which is quite helpful, btw), I couldn't find any way
of loading script files that's analogous to the way they're loaded in
web pages. The Core.load() function seems to load each separate script
file as its own object, which, while an excellent idea, doesn't mesh
well with how script files are loaded in all the other environments.
Is there another way of loading script files in JSOSA, in the same
inline fashion as web browsers do?

Thanks, and I look forward to learning more!

> We are pleased to announce the acquisition of FaceSpan 4 from Digital
> Technology International.

ZOMG! :)

Mark, congratulations! This is great news. FaceSpan, in your hands,
will be absolutely fantastic!

Best regards,
- Arthur

Hi Folks,

We are pleased to announce the acquisition of FaceSpan 4 from Digital
Technology International.  FaceSpan is a Rapid Application Development (RAD)
tool based on AppleScript.  Be sure to regularly visit our Web site for the
latest news about our plans for FaceSpan.

Cheers
-Mark

------------------------------------------------------------------------
Mark Alldritt                      Late Night Software Ltd.
Phone: 250-380-1725                Script Debugger 3.0 - AppleScript IDE
WEB:  http://www.latenightsw.com/  Affrus 1.0 - Perl Debugging

On Jun 7, 2005, at 12:02 AM,  Mark Alldritt  wrote:

>> Hi Folks,

Hi Mark, hello everybody,

>> Well, JSOSA 2.0a3 has been out for a couple of weeks now and I'm
>> interested
>> in any feedback you can offer.  Is this an improvement?

a question first (a dumb one I admit): is there a reason not to use
JSOSA when write Automator actions? In other words, is this possible?

>> Are you using it (it was only downloaded 10 times)?

11, as I just found the link you had posted and I was missing...

>> If there are things you want to see in JSOSA2, please let me
>> know.  As it
>> is, I have only 2 open bugs against JSOSA 2.  If I don't hear from
>> you, this
>> will go beta as it is.

It's nice to know that I'll start my experiments on a beta level
thing... ;-)


Cheers,
Aldo

--- In jsosa@yahoogroups.com, Mark Alldritt <alldritt@l...> wrote:
> Hi Folks,
>
> Well, JSOSA 2.0a3 has been out for a couple of weeks now and I'm interested
> in any feedback you can offer.  Is this an improvement?

Yes.  Visibly, there are the new functions which were added, but I'm just as
interested in
the SpiderMonkey upgrade.  If Mozilla is like other open-source projects, I
presume this
fixed a lot of latent bugs.  And since I'm not an OSA expert, I've enough
problems without
bugs in the interpreter as well.

> Are you using it (it was only downloaded 10 times)?

Only occasionally, but yes.  I guess I fit the classic customer profile of
someone who
already knows JavaScript and is too lazy to learn AppleScript.  I still use the
UNIX tools
more often, but pull out JSOSA when I need to use a Mac-native app.

> If there are things you want to see in JSOSA2, please let me know.  As it
> is, I have only 2 open bugs against JSOSA 2.  If I don't hear from you, this
> will go beta as it is.

Personally, I haven't found any regressions, so this looks like a good idea.

> Hi Folks,
>
> Well, JSOSA 2.0a3 has been out for a couple of weeks now and I'm
> interested in any feedback you can offer.  Is this an improvement?

   I'm extremely sorry, Mark. I am very interested in every aspect of
the JSOSA component, but I've been busy on other projects, and
have not had the chance to really evaluate 2.0. This weekend,
I promise, I'm going to give it my full attention. :)

> Are you using it (it was only downloaded 10 times)?

   2 of those would have been me, work and home. :)

   I am also interested in advocacy of the component. When it
gets to "release" status, we should try to get the word out
about it. Here's a good place to start:

   http://www.mozilla.org/js/projects.html

Cheers,
   - Arthur

Hi Folks,

Well, JSOSA 2.0a3 has been out for a couple of weeks now and I'm interested
in any feedback you can offer.  Is this an improvement?  Are you using it
(it was only downloaded 10 times)?

If there are things you want to see in JSOSA2, please let me know.  As it
is, I have only 2 open bugs against JSOSA 2.  If I don't hear from you, this
will go beta as it is.

Cheers
-Mark


------------------------------------------------------------------------
Mark Alldritt                      Late Night Software Ltd.
Phone: 250-380-1725                Script Debugger 3.0 - AppleScript IDE
WEB: http://www.latenightsw.com    Affrus 1.0 - Perl Debugging

Hi Folks,

A new JavaScript OSA 2.0 alpha build is available for downloading.

In this version, I've changed the MacOS.FileSpec object to use CFURL instead
of FSRef internally.  This allows MacOS.FileSpec instances to once again
refer to files that don't yet exist.  I've added two new properties to
MacOS.FileSpec which compliment the existing alias property:

   MacOS.FileSpec.fileURL
     - read-only
     - returns an instance of MacOS.AEDesc containing a typeFileURL AEDesc
   MacOS.FileSpec.fileRef
     - read-only
     - returns an instance of MacOS.AEDesc containing a typeFSRef AEDesc

Additionally, the JavaScript->AEDesc converter will generate a typeFSRef
AEDesc for MacOS.FileSpec instances if the file/folder exists.  If the File
does not exist, a typeFileURL AEDesc is generated.  You, the scripter, don't
need to do a thing.

Download & Release Notes:

  http://www.latenightsw.com/freeware/JavaScriptOSA/jsosa2.html

With this build (2.0a3), I've closed all the open bugs I have filed against
JavaScript OSA.  If something is broken, please let me know.

Cheers
-Mark

------------------------------------------------------------------------
Mark Alldritt                      Late Night Software Ltd.
Phone: 250-380-1725                Script Debugger 3.0 - AppleScript IDE
WEB: http://www.latenightsw.com    Affrus 1.0 - Perl Debugging

Hi,

> Sigh...ok, I'm just thinking out loud here. I need more coffee...I'll get
> back to you. :)

Thanks for the ideas.  I'm no leaning towards changing the MacOS.FileSpec
class so that it uses CFURLs internally rather than FSRefs.  This allows
MacOS.FileSpec to do the right thing in almost all cases.  I'll probably add
a few properties like the existing MacOS.FileSpec.alias property that return
MacOS.AEDesc objects containing various kinds of file references.

The notion of a File class that can actually read a file is a good one.  In
fact, Mozilla JavaScript has just such an object, but it depends on the
Mozilla browser.  I'm going to look into getting it working stand-alone once
I get the existing JSOSA2.0 functionality sorted out.

Cheers
-Mark

------------------------------------------------------------------------
Mark Alldritt                      Late Night Software Ltd.
Phone: 250-380-1725                Script Debugger 3.0 - AppleScript IDE
WEB: http://www.latenightsw.com    Affrus 1.0 - Perl Debugging

> Additionally, this build fixes all the open bugs against JavaScript OSA
> 1.0.3.  As a result of this work, there are several new properties and
> methods on the various objects provided by JavaScript OSA (please see the
> API Changes section of the release notes for full details).

>  http://www.latenightsw.com/freeware/JavaScriptOSA/jsosa2.html

Ohhh... there's a lot of good stuff here!!! :)

MacOS.appByBundleID(bundleID, loadDict)
MacOS.appByHFSPath(hfsPath, loadDict)
MacOS.appByPath(posixPath, loadDict)
MacOS.appByFileSpec(MacOS.FileSpec, loadDict)

MacOS.homeFolder
MacOS.documentsFolder
etc...

MacOS.FileSpec.displayName; // read only

MacOS.FileSpec.path;       // read/write
MacOS.FileSpec.HFSpath; // read/write
MacOS.FileSpec.valid;      // read/only
MacOS.FileSpec.items;     // read only

NICE!!!

   I responded to your previous email before checking out these
new methods and properties. This is really cool, Mark, good
stuff!!!

Cheers,
     - Arthur

> In JavaScript OSA 2.0, I've modernized all the file handing
> to use FSRefs. The advantage here is that JSOSA is now
> fully capable of handling long file names and file paths
> containing Unicode characters.

   For those looking for information on the datatypes involved,
Apple's tech note 2022 is a good place to start:
     <http://developer.apple.com/technotes/tn/tn2022.html>

> The problem is that FSRefs cannot refer to a file that does
> not yet exist (something that the Classic MacOS FSSpec could
> do).  So, this means it is impossible to send save/close/open
> for access AppleEvents that create new files.

> Technically, JSOSA needs to generate a file URL (typeFURL)
> AEDesc.  The simplest approach is to create a function on
> one of the objects which generates the typeFURL AEDesc,
> but this isn't particularly object oriented. There's also the
> problem if what to do when a typeFURL is received from
> an application.

OK, just thinking out loud:

	 typeFSRef   = MyFirstApp.file[ 1 ];  // this app returns typeFSRef
	 typeFileURL = MySecondApp.file[ 1 ]; // this app returns typeFileURL

	 // When received from apps, all of these types should map to a single
	 // object wrapper.
	 //
	 typeFSRef.constructor == typeFileURL.constructor == MacOS.File // true

	 typeFSRef.fileType; //-> "typeFSRef"
	 typeFileURL.fileType; //-> "typeFileURL"

	 // where 'f' is either typeFSRef or typeFileURL

	 f.typeAlias();   //-> returns a raw alias AEDesc
	 f.typeFSRef();   //-> returns a raw fsref AEDesc
	 f.typeFileURL(); //-> returns a raw furl AEDesc

Er... OK, I'm not sure where I'm going here. Basically, I'd like a single object
wrapper that would act as a sort of "union" structure for holding all of these
damn datatypes, but that would have methods (or "getters", ideally) for
sending specific datatypes off to apps via AppleEvents.

The thing is, (and I know it would mean a lot more work for you, Mark),
I would prefer a File object that was more or less a self-contained
working entity, rather than just a specific datatype holder. Um, I mean
something like this:

var f = new MacOS.File( "/hello.txt" ); // let's say "hello.txt" doesn't exist

f.exists(); // false
//
// a native method of MacOS.File instances, and
// NOT just a hook that sends an AppleEvent to
// the Finder

f.openForAccess( true ); // true == writting permission
//
// the js object would itself, (without having to use any damn AppleEvents),
// determine that the path-string "/hello.txt" does not refer to an existing
// file, and would therefore create it.

   One of the (many) reasons why AppleScript is terrible for object-oriented
work is because of its complete realiance on AppleEvent data structures.
Creating a File object that natively handles 90% of the most basic things
without the Finder or osax, such as renaming files, moving them, deleting
them, reading and writing them, would make dealing with files much
easier, (and presumably faster, without the AppleEvent overhead).

   Sigh...ok, I'm just thinking out loud here. I need more coffee...I'll get
back to you. :)

Cheers,
     - Arthur

[My apologies if you receive this message more than once - I've been
experiencing some problems with Yahoo Groups]

Hi Folks,

I made some good headway over the weekend.  JavaScript OSA 2.0a2 addresses
two specific regressions in the 2.0a1 build:

  - opening existing scripts now works
  - Core.XML is once again operational

Additionally, this build fixes all the open bugs against JavaScript OSA
1.0.3.  As a result of this work, there are several new properties and
methods on the various objects provided by JavaScript OSA (please see the
API Changes section of the release notes for full details).

Release Notes and Download information are available here:

  http://www.latenightsw.com/freeware/JavaScriptOSA/jsosa2.html

CAUTION: Please keep in mind that this is Alpha software.  You should expect
problems if you choose to use this software.

Cheers
-Mark

------------------------------------------------------------------------
Mark Alldritt                      Late Night Software Ltd.
Phone: 250-380-1725                Script Debugger 3.0 - AppleScript IDE
WEB: http://www.latenightsw.com    Affrus 1.0 - Perl Debugging

Hi Folks,

I made some good headway over the weekend.  JavaScript OSA 2.0a2 addresses
two specific regressions in the 2.0a1 build:

  - opening existing scripts now works
  - Core.XML is once again operational

Additionally, this build fixes all the open bugs against JavaScript OSA
1.0.3.  As a result of this work, there are several new properties and
methods on the various objects provided by JavaScript OSA (please see the
API Changes section of the release notes for full details).

Release Notes and Download information are available here:

  http://www.latenightsw.com/freeware/JavaScriptOSA/jsosa2.html

CAUTION: Please keep in mind that this is Alpha software.  You should expect
problems if you choose to use this software.

Cheers
-Mark

------------------------------------------------------------------------
Mark Alldritt                      Late Night Software Ltd.
Phone: 250-380-1725                Script Debugger 3.0 - AppleScript IDE
WEB: http://www.latenightsw.com    Affrus 1.0 - Perl Debugging

Hi All,

In JavaScript OSA 2.0, I've modernized all the file handing to use FSRefs.
The advantage here is that JSOSA is now fully capable of handling long file
names and file paths containing Unicode characters.

The problem is that FSRefs cannot refer to a file that does not yet exist
(something that the Classic MacOS FSSpec could do).  So, this means it is
impossible to send save/close/open for access AppleEvents that create new
files.

Technically, JSOSA needs to generate a file URL (typeFURL) AEDesc.  The
simplest approach is to create a function on one of the objects which
generates the typeFURL AEDesc, but this isn't particularly object oriented.
There's also the problem if what to do when a typeFURL is received from an
application.

Do any of you have a preference for how this should be handled?

Cheers
-Mark

------------------------------------------------------------------------
Mark Alldritt                      Late Night Software Ltd.
Phone: 250-380-1725                Script Debugger 3.0 - AppleScript IDE
WEB: http://www.latenightsw.com    Affrus 1.0 - Perl Debugging

> Well, its been a long while, but I'm once again moving forward with
> JavaScript OSA.  I'm pleased to announce JavaScript 2.0a1 (that's Alpha!!!).

   Mark, this is fantastic! Thank you. :)

> Please be warned that this is an Alpha build which has only undergone
> minimal unit testing.  You must expect bugs and problems.  However, if you
> are feeling adventurous, please give it a try.

	 Core.version;  //-> "1.0b10"

Alrighty, then. ;-)

   I'll give the component a workout this week.

Cheers,
     Arthur

Hi Folks,

Well, its been a long while, but I'm once again moving forward with
JavaScript OSA.  I'm pleased to announce JavaScript 2.0a1 (that's Alpha!!!).

Please be warned that this is an Alpha build which has only undergone
minimal unit testing.  You must expect bugs and problems.  However, if you
are feeling adventurous, please give it a try.

While JSOSA 2.0a1 is (almost) functionality identical to 1.0.3, there have
been dramatic internal changes in this build.  These changes make
maintaining JSOSA much simpler and will permit me to begin doing new
development.

Download and Release Notes:

  <http://www.latenightsw.com/freeware/JavaScriptOSA/jsosa2.html>

Cheers
-Mark

------------------------------------------------------------------------
Mark Alldritt                      Late Night Software Ltd.
Phone: 250-380-1725                Script Debugger 3.0 - AppleScript IDE
WEB: http://www.latenightsw.com    Affrus 1.0 - Perl Debugging

Thanks. I had already done something fairly similar to this, but it is good to
hear that I am
not just doing something stupid.

-Gregory


--- In jsosa@yahoogroups.com, arthur@s... wrote:

> I played around with this for a while, and couldn't get the object "recast",
sorry.
> This is a work-around function, nothing else I can think of:
>
>  BBEdit = MacOS.appBySignature( 'R*ch' );
>
>  function BBFindTag( tagName )
>  {
> 	 var rec = BBEdit.find_tag( tagName, 0, false );
>
> 	 if ( ! rec.found_tag ) return rec;
>
> 	 rec.tag.name                 = rec.tag.ae_pnam;
> 	 rec.tag.is_close_tag         = rec.tag.ae_TICl;
> 	 rec.tag.is_empty_xml_element = rec.tag.ae_TIEx;
> 	 rec.tag.start_offset         = rec.tag.ae_Estr;
> 	 rec.tag.end_offset           = rec.tag.ae_Eend;
> 	 rec.tag.attributes           = rec.tag.ae_TIAl;
>
> 	 return rec;
>  }
>
>  var rec = BBFindTag( 'meta' );
>
>  MacOS.message( rec.tag.start_offset );
>
> Cheers,
>     Arthur

Sorry, my last email got cut off by a stray null character.

> Below is a script that loops through all properties of the returned object (an
image tag).
> What I really wanted was to be able to get rec.tag.start_index and
rec.tag.attributes.src.

> Any advice?

I played around with this for a while, and couldn't get the object "recast",
sorry.
This is a work-around function, nothing else I can think of:

	 BBEdit = MacOS.appBySignature( 'R*ch' );

	 function BBFindTag( tagName )
	 {
		 var rec = BBEdit.find_tag( tagName, 0, false );

		 if ( ! rec.found_tag ) return rec;

		 rec.tag.name                 = rec.tag.ae_pnam;
		 rec.tag.is_close_tag         = rec.tag.ae_TICl;
		 rec.tag.is_empty_xml_element = rec.tag.ae_TIEx;
		 rec.tag.start_offset         = rec.tag.ae_Estr;
		 rec.tag.end_offset           = rec.tag.ae_Eend;
		 rec.tag.attributes           = rec.tag.ae_TIAl;

		 return rec;
	 }

	 var rec = BBFindTag( 'meta' );

	 MacOS.message( rec.tag.start_offset );

Cheers,
     Arthur

> I am new to jsosa and am a little confused.

   Aren't we all? ;-)

> My problem is this: if I find a tag in an HTML document, the result is not
cast
> as a tag.

	 BBEdit = MacOS.appBySignature( 'R*ch' );

	 rec = BBEdit.find_tag( 'meta', 0, false );
	 /*
		 {     class : 'TRsC'

Hello-

I am new to jsosa and am a little confused. I am an experienced JavaScripter
with moderate
Applescript knowledge trying to do something in BBEdit.

My problem is this: if I find a tag in an HTML document, the result is not cast
as a tag. For
instance, the following works to find an image tag, but the resulting object has
the
AppleEvent properties (like ae_Eend) rather than what I would expect
(end_offset). How do
I cast the object to the correct class?

Below is a script that loops through all properties of the returned object (an
image tag).
What I really wanted was to be able to get rec.tag.start_index and
rec.tag.attributes.src.

Any advice?


var bbEdit = MacOS.appBySignature("R*ch", true, false);

with( bbEdit ) {
   _strict = false;
   activate();

   var rec = find_tag( "img", 0, false );

   if( rec.found_tag ) {
     var str = "Tag Found: \n";
     var props = new Array();

     for( var prop in rec.tag )
       props.push( prop + ":\"" + rec.tag[prop] + "\"" );

     display_dialog( "tag found: {" + props.join(", ") + "}" );
   } else {
     display_dialog( "tag not found" );
   }
}

:-( sad ...
In the string generated by the md.toString() I think that I locate the
index of the image in the whole catalog, so I can parse that string
waiting for a correction of this.

Constant



--- In jsosa@yahoogroups.com, arthur@s... wrote:
>   I can't figure it out. It's simple enough in AppleScript:
>
>  tell application "iView MediaPro"
>
> 	 catalog 1's selection's item 1's name
>
>  end tell
>
> but I can't get anywhere in JavaScript:
>
>  iView = MacOS.appBySignature( "IVW5" );
>
>  iView.catalog[ 1 ].selection[ 1 ].name; // error "Out of Memory",
or something
>
> It knows about the name property:
>
>  iView = MacOS.appBySignature( "IVW5" );
>
>  md = iView.catalog[ 1 ].selection[ 1 ];
>
>  s = "";
>  for ( p in md ) { s += p + "\n" }
>  s;
>  /*
> 	 annotations
> 	 displayed_height
> 	 displayed_width
> 	 catalog_date
> 	 annotation_date
> 	 creation_date
> 	 modification_date
> 	 label_index
> 	 media_info
> 	 modified
> 	 mounted
> 	 path
> 	 device_info
> 	 rotation
> 	 sample_color
> 	 thumbnail
> 	 media_type
> 	 unique_id
> 	 URL
> 	 volume_name
> 	 index
> 	 name 	 <- here it is
> 	 custom_field
>  */
>
> but you can't actually access it.
>
> This is the event AppleScript is sending:
>
>  core\getd{
> 	 ----:obj {
> 		 form:'prop',
> 		 want:'prop',
> 		 seld:'pnam',
> 		 from:obj {
> 			 form:'indx',
> 			 want:'cobj',
> 			 seld:1,
> 			 from:obj {
> 				 form:'prop',
> 				 want:'prop',
> 				 seld:'sele',
> 				 from:obj {
> 					 form:'indx',
> 					 want:'cwin',
> 					 seld:1,
> 					 from:'null'()
> 				 }
> 			 }
> 		 }
> 	 },
> 	 &csig:65536
>  }
>
> And here is what JSOSA is trying to do:
>
>  core\getd{
> 	 ----:obj {
> 		 want:'prop',
> 		 from:obj {
> 			 want:'cgob',
> 			 from:obj {
> 				 want:'cwin',
> 				 from:'null'(),
> 				 form:'indx',
> 				 seld:1
> 			 },
> 			 form:'ID  ',
> 			 seld:2
> 		 },
> 		 form:'prop',
> 		 seld:'pnam'
> 	 }
>  }

I can't figure it out. It's simple enough in AppleScript:

	 tell application "iView MediaPro"

		 catalog 1's selection's item 1's name

	 end tell

but I can't get anywhere in JavaScript:

	 iView = MacOS.appBySignature( "IVW5" );

	 iView.catalog[ 1 ].selection[ 1 ].name; // error "Out of Memory", or something

It knows about the name property:

	 iView = MacOS.appBySignature( "IVW5" );

	 md = iView.catalog[ 1 ].selection[ 1 ];

	 s = "";
	 for ( p in md ) { s += p + "\n" }
	 s;
	 /*
		 annotations
		 displayed_height
		 displayed_width
		 catalog_date
		 annotation_date
		 creation_date
		 modification_date
		 label_index
		 media_info
		 modified
		 mounted
		 path
		 device_info
		 rotation
		 sample_color
		 thumbnail
		 media_type
		 unique_id
		 URL
		 volume_name
		 index
		 name 	 <- here it is
		 custom_field
	 */

but you can't actually access it.

This is the event AppleScript is sending:

	 core\getd{
		 ----:obj {
			 form:'prop',
			 want:'prop',
			 seld:'pnam',
			 from:obj {
				 form:'indx',
				 want:'cobj',
				 seld:1,
				 from:obj {
					 form:'prop',
					 want:'prop',
					 seld:'sele',
					 from:obj {
						 form:'indx',
						 want:'cwin',
						 seld:1,
						 from:'null'()
					 }
				 }
			 }
		 },
		 &csig:65536
	 }

And here is what JSOSA is trying to do:

	 core\getd{
		 ----:obj {
			 want:'prop',
			 from:obj {
				 want:'cgob',
				 from:obj {
					 want:'cwin',
					 from:'null'(),
					 form:'indx',
					 seld:1
				 },
				 form:'ID  ',
				 seld:2
			 },
			 form:'prop',
			 seld:'pnam'
		 }
	 }

I try the iView._strict = false and I got the same error. Exept that it told me
'MacOS.AEClass: can't convert to' without the stange characters at the end of
the
message...

I can figure out what "cat = iView.catalog[ i ]" returns me, I didn't yet try to
call  AEColl
methods it.

The list looks to be zero based when I use "for (var x in cat.selection )" with
two images
selected in the catalog, x goes from 0 to 1.

Look's to be a stange typical computer behavior :-)
The reason is probably simple but we don't know it yet !

I'll try to call AEColl methods and give updates.

Thanks


--- In jsosa@yahoogroups.com, arthur@s... wrote:
> > I testing JSOSA to pilote  the iView (v2.6.3) application.
>
>   I'm a little confused. I downloaded a demo, and I can't even
> find a dictionary for the app. Their website says its scriptable,
> but I can't figure out how to tell it to do anything. Maybe the
> 21-day demo iView has scripting disabled?
>
> > Here is a simple code to collect basic info from iView (and train
> > myself) :
>
> > var iView = MacOS.appBySignature("IVW5");
>
>     iView._strict = false; // often useful to do
>
>     ...
>
> >  if( cat.selection.length > 0 ){
> > 	 for( var x = 0; x < cat.selection.length ; x++){
> > 		 var md = cat.selection[x];
> > 		       str += " " + md.name + "\n"; // <- here is the problem
>
>   Wouldn't cat.selection be 1-based, rather than 0-based? That is, does
> getting "cat = iView.catalog[ i ]" return an array or an object of type
AEColl?
>
>     for( var x = 1; x <= cat.selection.length ; x++ )
>
>
> > The selection in iView should be a liste of media item object
> > (following the dictionnary).
>
>   I'd love to actually see the dictionary. :)
>
> Cheers,
>     Arthur

>> I testing JSOSA to pilote  the iView (v2.6.3) application.

>   I'm a little confused. I downloaded a demo, and I can't even
> find a dictionary for the app. Their website says its scriptable,
> but I can't figure out how to tell it to do anything. Maybe the
> 21-day demo iView has scripting disabled?

   Whoops, there is a difference between the "Media" and "MediaPro"
versions, sorry. I'll get back to you.

>   I'd love to actually see the dictionary. :)

   And now I can. :)

Cheers,
   Arthur