Blogjava中很少有關于OpenOffice.org的討論，本人做過這方面的項目現將項目中的經歷記錄下，方便自己和大家。
    上一個項目是關于OpenOffice.org二次開發的，現在那個項目已經結束了，但是對于OpenOffice.org總是有一種難以割舍，難以忘懷的心情。這可能主要是因為OpenOffice.org是SUN公司開源的,并且它最接近于個人的現實生活吧：），況且它各方面性能不差是我們在政府大力推廣正版化之后的良好替代方案,它能夠為我們極大的減少軟件支出費用，也能夠降低大家使用盜版軟件所帶來的心理上的負擔。本人強烈建議軟件開發人員使用正版軟件，如果不能的話，請使用免費軟件替代。試想自己都不能夠尊重別人的知識產權，今后我們有何理由向別人提及它、要求它呢！這不就是自己砸自己的腳嘛。
    今后我會抽空慢慢總結在做OpenOffice.org二次開發項目之中遇到的問題與經驗教訓。
    OpenOffice.org的二次開發，主要是向其添加UNO組件的形式進行的，具體而言就是向其添加UNO組件的壓縮包，這個壓縮包在OOo調用的時候又分為兩種：
    1、OOo直接調用這部分插件代碼。
    2、OOo通過其內部的腳本調用插件代碼。
由于所屬層次與調用機制不同，造成了腳本調用功能完善，但第一次執行效率較另一個低下；而直接調用速度快，但在調用OOo內部的類的時候層次有所限制。具體性能測試后腳本調用并不會滯后多少。綜其而言，通過腳本調用插件是我們的首要選擇目標。下面我來向大家簡要介紹兩種UNO包的結構及其異同：
    一：直接調用的包：
          zip--|
               |-jarName.jar
               |
               |-addons.xcu
               |-jarName.xcu

    二：腳本調用的包：
          zip--|
               |-jarName文件夾--|--jarName.jar
               |                |
               |                |--parcel-descriptor.xml
               |
               |-addons.xcu
               |
               |-META-INF--|--manifest.xml

    相同點：
       1、由于OOo現在是SUN公司主導的開源項目，所以遵循SUN公司的打包慣例UNO包使用的也是zip打包壓縮算法，這樣就極大減少了瑣碎小文件對于系統時間空間上地占用。
       2、它們都有設置OOo菜單的xcu文件，它是xml格式的配置文件。
       3、對具體的class文件都要打jar包。
    不同點：
       1、對于jar包，直接調用的需要在jar包中的MATE-INF文件夾中MANIFEST.MF文件中指出主類，而腳本調用的則不需要。
       2、對于zip包，直接調用比腳本調用多了一個xcu配置文件，這是因為它是說明OOo調用那個類開始的；而對于腳本調用，它在自己的zip包中還多加了一層文件夾包括了jar包和一個配置文件，這個名為parcel-descriptor.xml的配置文件詳細說明了OOo需要調用的類，以及用于解析腳本所用的dtd文件。
       3、直接調用的處理是從使用OOo之中的XComponentContext對象開始的，而腳本調用則是從OO中腳本調用機制傳入的XScriptContext對象啟動。XScriptContext對象所屬的層次比XComponentContext高，它能夠獲取當前編輯的文檔對象以及XComponentContext。

    這次接著說UNO組件的配置文件，該組件的配置文件是以xcu后綴名結尾的，同其他java中的配置文件一樣，它也是xml格式的文件。
    xcu配置文件的作用是對OOo插件的在OOo的菜單欄、工具欄之中指定如何定義用戶界面擴展，以及菜單被點擊后應該觸發哪個類的具體方法的指向。例子如下：
   
    該xml文件為了避免和命名沖突使用了xmlns:oor="http://openoffice.org/2001/registry"、xmlns:xs="http://www.w3.org/2001/XMLSchema"的命名空間。
    Addons.xcu是腳本調用和直接調用都要用到的文件，它的根節點為oor:component-data，在
