I'm trying to get a Mac Word faux-plugin to work and I'm running into a few weird issues. Sorry - wall of text incoming!
I realize I'm touching on the intersection of several voodoo topics here, so please bear with me.
We've got...
- Microsoft Word 2011 Mac
- AppleScript
- AppleScript-Obj-C
... trying to fake a plug-in. Which I realize is absolutely not supported.
My setup:
- OS: macOS El Capitan, Xcode 7
- Word: 2011 (most recent patches)
End of day, the plugin manipulates Word field codes. It creates and edits them. There's a super simple UI to do things like this them and then under the hood the create/update/delete functionality is in various classes.
Theory is:
- Export Word AppleScript headers with sdef, then create Obj-C interfaces using sdp (Scripting Bridge)
- In some cases where that's just broken (
find, for example), bridge to AppleScript with AppleScript-Objective-C - Write Obj-C methods and view controllers to present user with controls
Running through XCode unit tests I've actually got everything working. Hosting through an external dummy app, all works well, too. But what I'd really love to do is have this embedded into Word.
So I looked at two similar, but different options for doing that:
- Deploy as framework, call into Framework by referencing a public C interface (via VBA)
- Deploy as framework, call through AppleScript (via VBA...)
They're close, but... not quite right.
Option 1 - Framework w/ C Interface
With this approach, you create public C interfaces into your framework and use those to create view controllers. You reference the framework in Word and can call out to the public C methods. Because your framework is more directly hosted by Word, you have to compile it as 32-bit.
Steps:
- Create a .m file in your framework and expose public methods for accessing your UI (EX: "MyLibOpenCustomUI").
- Reference your framework in VBA
- VBA Macro (OpenOurCustomUI) messages your public C interface
Private Declare Sub MyLibOpenCustomUI Lib "/Library/Frameworks/MyFramework.framework/MyFramework" ()
Sub OpenOurCustomUI()
Call MyLibOpenCustomUI
End Sub
Issues:
This worked well, but for a serious issue with Word field codes. The behavior is incredibly inconsistent.
- Attempting to access a field's fieldText (aka "data" from Windows) will frequently return
data parameter is nil. The entry_index, range, and other components all seem to be fine. For whatever reason, fieldText appears to be inaccessible.
NSLog(@"fieldText : %@", [field fieldText]);//data parameter is nil
- On those occasions when you can access fieldText (it's still unclear to me how/why this occasionally works), the fieldText is "corrupted" after exactly 256 characters. I can only say "corrupted" as the text appears to go from ascii text to some form of unicode characters and also appears to be truncated after that.
EX: (Then : after "Name" is at position 256)
"Name":䜽芟㘱瑵飯ﶿṼﶿ璒澗瑸瑵ᕻ各
Thinking this could be odd behavior with the AppleScript-Objective-C bits when running via the external framework, I actually tried to call out to AppleScript from Objective-C (embed applescript, write wrapper in Obj-C, then load script at runtime).
Something like this... it just attempts to return the field text for a given field (by numeric index)
on getFieldDataForFieldAtIndex:theIndex
set theIndex to theIndex as integer
tell application "Microsoft Word"
set theField to field theIndex of active document
return field text of theField
end tell
return missing value
end getFieldDataForFieldAtIndex:
This gave me a more interesting error:
Microsoft Word got an error: Can’t get active document. (error -1728)
So - no dice. When it does work I get "corrupt" string responses. But more times than not I just can't get at the fieldText.
I have absolutely no idea why this is failing and at this point I have to believe it's got to do with how the framework is interacting with Word when launched like this. Which stinks, really. I'd love for this to work.
Option 2 - Framework w/ osascript + AppleScript
With this approach, you use vba to call osascript to call out to an applescript that hosts your UI (I know... I know...). You compile your framework as 64-bit.
In this version, Word fields work fine - strings look great and all field fieldText properties can be accessed and set without issue.
Steps:
- Reference popen in VBA
- VBA Macro (OpenMyUI)
- Calls osascript
- Which calls AppleScript (OpenMyUI.scpt) to call public method "show me the interface" in your framework
Private Declare Function popen Lib "libc.dylib" (ByVal command As String, ByVal mode As String) As Long
Sub OpenMyUI()
'this works from the VBA debugger
'I _cannot_ get it to work from the VBA when launched from a button in a document...
'window closes immediately w/o input
Dim scriptToRun As String
Dim output As String
Dim command As String
command = "osascript ~/Library/Application\ Scripts/com.microsoft.Word/OpenMyUI.scpt"
output = popen(command, "r")
'If you want this to stick around, you have to do something like...
'MsgBox "stick around, window"
End Sub
--reference our framework
use framework "/Library/Frameworks/MyFramework.framework"
property theWindowLauncher : class "MyWindowLauncher"
on openMyUI(arg)
set theReturn to theWindowLauncher's openUpdateOutput
return theReturn
end openSettings
return openMyUI(1)
Issues:
There are two biggies:
- When you invoke the sub via a button click, etc., the UI disappears or never presents. Unless you subsequently call something like "MsgBox 'something'" in VBA. Then it appears. But the behavior is odd - if you don't focus on the custom UI window before closing the dialog box, then the custom UI disappears.
- Bigger than that, the window (at least on my machine) became globally modal. Which I've never seen before. That's definitely not good.
What's odd is this works well through the Word VBA debugger. Works perfectly, actually. Just not when you run it by calling the sub directly from a Macro (like on a button click).
Very, very close on both options. Just not close enough. I'm particularly stumped by the fieldText weirdness.
So... I'm wondering. Any creative ideas on how to proceed? I realize what I'm doing here is well past the bounds of "good idea," but I'd love to see this work.
