update.. i trimmed the code down to the absolute bare minimum just so i can see what's happening.. the following code produces the result "[SpotColor]"
var docRef = app.activeDocument; var paths = docRef.pathItems; alert(paths.fillColor); // returns: "[SpotColor]"
That tells me that for some reason the property fillColor is returning the typeName.. so i changed the alert to this, in order to get the name of the swatch:
var docRef = app.activeDocument; var paths = docRef.pathItems; alert(paths.fillColor.name); // returns: "undefined"
???? this is really confusing to me.. anyone tell me what i'm doing wrong here?
The spot color access through fill or stroke color of a path item when it is a spot color is just a tiny bit more complicated, you have got to go pathItem.fillColor.spot.name .
To see whether an unwanted color is in the document, you could utilize a more efficient method by scanning the InkList of the document- it has the information that you see in the print dialog under output.
doing alert(document.inkList) will show you the collection of ink plates.
why doesn't the scripting guide show fillColor as an available property for pathItems? sometimes that scripting guide is genius and sometimes i wonder if the writer was falling asleep while writing it and just left out huge chunks of information...
as to your second suggestion, i need to be more specific than just determining whether the spot color exists in the document.. for example, i need to know that thru-cut exists only as a stroke color, and at least once per artboard. to my knowledge, the inkList or doc.swatches properties will only tell me whether the color exists at all. it would be helpful for me to know that the color does NOT exist, but the script i have will alert me to that as well as cross reference the number of artboards vs the number of artboards that contain at least 1 thru-cut stroke.
interesting.. that worked in my shorthand sample script and alerts the proper color.. but in the original script i posted above i'm getting the error "undefined is not an object" on the first loop on line 18... it seems it doesn't allow me to access the pathItems inside of groupItems[a] for some reason??
I believe you can double your productivity by using the step-through functions of the ETSK and watching the data browser for the contents of your variables. When you do, a new world will open up! You click the area next to your line number to set up a breakpoint and use the shortcuts under the Debug menu to go through your script, seeing the innards. In the case of this screenshot, I pressed Run, and it ran until reaching my breakpoint. At this time it is possible to see the variable x in the Data Browser, it shows to be a string "Untitled-1"
DDo you know of any good tutorial video that walks through break points and step through functions??? I've seen all of that stuff there, and I've used the data browser to view the values of certain variables and sometimes I've been able to discern available properties that weren't listed in the scripting guide. But the data browser is always so cluttered with stuff that is in no way relevant to my project (tons of after effects functions????) and I haven't quite seen how to delete the impertinent stuff.. I just need some kind of crash course.. But I can definitely see the benefits you're talking about and how they woudid really increase my productivity.
I see. The reason you see too much clutter is because of a lack of closure. See my screenshot above, the code is wrapped in a function called test(). When you're running scripts without a closure, you add all the variables you've created into memory and you will see them next time too.
Try to run the exact thing I have in the screenshot, and you should only see the variables in the screenshot.
WWhen I open a fresh, blank estk document, the data browser by default is cluttered with about 50 generic variables and functions. many of which, like I said, are for after effects, even though I've never written a line of code that targeted AE.
Yes there can be a lot of stuff in the global scope when you're just in the etsk writing your script, but when you step-through (Debug > Step Into), your variables in the data browser should only be the ones in the current scope of execution.
the data browser seems to display tons of stuff i don't need and have never used.. sometimes it displays variables within other open documents.. and sometimes it even shows variables that i tried like last week and decided i didn't need so i deleted them. how do i go about cleaning that panel up?? why would it hold information from previous projects? (especially when i can't seem to get ESTK to even save my preferences at the end of a session.. for example i change the font and size every day to make it easier to read.. the default font makes it difficult to determine the difference between i and l..). but whenever i start a new session... the preferences go back to default.. i wonder if i've got some serious bugs and perhaps need to re-install the application?
Your yellow line is at the start of the function, before your execution goes inside, so it shows the old global stuff from outside. Press F11 on Windows or Shift+Cmd+I on a Mac to step into the function. Your yellow line will go into the function and your data browser will show just stuff in the function.
ok.. i see that i have to keep stepping to get inside the function.. but it still doesn't reveal variables as i go through them.. for example.. why doesn't it show the value of x on line 5? why does it show the value of x on line 6??
i can see the benefit of viewing the results and values of each line.. but this seems like a really cumbersome way to do it.. it seems to me that it would be easier to simply log each result to the console and read it that way.. especially because step through stops on just about every line even if it's not giving you any information. for example.. when i step through and it stops on "var docRef = app.activeDocument"... i'm not gaining any information about that variable.. every bit of information i need for that one is right there in that statement..
i'll have to keep playing with this.. but right now it seems like it's going to slow me down more than anything..
not to mention.. i'm not sure how to 'close' my loops and such in the script i posted at the beginning of this thread.. if i just put all of those loops in a function, as i'm stepping through it i have to step through the first loop [a] times before i can get any information about the second loop. it seems like i should have separate functions rather than lumping all of that into one function.. but i don't really know how to put that together.
The breakpoints are what will help you get somewhere faster without going through a bunch of code manually: you put one on, hit debug>Run and it will stop at the breakpoint, if something is there. That way you can see what different properties are in something. It shows the data in the data browser on the next line because it shows stuff for lines before your current one. When you do another step, you read the line your lellow line is on for the first time. I wanted you to know about this because you were having problems with the fillcolor of a path item, and the spot color, which is confusing still to me after all these years, but you can see exactly what you are up against when using breakpoints and stepping through. For stepping over functions, you can use the Step-Over command to skip a block of code. What I generally do is put my breakpoint, hit Run, it stops where the breakpoint is and then I either abort execution or hit run again to finish after I've observed what I need. Most of the time, I do use $.writeln and alert() to get quick info, but when something is not working and you don't know why and are going mad, this may be the only way to save oneself.
ok.. i think i'm starting to get it. so as far as your ESTK workflow.. do you wait until you've gotten an error to add the break point? or are you adding those proactively while you're writing your code in anticipation of potential errors?