The intention of this mode of operating is that any dialogs would be suppressed with the default settings accepted, but any alerts that your scripting actions caused would still be displayed. I have yet to successfully use this option.

This is more a change in functionality of the product, but if (like me) you had used labels for tables in CS confident that the user wouldn't see them, this is changed in CS2. If you select a whole table in the UI, you'll see the Script Label (if there is one) in the Script Label palette.

Note also that cells can now have labels. This should help those people who want to automate linkages between parts of tables with parts of spreadsheets. Cell labels too are visible in the UI.

In the situation where a table consists of just one cell (I use these in my HeadStraddler product), you can see only the table label in the UI. To see the cell label, you'd have to temporarily add a cell to the table.

The really good news here is that both Cells and Tables have the insertLabel and extractLabel methods, so you can still have labels added by your scripts that aren't visible in the UI.

This change is likely to cause a fair amount of editing. In CS, the text property parentTextFrame sometimes returned a collection making its name rather confusing. Now, it always returns a collection and so its name has been changed to the plural form.

So, if the only thing you care about is the parent text frame of the first character of some text, you can write:

I think this is JS only. Whereas before, exit() issued a beep as it exited, it now exits silently. However, there is a new beep() method to create a beep. This means you can issue a beep as you pop-up an alert.

I've been using this function to manage my exiting from scripts so that they will work with either CS or CS2:

This is more of a functional change of the application itself. The symbol used by Find/Change for End Nested Style Here is now ^h rather than ^\. I don't think I ever actually used that symbol in a script but had I done so ...

I've been grappling with this one most of the day. There is something strange associated with the form of the convert to table method when used with three parameters (as you do when you want the return character to delimit both cells and rows).

In CS, my HeadStraddler product uses:

myTable = myText.convertToTable("\r","\r",1);

to convert the text of the first paragraph of a text frame (less its paragraph marker) to a single-cell table. To get this to work properly in CS2, I have had to use:

myTable = myText.convertToTable("\r","\r",1)[0];

but this has the look of an unintentional bug, so I'm actually restructuring what I'm doing altogether, taking advantage of the fact that the table is the first thing in the frame, so I've changed the original to:

This list is by no means exhaustive, but these are the things I've run into in the past few days.

If any of you know of any other topics worthy of adding to this list, please e-mail me (my address is accessible if you click my name) or start another topic and I'll add them in here with the links at top.

If you want to discuss or explore any of the topics I've posted, feel free to start a new topic.

Regarding your doScript example--you haven't given it a file to run, you've given it a string. I'm not sure what you mean by "the fundamentally different manner in which scripts are run with CS2"--I don't see it. If doScript for a string returned a file for a string being run using doScript in CS, then it was an error.

In addition, if you use doScript to run a script file, then app.activeScript should return the name of that file, not the name of the script in which the doScript statement is used.

Regarding the end nested style metacharacter--this is also true in the user interface, so it's not only a scripting change (and, for that matter, we have no control over it). While I disagree with the UI team changing find/change metacharacters without notice, I do check the metacharacters list with each new release, just in case.

Text selections are more specific about what is selected than in CS. While CS would only ever give you Text or InsertionPoint as the kind of selection, CS2 will give you responses like Word or Paragraph.

I don't know -- but I'd advise against using unicode values to identify tables. Doing that kind of thing falls into the category of reverse engineering, it seems to me, and is not something that can necessarily be relied upon from one release to the next.

Maybe, but I'd regard it as an implementation detail and not something to be relied upon. It's safe to rely on it for a particular release, but if they choose to implement tables in an entirely different way, they're free to do so, it seems to me. That a table has a unicode is not documented -- it's something we scripters found out by digging.

> don't know -- but I'd advise against using unicode values to identify tables. Doing that kind of thing falls into the category of reverse engineering, it seems to me, and is not something that can necessarily be relied upon from one release to the next.

Very true. Relying on undocumented features is a good way to have your scripts break with the next release.

However, since Adobe has no compunction about breaking documented behavior with a new release, it doesn't make much difference, does it?

Scripting indexes has changed a lot. It finally works, and it works well. The property 'subtopic' has gone, instead you iterate the property 'topic' (up to three times). The following lines illustrate:

Glad you noticed that we fixed indexing! I'd actually somewhat forgotten about it, as it's not a new feature--we just made it work the way it was always supposed to work. (It was originally implemented by WinSoft in France--between their English and my French, some things were lost in translation.)

There's still a lot to do, and there are still some bugs to fix--I'd urge you not to change the sort order for an existing index topic using scripting, as it's pretty fragile. But it's much better--for scripting and for saving to .inx.

I like adding the "flattened" collections--such as allTopics--wherever we can (to avoid having to use iteration/recursion to find things), so it made sense to take care of it while we were working on the plug-in.

//----------------------------------------
A new property is allTopics: myIndex.allTopics returns an array of all (sub)topics. This is a flat, one-dimensional, array, i.e. it returns the whole index but without structure.
//----------------------------------------
In CS:
allTopics = myIndex.topics.everyItem().subtopics.everyItem();

But if change the topics's one subTopic's sortOrder, the subTopic's index has been changed, it means:
the before subTopic[x] != after subTopic[x];
I have spent so much time to solve the problem.
Is not the same as the in CS2?

Hey, wait - "sort order" ?<br /><br />Does it do what one would think it does? I.e. change sort order to that of<br />different alphabets such as German, English, Norwegian etc?<br /><br />Where is that located in the UI? I can't find it<br /><br /><br /><br />On 05-04-28 02.58, in article 3bba0c2a.19@webx.la2eafNXanI,<br />"Olav_Kvern@adobeforums.com" <Olav_Kvern@adobeforums.com> wrote:<br /><br />> There's still a lot to do, and there are still some bugs to fix--I'd urge you<br />> not to change the sort order for an existing index topic using scripting, as<br />> it's pretty fragile. But it's much better--for scripting and for saving to<br />> .inx.

b Common problems:
<1>. Simple Chinese(Chs): Phonetic--Stroke sorting can be not identifed automately;
<2>. Traditional Chinese(BIG5): Stroke sorting can be not identifed automately;
<3>. Korean can not be sorting by KS Code automately;

A couple of days ago, I posted a script that started out by deleting all paragraph styles. Even in CS, you had to avoid attempting to delete the "first" paragraph style ("No paragraph style"), but in CS2 you also need to avoid deleting the second one, also.

By the way, this is quite an annoyance in the UI. If you select all unused and your Basic Paragraph style is not in use and so gets selected (something which is more likely to happen with converted documents than newly created ones), the Delete menu item is greyed out in the Paragraph Style palette menu because you can't delete that style.

When an asset is placed on a document from a library, in CS it became the selection. In CS2, this is no longer the case, so you cannot rely on the selection to get a reference to what was just placed (something which I've been doing although it wasn't strictly necessary).

The following code works in both CS and CS2 and so is the preferred way of doing this:

myObj = myAsset.placeAsset(myDoc)[0];

The index is needed because an asset might consist of multiple page items, so placeAsset returns an array of references even when there's only one item.

In CS2, do not attempt to place an asset on a document if you have an active selection in that document. The code in the previous message only works if you do not have a selection. If you have one, strange things happened. You might even conclude that your document is haunted.

Yikes, I was under the impression that there wouldn't be that many changes but there sure are. I've identified 3412 (!) differences so far, by comparing the scripting libs of CS and CS2 via reflection. This excludes all new types, such as ObjectStyle.

One very, very bad thing is that the scripting lib is now even less (by magnitudes) typesafe than it was before, making typesafe scripting in .NET a PITA.

E Gunnar Liljas wrote: "Yikes, I was under the impression that there wouldn't be that many changes but there sure are. I've identified 3412 (!) differences so far, by comparing the scripting libs of CS and CS2 via reflection. This excludes all new types, such as ObjectStyle."

You should be able to use the CS (3.x) version of the scripting model with VB.NET, as described in the earlier post (publish the terms, then add the reference to your VB.NET project). If that doesn't work, you can alway send a string as VBScript and target the 3.x version of the model.

OK, that seems to work. However, there still exist a few changes, especially for the ChangePreferences and FindPreferences, where all properties are of type "object" now. They used to be strongly typed.

Is this change done in order to make it possible to unset the properties of ChangePreferences and FindPreferences, by using null/Nothing, or it it something else?