• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Adobe's lousy AppleScript implementations
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Adobe's lousy AppleScript implementations


  • Subject: Adobe's lousy AppleScript implementations
  • From: David Crowe <email@hidden>
  • Date: Thu, 26 Sep 2002 13:36:52 -0400

I have been attempting to replicate what I could do in Mac OS 9 with the greatest of ease using KeyQuencer - move a window on the screen without regard to the application. I have written AppleScripts connected to QuicKeys that can accomplish commands such as 'move window to right side of screen' using hot keys - but with a number of restrictions, one of which is the apparently stupid implementation of AppleScript by at least 2 Adobe products.

I knew that using AppleScript would only work on applications that support AppleScript (so much for using these scripts with my beloved copy of Microsoft Word 5.1, even though it still works more reliably than the most recent version of Word), but I've discovered that:

1. Adobe Acrobat does not recognize the "window" class, but only "pdf window".

2. Adobe FrameMaker does not recognize the "window" object, but only the "document" object. Worse yet, its implementation of the 'bounds' property has the X and Y coordinates reversed.

This is an example of the ugliness of one of the resulting scripts:

property JogAmount:50
tell application "Finder"
set theAppName to name of (every process whose frontmost is true) as string
end tell

try
if theAppName starts with "Acrobat"
tell application "Acrobat 5.0"
set {wLeft, wTop, wRight, wBottom} to bounds of pdf window 1
if wLeft > JogAmount then set bounds of pdf window 1 to {wLeft-JogAmount, wTop, wRight - JogAmount, wBottom }
end
else if theAppName starts with "FrameMaker"
tell application theAppName
-- FrameMaker has coordinates rotated!
set {wTop, wLeft, wBottom, wRight} to bounds of document 1
if wLeft > JogAmount then set bounds of document 1 to {wTop, wLeft-JogAmount, wBottom, wRight -JogAmount}
end
else
tell application theAppName
set {wLeft, wTop, wRight, wBottom} to bounds of window 1
if wLeft > JogAmount then set bounds of window 1 to {wLeft-JogAmount, wTop, wRight - JogAmount, wBottom }
end tell
end
end


Another consequence of the use of a non-standard class is that <tell application "Acrobat 5.0"> must be used in order for the script compiler to recognize the "pdf window" class. This is not necessary for FrameMaker (6.0) because document is a standard class.

Another little wrinkle is that window 1 appears to always be the topmost window (and this goes for pdf window), but documents are numbered iin the order they show up in the FrameMaker Window menu.


Any hints as to how to simplify this would be appreciated. If someone has FrameMaker 7 it would be nice to know if the same (mis-)behaviour occurs with that version.

- David Crowe
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Adobe's lousy AppleScript implementations
      • From: Bill Briggs <email@hidden>
  • Prev by Date: use printer on Mac OS X???
  • Next by Date: Re: Interesting... AppleScript X ??
  • Previous by thread: Re: Can't compile from OS X
  • Next by thread: Re: Adobe's lousy AppleScript implementations
  • Index(es):
    • Date
    • Thread