John Love wrote:
Really though, what's best/practical/possible all depends on what
you're trying to do, so if you want more advice then you'll need to
provide more information.
Very short info list is as follows (stuff I need to do from within my
Cocoa app):
1) be able to save the Excel spreadsheet
Opening and saving Excel workbooks can be done with Apple events, e.g.
using objc-appscript [1]:
// To create glue: osaglue -o MEGlue -p ME Microsoft Excel
MEApplication *microsoftExcel = [MEApplication applicationWithName:
@"Microsoft Excel"];
// open file specified by HFS path
MEOpenWorkbookCommand *cmd = [[microsoftExcel openWorkbook]
workbookFileName: @"Mac
HD:Users:foo:Workbook1.xlsx"];
id result = [cmd send]; // result is a by-name reference to the new
workbook, or nil if an error occurred
// save in new file
MEReference *ref = [[microsoftExcel workbooks] byName:
@"Workbook1.xlsx"];
MESaveWorkbookAsCommand *cmd = [[ref saveWorkbookAs]
filename: @"Mac HD:Users:foo:Workbook2.xlsx"];
id result = [cmd send]; // result is nil if an error occurred
Two potential problems to be aware of:
1. Excel stupidly uses HFS path strings in its 'open workbook' and
'save workbook as' commands. This means you'll have big problems if
you have another volume with the same name as the one you're opening
from/saving to, as HFS paths can't distinguish between identically
named volumes. (Better designed applications use alias and file URL
types to identify filesystem objects and locations.)
You might be able to work around this issue by using the standard
'open' and 'save' commands, although you lose the additional features
provided by 'open workbook' and 'save workbook as'. Or you may
consider using HFS paths to be an acceptable risk and just put up with
them.
2. References returned by Excel only identify workbook objects by-
index or by-name references. That makes it tricky to ensure you've a
stable handle on the workbook for the length of time it's open. (By-
index specifiers are sensitive to element order; by-name specifiers
can't distinguish between two elements with the same name. Only by-id
specifiers are guaranteed to be unique and stable over a target
process's lifetime, but most apps don't use those.) I did wonder if
using a by-test specifier would work; something like:
tell app "Excel"
tell first workbook whose full name = HFS_path_to_file
-- do stuff here
end
end
but it doesn't work, so you'll either need to iterate over elements
and compare their paths yourself or else just use the existing by-name
references and trust that nobody opens another file with the same name
while your program is doing its thing.
2) be able to stop any calculation in progress
Dunno myself; you'll need to ask someone with more Excel scripting
experience.
3) be able to detect if the user closed the spreadsheet "behind the
back" of my Cocoa app, upon which my Cocoa app would raise a NSAlert.
Assuming you've figured out a way to uniquely identify your workbook
element, you could poll Excel at regular intervals to see if it still
exists.
HTH
has
[1] Be aware that Office apps are a rather eccentric bunch even by
AppleScripting standards, but appscript's application compatibility is
very nearly as good as AppleScript's these days (and sometimes even
better) so I don't think it'll have any problems.
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