<node oor:name="AddonUI">節點下可以設置三個不同地點顯示的信息的子節點，它們分別是
<node oor:name="OfficeMenuBar">、<node oor:name="OfficeToolBar">、
<node oor:name="OfficeHelp">，從xml文件的易讀性我們可以看出這些分別是設置菜單欄、工具欄和幫助信息的。
    用于定義加載項菜單的支持的 org.openoffice.Office.Addons集
    OfficeMenuBar   此集中定義的菜單將成為 OOo 菜單欄中的頂層菜單。
    AddonMenu       此集中定義的菜單將成為彈出式菜單，是位于工具菜單底部的“加載項”菜單項的一部分。
    模板 MenuItem 的屬性
    oor:name  字符串型。配置節點的名稱。名稱必須以 ASCII 字母字符開始。 該名稱在 Office-MenuBar 集中必須是唯一的。因此，必須使用諸如org.openoffice.<developer>.<product>.<addon name> 或com.<company>.<product>.<addon name> 之類的模式以避免產生名稱沖突。請記住，您的配置文件將合并到 OOo 配置分支中。您不知道當前安裝了哪些 加載項或者安裝了多少加載項。因此子菜單的菜單項的節點名稱在其子菜單中必須是唯一的。配置集不能保證其條目的順序，因此您應該使用字符串 + 編號（如 “m1”）這樣的模式作為排序條目時使用的名稱。
    URL       字符串型。指定用戶激活菜單條目時應該分發的命令 URL。如果 MenuItem 是子菜單的
標題，則該屬性將被忽略。要定義分隔符，您可以使用特殊的命令 URL ""private:separator。分隔符將忽略所有其他屬性。
    Title     字符串型。包含頂層菜單項的標題。 此屬性支持本地化：默認字符串（在 StarSuite 無法找到其當前語言的字符串定義時使用）使用不帶屬性的 value 元素。您可以使用xml:lang 屬性為特定語言定義字符串。為屬性指定語言/語言環境，例如<value xml:lang="en-US">string</value>。
    Target    字符串型。為命令 URL 指定目標框架。通常，加載項會使用以下某個預設的目標名稱：
                    _top   返回調用的框架的頂層框架，它是在向上遍歷分層時 isTop() 返回 true 的第一個框架。
                    _parent 返回框架分層中位于次高的框架。
                    _self   返回框架本身，其名稱與空白目標框架的名稱相同。也就是說，您正在搜索一個已經存在而且合法的框架。
                    _blank  創建新的頂層框架，其父級框架是桌面框架。
    Context    字符串型。服務名稱的列表，以逗號分隔，指定加載項菜單功能應在哪個上下文中出現。空的 Context 表示功能應該在所有上下文中出現。StarSuite 應用程序模塊使用以下服務名稱：
            Writer：com.sun.star.text.TextDocument
            Spreadsheet：com.sun.star.sheet.SpreadsheetDocument
            Presentation：com.sun.star.presentation.PresentationDocument
            Draw：com.sun.star.drawing.DrawingDocument
            Formula：com.sun.star.formula.FormulaProperties
            Chart：com.sun.star.chart.ChartDocument
            Bibliography：com.sun.star.frame.Bibliography
加載項的上下文服務名稱由綁定到框架的模型的服務名稱確定，它與 UI 元素（工具欄、菜單欄等）相關。因此，Writer 模型的服務名稱是com.sun.star.text.TextDocument。這表示，上下文名稱被綁定到應用程序模塊的模型。如果開發者實現具有模型的新桌面組件，可以將其服務名稱作為加載項 UI 項的上
下文。
    Submenu   一組MenuItem 條目。可選，用于定義菜單條目的子菜單。

    接上次講到界面擴展的配置文件，這次說直接調用和腳本調用的配置文件。
之前我說過腳本調用的包的結構為：
腳本調用的包：
          zip--|
                |-jarName文件夾--|--jarName.jar
                |                  |
                |                  |--parcel-descriptor.xml
                |
                |-addons.xcu
                |
                |-META-INF--|--manifest.xml

META-INF文件夾中manifest.xml文件的內容可能為：

    上面兩項分別是配置顯示擴展所用的Addon.xcu配置文件，和你所要添加的業務組件的zip包內所在的文件夾名，后面的類型說明標明了其類型。
    說到腳本調用，我們就應該了解OOo的腳本調用框架，ScriptingFramework 的目標在于使OOo支持地語言編寫的宏可以：
        *執行
        *顯示
        *被管理
        *被指定到 OOo 事件、組合鍵、菜單和工具欄項目
    通過部署滿足 com.sun.star.script.provider.LanguageScriptProvider 指定服務定義要求的UNO 組件，來添加新語言支持，即可實現上述目標。ScriptingFramework 通過找出滿足服務規范并遵守命名約定  “com.sun.star.script.provider.ScriptProviderFor[Language]” 的可用組件來檢測支持的語言。默認情況下，OOo 安裝了許多參考 LanguageScriptProvider。下面是OOo現在支持的語言列表：
