Open Word Doc on Mac

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.

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.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

why not try just


should open the word document on either platform, UNLESS you are attempting to open INSIDE an XOJO window

[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?
OLE does not exist on Mac, so yes.

I got that other code from the forums on a search.

f.launch works on the mac!

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=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.

But then you’d get “strange results” using the OLE method on Windows if Word were not there as well.

On the old code I used I trapped an OLEException…

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.

Launch works as long as there is an app that can open the file. What file ending are you using for 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

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

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?

You need to check if the bundle id is available. This can be done with the MBS plugin with the LaunchServices. As example

FilemakerFolderitem = LaunchServicesApplicationForInfoMBS("", "", "fmp12", -1)

gives me the location of Filemaker. I think that macos-lib also should have functionality for this.

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.

You can use the function with a bundle id:

LaunchServicesFindApplicationForInfoMBS(creator as string, bundleID as string, name as string) as folderitem

You could also use a form pdf for the users to fill out.

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 ?

or use this more complete method :

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 "" 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:

OpenInWord theFile.AbsolutePath

Just an add-on to TT’s comment above:
You may need a shell path here (like “/Users/myName/Desktop/”) for modern applications. Older applications may still need the old style path (like “Macintosh”).

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?