Hi,
On Windows I have this code which works fine on Windows, but
the same code on Mac gives me an OLEException error that pops up
saying “OLE Not Supported on this platform”
Do I need to change this some to work on the Mac?
Thanks in advance.
-Tim
Dim f as FolderItem
dim dlg as new OpenDialog
dlg.InitialDirectory=SpecialFolder.Documents.Child("Torrid Technologies").Child("MyFolderName").Child("Docs")
dlg.Title = "Open the Word Doc"
f = dlg.ShowModal()
Dim Word as new WordApplication
Word.Documents.Open(f.NativePath)
Word.Visible = True //Show the Word Application
Word = Nil //Set the object to Nil
Exception err as OLEException //Check for an error
MsgBox err.message //display the error
[quote=245414:@Tim Turner]Hi,
On Windows I have this code which works fine on Windows, but
the same code on Mac gives me an OLEException error that pops up
saying “OLE Not Supported on this platform”
Do I need to change this some to work on the Mac?
[/quote]
OLE does not exist on Mac, so yes.
[quote=245425:@Tim Turner]Should I do that for mac AND windows?
That just tells the OS to “open this file” and OS knows the file type by the file extension and thus knows how to deal with it?[/quote]
Yes, and correct.
If the user does not have an app installed that can handle the filetype you may get unexpected results.
In the case where they don’t have Word or something to open the .doc file, what exception should I be trapping?
Also does launch work with any file type? I have some other code that pushes data out to an excel file and then tries to open Excel but it’s not working reliably on all versions of Excel.
On both platforms, if you dont plan to try to DRIVE the target application (Word, Excel…) using OLE, but just get them to open the document, then the best and simplest approach is to use
f.launch
On a Mac, that will probably open a DOC file in Pages, and an XLS file in Numbers
On a PC, DOC will be opened by Word or by WordPad if Word is not present
BUT
Later versons of Excel have become fussy
It used to be the case that saving a CSV file with an XLS extension would cause Excel to open it. Now, some versions of Excel look at the file and throw up a message to say ‘hang on, thats now an Excel file, what are you playing at?’
(Or words to that effect)
So if the file you want to open is actually a CSV file, give it a CSV extension and it will work.
If it is a tab delimited file, you might give it .TSV or .TXT
Its less likely that Excel will be the app that opens it, but you could always try assembling a command line to launch Excel with the filename on the command
OK this is an old thread but I have run across a mac with no Word installed and the .doc is opened in TextEdit and loses any reasonable formatting. User thinks document is poorly done and ugly.
Can we check for Word and if not there catch that and throw message to a user?
I just looked at the MBS docs about that… it says that is returning the names of apps that can handle the file type.
Clearly TextEdit has registered that it can handle .doc files but it just does a really poor job of it.
I basically don’t want to launch the file if it’s not Word (or perhaps some other app that can handle it properly)
Am I misinterpreting what LaunchServicesApplicationForInfoMBS does?
I am opening a simple word doc questionnaire provided for the user as a courtesy because all of the advisors ask for a “fact finder” to have their clients fill it out. But when it looks ugly they think negatively of our company and our app. Rather not launch it at all than show an ugly version.
Word does not have a lot of places to be.
directly in the /Applications folder, or in a “Microsoft Office 2011” or 2008.
may be you could simply check for that ?
You can also use an AppleScript to open documents on the Mac. That might give you more control Word as well, similar to OLE on Windows, i.e. you could ask Word if the document is already open (and then close it in case you have now created an updated version).
You’d have to use “Script Editor” on a Mac to write and save the Applescript, then drag that into your project and call it like it’s a method, e.g. here’s the script you could use:
on run {arg1}
tell application id "com.microsoft.Word"
open alias arg1
end tell
end run
The beauty of this is that it finds the “prevailing” (i.e. usually the latest) version of Word, no matter where it’s located. So you don’t have to ask the user to locate it.
Save as “OpenInWord.scpt”, add it to your project, and then invoke the function like this:
Just an add-on to TT’s comment above:
You may need a shell path here (like “/Users/myName/Desktop/foo.bar”) for modern applications. Older applications may still need the old style path (like “Macintosh HD:Users:myName:Desktop:foo.bar”).
It depends on the app you call.
You can convert these path types via
POSIX path of COLONPATH -- gives UNIX path
POSIX file UNIXPATH -- gives colon type file reference
POSIX file UNIXPATH as string -- gives colon path
To clarify: When using “alias x” in a script, then you pass AbsolutePath (e.g. in the form “Macintosh HD:Users:Name:Documents:myfile.docx”). If you want to pass a POSIX path, like “/Users/Name/Documents/myfile.docx”, by using FolderItem.NativePath (but not ShellPath!!!), you’ll have to use “posix file x” in the script instead.
So no, this does not, as TE claims, depend on the App (Word vs. Finder, or what?) you call. It depends on the APIs you use (i.e. “alias” vs. “posix file” in AppleScript). Both Posix and classic HFS paths are still supported by macOS and AppleScript, so use whatever you prefer, and it’ll work with any app. If you want to stay modern, go with FolderItem.NativePath and “posix file” instead of .AbsolutePath and “alias”.
Na… I’ve seen apps which require an old path e.g. for open documents and other require a UNIX path (NativePath).
Not all apps use an “open alias foo”, it could be just “open foo” and then you need the proper path type.
My comment was just thought to the AppleScript novices to get a clue what’s wrong when it does not work as expected. In case a wrong path type is used it can be tricky to get a clue what’s wrong
TE, that’s not how AppleScript works, though. Applescript resolves the “alias x” or “posix file x” so that the app that receives the AppleEvent(!) will simply get a “file reference” parameter and then can retrieve in whichever form it requires it internally.
So, even the older or most recent app can handle both forms, I’m quite sure (I’ve developed a whole AppleScript lib with Xojo, so I know how the internals work).
Or can you give an example where this actually doesn’t work as I said?