Java            com.sun.star.script.provider.ScriptProviderForJava
JavaScript      com.sun.star.script.provider.ScriptProviderForJavaScript
BeanShell       com.sun.star.script.provider.ScriptProviderForBeanShell
Basic           com.sun.star.script.provider.ScriptProviderForBasic

所有 BeanShell、JavaScript 與 Java 宏都附帶一種類型變量
com.sun.star.script.provider.XScriptContext（可用它來訪問 OOo API）。此類型有三
種方法：
        * com.sun.star.frame.XModel getDocument(  )
    返回為其調用宏的文檔的 XModel 接口
        * com.sun.star.frame.XDesktop getDesktop(  )
    返回應用程序的 XDesktop 接口，用于訪問打開的文檔和加載文檔
        * com.sun.star.uno.XComponentContext getComponentContext(  )
    返回 XComponentContext 接口，用于創建服務實例
    根據語言的不同，宏以不同的方式訪問 XScriptContext 類型：
        *Java：傳遞到宏方法的第一個參數總是屬于類型 XScriptContext
    Xmodel xDocModel = xScriptContext.getDocument();
    因為 Java 是一種編譯語言，所以不能直接在 OOo 中將 Java 源代碼作為宏來執行。該代碼必須
先編譯，然后部署在 OOo 安裝和文檔內。
    以下步驟介紹如何使用 HelloWorld 示例代碼創建Java 宏：

1. 為宏創建一個 LemmaDialog 目錄
2. 使用 LemmaDialog源代碼創建一個 LemmaDialog.java 文件
3. 編譯 LemmaDialog.java 文件。下列來自于 OOo安裝的 program/classes 目錄的 jar 文件必須位于類路徑中：ridl.jar、unoil.jar、sandbox.jar、jurt.jar
4. 創建一個包含 LemmaDialog.class 文件的 LemmaDialog.jar 文件
5. 為宏創建一個 parcel-descriptor.xml 文件

其parcel-descriptor.xml文件如下：
第13行，說明了宏調用的具體業務代碼是LemmaDialog.jar包中的類，而且是從第10行 cn.ac.cintcm.oo.plugin.lemma.LemmaDialog.lemmaDialog這個全路徑所表示的類中的方法開始中注入XScriptContext這個參數開始的。接下來就可以調用XScriptContext的對象進行一系列的操作了。
    com.sun.star.awt中有很多與awt、swing相類似的組件可以調用，com.sun.star.beans.XPropertySet是對這些組件進行參數設置的接口。
    下次介紹有關于使用Java調用OOo具體類的業務代碼，在OOo中調用其sdk的service與我們一般編寫java代碼有一定的區別，下回大家就可明白這其中的區別了。

    前一段時間在公司一直不能夠登陸Blogjava，所以沒有時間更新博客。今天周二休息所以就繼續我的OpenOffice.org之戀吧！：）
    這次應該說Java調用OOo具體類的業務代碼了。
    OOo的技術架構設計是與平臺無關的，其構建在操作系統層之上的模塊層次除了一部分VCL庫以外，都達到了平臺無關，平臺無關是SUN的一貫作風。這部分代碼占到了整個OOo的90%以上，而那部分VCL庫平臺有關的代碼是為了直接調用各個平臺之間與GUI有關的圖形圖像組件的最小公約數。這個就像jdk中的awt/swing一樣，他們對各個操作系統都有的GUI組件進行了封裝，而對沒有的組件進行了本地模擬。swt做的正好與之相反，當然這個已經離題了：）暫不討論這些。
    OOo安裝完成以后，在${OOoPath}/program/classes目錄之下會有一些jar包存在，這些主要用于其自定義UNO組件擴展的內部類庫。我們會主要使用到如下四個類包： jurt.jar、unoil.jar、ridl.jar 與
juh.jar將其加入到我們項目的classpath之中。接下來我們就可以引用其類苦中的類來自定義我們需要的具體功能了。
        服務管理器
    UNO 引入了服務管理器的概念。服務管理器可以被視為創建服務的“工廠”。現在，只需將服務看
作可用于執行特定任務的 UNO 對象即可。稍后我們將更精確地定義術語“服務”。
例如，可以使用以下服務：
        com.sun.star.frame.Desktop
維護加載的文檔：用于加載文檔，獲得當前文檔以及訪問所有加載的文檔
        com.sun.star.configuration.ConfigurationProvider
生成對 OOo 配置（例如工具 – 選項對話框中的設置）的訪問權限
        com.sun.star.sdb.DatabaseContext
維護與 OOo 一起注冊的數據庫
        com.sun.star.system.SystemShellExecute
在當前平臺上執行為應用程序注冊的系統命令或文檔
        com.sun.star.text.GlobalSettings
管理文本文檔的全局視圖和打印設置
    這些類是以后我們能夠使用到的比較主要的類。服務的功能是其始終存在于組件上下文中。組件上下文包括創建了服務以及服務使用的其他數據的服務管理器。
我們自定義的類被視為 OOo 進程的客戶機，而此時的 OOo 是服務器。該服務器有自己的組件上下文和服務管理器，可從客戶機程序進行訪問以使用辦公軟件功能。該客戶機程序初始化 UNO，并從 OOo 進程獲得組件上下文。在內部，此初始化進程創建一個本地服務管理器，建立與一個正在運行的OOo 進程的管道連接（如有必要，則啟動一個新進程）并返回遠程組件上下文。
   com.sun.star.comp.helper.Bootstrap.bootstrap() 方法初始化 UNO，并返回一個正在運行的 OOo 進程的遠程組件上下文。而由腳本調用的UNO的方法就不是這樣初始化的啦：）
    第一個初始化步驟完成后，您可以使用組件上下文的方法   getServiceManager() 獲得OOo 進程的遠程服務管理器，這就使您可以通過 API 訪問可用的完整辦公軟件功能。
    在OOo's sdk的doc中描述各個類用的說明語言是c++，而且其使用的名稱是service而非class，這個大家注意一下。
    我們的上下文中的對象是一個軟件工件，具有您可調用的方法。使用 OOo 完成某些操作時需要對象。但從哪里獲得這些對象呢？
    新對象
    通常情況下，新對象或第一次訪問所需的對象是由 OOo 中的服務管理器創建的。在如下示例中，遠程服務管理器創建遠程 Desktop 對象，該對象用于處理 OOo 中的應用程序窗口和已加載的文檔：

    OOo中還有和我們java中的接口類似概念的interface：接口指定共同定義對象的一個方面的屬性集和方法集。
    OOo中引入接口和服務的概念是出于以下幾個原因：

1. 接口和服務將規范從實現中分離出來

    接口或服務的規范是抽象的，也就是說，它沒有定義支持某項功能的對象如何在內部實現此支持。通過 OOo API 的抽象規范，可以在 API 下分離出實現，并安裝其他實現（如果需要）。
  2. 服務名稱允許按規范名稱而不是類名稱創建實例
    在 Java  中，使用 new 運算符來創建類實例。此方法有所限制：獲得的類為硬編碼。以后您無法在不編輯代碼的情況下將其更換為其他類。服務的概念解決了這個問題。OOo 中的中心對象工廠（即全局服務管理器）被請求創建一個對象，此對象不需要被定義內部實現就可以用于特定目的。這是可以實現的，因為通過服務名稱可以從工廠定制服務，并且工廠決定返回的服務實現。獲得哪種實現沒有什么區別，因為您只使用明確定義的服務接口。

  3. 多繼承接口使細顆粒狀接口便于管理
    如果抽象接口是細顆粒狀，即小型且僅描述對象的一個方面而不是多個方面，則可以更好的重復使用。但那樣的話，就需要多個此類接口來描述一個有用的對象。一方面，多繼承接口允許具有細顆粒狀接口；另一方面，又允許通過將接口組織成集合來輕松地管理這些接口。由于在辦公軟件環境中對象很可能共享多個方面，因此，此細顆粒狀可以使接口重復使用，從而獲得行為一致的對象。例如，可以使用統一的方式來處理文字，無論處理的是正文、文字框、頁眉或頁腳文字、腳注、表格單元格還是繪圖形狀中的文字。不需要為這些不同的文字處理定義單獨的接口。

使用接口
    由于必須通過 UNO 對象的接口來訪問它們，因此會對某些語言（例如 Java ）造成影響。因為在這些語言中，只有編譯器所需的對象引用類型正確時才能從中調用方法。在 Java 中，在訪問對象實現的接口之前，通常就可以轉換對象類型。但使用 UNO 對象時是不同的：必須， UNO環境在需要訪問對象支持的接口的方法時獲得相應的引用，但編譯器對此不知情。只有這時才能安全地轉換對象類型。
Java UNO 環境含有用于此目的的 queryInterface() 方法。它看起來似乎非常復雜，但當您了解了 queryInterface() 是與跨進程安全轉換 UNO 類型相關的，就會很快習慣它。

  

    上回說到了如何在OOo之中應用其SDK所帶的類庫，這次重點說說OOo應用程序的應用環境。桌面環境由桌面對象和輔助對象組成。它通過框架 API 實現其功能。目前，框架 API 包括兩個組成部分：組件框架和分發框架。組件框架采用一種特殊的“框架 - 控制器 - 模型”模式來管理OOo 中的可視組件。分發框架處理來自 GUI 的命令請求。

    桌面環境
    com.sun.star.frame.Desktop 服務是 OOo 應用程序框架的核心管理實例。所有 OOo 應用程序窗口都按框架分層組織，框架中包含可視組件。桌面是該分層的最頂層框架。

    通過桌面管理的可視組件包括三種不同的對象：具有文檔模型和控制器的成熟辦公軟件文檔、具有控制器但無模型的組件（例如文獻目錄和數據庫瀏覽器）以及不帶啟用了 API 的控制器的簡單窗口（例如預覽窗口）。這些組件類型的相同點是 com.sun.star.lang.XComponent 接口。帶有控制器的組件也稱作辦公軟件組件，而簡單窗口組件則稱作普通組件。

    下面重點說說 OOo 中的“框架 - 控制器 - 模型”模式

    著名的“模型 - 視圖 - 控制器 (MVC)”模式有三個應用領域：文檔數據（模型）、顯示（視圖）和交互（控制器）。OOo 中的“框架 - 控制器 - 模型 (FCM)”模式也是一個類似的抽象概念。FCM 模式與 MVC 模式在某些方面是相同的，但它們的目的不同，所以最好分別處理。MVC 模式和 FCM 模式中的模型和控制器是完全不同的。

    OOo 中的 FCM 模式有三個應用領域：文檔對象（模型）、與模型的屏幕交互（控制器）以及控制器與窗口之間的聯系紐帶（框架）。

    *模型包含文檔數據，還包含多種更改數據的方法（不必使用控制器對）。在模型中，可以直接訪問文本、圖形和工作表單元格。

    *控制器掌握著文檔的當前視圖狀態并控制文檔的屏幕顯示，但是不能控制文檔數據。它監視模型的變化，并能夠通過復制使一個模型具有多個控制器。

    *框架包含模型控制器，并了解與之一起使用的窗口，但沒有窗口功能。
    FCM 的目的是使系統具備三個與可交換窗口系統配套使用的可交換部件：

    框架
    在“框架 - 控制器 - 模型”模式中，框架的主要角色是擔任可視組件和窗口系統之間的聯系紐帶。框架可以包含一個組件，或者一個組件與一個或多個子框架。構造框架時，必須使用容器窗口對框架進行初始化（使用com.sun.star.frame.XFrame:initialize()）。這種方法需要具有外圍窗口實例的com.sun.star.awt.XWindow 接口，它將成為框架的容器窗口。傳送給 initialize() 的窗口實例還必須支持 com.sun.star.awt.XTopWindow 才能成為容器窗口。支持com.sun.star.awt.XTopWindow 并不意味著容器窗口獨立于帶有標題欄和系統菜單的底層窗口系統。XTopWindow 可在需要時充當窗口，但也可以固定或根據外圍應用程序窗口而改變位置。

    將框架添加到桌面框架分層中后，桌面就成為框架的父級框架。因此，需要將桌面的com.sun.star.frame.XFramesSupplier 接口傳送給 XFrame 接口中的 setCreator() 方法。在桌面提供的 com.sun.star.frame.XFrames 接口中調用 append() 方法時，內部就會發生這一過程。

    框架中的組件
“桌面環境”一節介紹了可以插入到框架中的三種可視組件。如果組件帶有控制器和模型 （例如文檔），或者只有控制器（例如文獻目錄和數據庫瀏覽器），該組件就能實現接口com.sun.star.frame.XController 所表示的 com.sun.star.frame.Controller 功能。

    控制器
OOo 中的 控制器介于框架和文檔模型之間。這是它的基本作用，它具有 getModel() 和 getFrame() 兩個方法。getFrame() 方法提供控制器所附著的框架。getModel() 方法返回一個文檔模型，但是，如果組件沒有文檔模型，它可能返回一個空引用。

    分別從框架、控制器和模型中獲取另外兩方
    開發人員通常需要使用已加載文檔模型的控制器和框架。OOo 文檔模型的com.sun.star.frame.XModel 接口通過其 com.sun.star.frame.XController 接口獲取可以訪問框架的控制器。下圖顯示了從文檔模型中獲取控制器和框架以及從控制器或框架中獲取文檔模型的方法。從框架中獲取相應的組件和容器窗口。

 

存儲文檔
    成功加載辦公軟件組件之后，返回的接口用于操縱該組件。諸如com.sun.star.text.XTextDocument、com.sun.star.sheet.XSpreadsheetDocument 或com.sun.star.drawing.XDrawPagesSupplier 之類的文檔特定接口是通過 queryInterface() 進行檢索的。

    如果辦公軟件組件支持適用于實現 com.sun.star.document.OfficeDocument 服務的每個組件的com.sun.star.frame.XStorable 接口，則可以存儲該組件：

void store ( )
void storeAsURL ( [in] string sURL, [in] sequence< com::sun::star::beans::PropertyValue > lArguments )
void storeToURL ( [in] string sURL, [in] sequence< com::sun::star::beans::PropertyValue > lArguments )
boolean hasLocation ()
string getLocation ()
boolean isReadonly ()
    XStorable 提供的文檔存儲方法有 store()、storeAsURL() 和 storeToURL()。后兩個方法使用中間描述符進行調用。

store() 將覆蓋現有文件。對使用 private:factory/... URL 從頭開始創建的文檔調用這個方法將導致異常。其他兩個方法 storeAsURL() 和 storeToURL() 都保留原文件不動，不同之處在于存儲文檔之后。

storeToURL() 方法將當前文檔保存到指定位置，而不改變文檔的內部狀態。storeAsURL 方法將文檔的 Modified 屬性（可通過文檔的 com.sun.star.util.XModifiable 接口訪問）設置為假，并使用調用中傳送的參數更新文檔的內部中間描述符。這樣就改變了文檔的 URL。

    在保存已編輯文檔之前需要對一個 PropertyValue 數組結構體進行內容設置，

PropertyValue[] prop = new PropertyValue[1];
        prop[0] = new PropertyValue();
        prop[0].Name = "Overwrite";
        prop[0].Value = Boolean.TRUE;

事件綁定描述中的 PropertyValue 結構如下：

EventType 字符串型。可能的值為 "StarBasic" 或 "Script"。事件類型 "Script" 用URL 表示位置。事件類型 "StarBasic" 是出于兼容目的而提供的，除 URL外，它還用 Library 和 MacroName 屬性來描述宏的地址。

Script  字符串型。適用于 Script 和 StarBasic事件類型。用于描述被綁定宏/腳本例程的位置。URL 屬性需要使用命令 URL。StarBasic 將在發生事件時執行此命令。 對于事件類型 StarBasic 而言，URL 使用 macro：協議。對于事件類型Script 而言，可以使用其他協議，特別是 script：協議。macro 協議有兩種形式：macro:///<Library>.<Module>.<Method(args)>macro://./<Library>.<Module>.<Method(args)>第一種形式指向全局基本存儲器中的一個方法，第二種形式指向嵌套在當前文檔中的一個方法。Library>.<Module>.<Method(args)> 表示程序庫、模塊和方法的名稱。目前，args 只能使用字符串參數（用逗號分隔）。如果不存在參數，必須使用空括號，因為括號是方法的組成部分。下面是一個 URL 示例：macro:///MyLib.MyModule.MyMethod(foo,bar)

Library 字符串型，已不再使用。適用于 EventType "StarBasic" 事件類型。可以為其賦予"application" 值或為全局基本存儲器賦予空字符串值，為嵌套代碼的文檔賦予 "document" 值。

MacroName 字符串型，已不再使用。適用于 EventType "StarBasic" 事件類型。將宏
地址描述為 <Library>.<MyModule>.<MyMethod>。

還有些屬性，等我整理好了再補充上來：）