本文主要針對用例之間的調度，和定時運行用例這兩個方向進行了介紹，其中用例之間的調度在RobotFramework平臺上直接可以實現，對定時運行用例，我們進行了Robot平臺的二次開發。
在RobotFramework里添加該資源庫文件，定義一個全局變量${turn},新建兩個用例test1和test3,Robot平臺提供了關鍵詞Run Keyword if，可以實現兩個用例之間的調度關系，如果函數（在Robot稱為關鍵字）check返回的是True則執行函數Add，否則不會執行函數Add。
【RobotFramework二次開發】 關于定時運行用例，對Robot平臺進行了二次開發，在Robot平臺的菜單欄里添加一個Tasks菜單項，點擊下拉菜單Schedule彈出設置界面。
1、該Task Schedule Dialog 可以設計定時運行用例，有兩種觸發方式，Single和Cycle（CI Trigger方式目前沒有實現），其中Cycle可以設置間隔時間，單位為hour、day、week；
2、打開Task Schedule Dialog時，自動將Robot平臺設計的用例樹放在界面的綠色區域，可以選擇單個用例或多個用例，輸入Task Name（也就是Robot平臺的tag），選定觸發方式（Single或Cycle），點擊Add按鈕添加任務；
5、點擊Start按鈕將按設置時間依次運行各用例，如圖6所示，如果用例是保存在文件夾D:python_testSofttest,，任務的運行報告自動保存在當前目錄的OutputDirN下，如果是Cycle方式會再建一層文件夾（文件夾名為任務運行時間）。
關注點：Task Schedule Dialog里的Task Name就是Robot平臺的tag，執行的過程先判斷設定時間，如果滿足條件，將Output Directory目錄下的含有該tag的所有用例都運行一次。用例執行順序和最初在Robot平臺設計的用例順序一致。
6、Robot平臺的二次開發使用方法：將FrameTask.py，mainframe.py，TaskSchedule.py，TestTree.py放在C:Python26Libsite-packagesrobotideui，覆蓋所有文件，再打開Robot就可以看到菜單項。
網站二次開發合同
甲方：
乙方：
甲方在此委托乙方進行
網站的二次開發。為明確雙方責任，經友好協商，雙方達成以下協議：
第一條：項目的內容、價款、開發進度、交付方式。
第二條：甲方的權利和義務
1.提供專人與乙方聯絡。
2.提供所有需要放到網上的資料交給乙方，并保證資料的合法性。
3.乙方在完成合同規定的義務后，甲方按照附錄一的要求，及時支付費用。
4.甲方將在著作權法的范圍內使用本合同標的及相關作品、程序、文件源碼，不得將其復制、傳播、出售或許可給其它第三方。
5.甲方對本合同標的中的網頁、圖像享有排版的版權。
6．版權所有歸甲方（包括原文件、程序、文字、動畫文件、有聲文件、及相關作品）第三條：乙方的權利和義務
1.提供專人與甲方聯絡。
2.按附錄一的要求，使用甲方資料，進行網站的二次開發。
3.在附錄一要求的期限內，完成網站的二次開發，并通知甲方進行驗收。
4.在驗收期內甲方要求下，對不合格地方進行修改。
5.乙方未經甲方同意不得向第三方拷貝或泄露網站程序。6．乙方負責維護甲方網站運營期間數據的安全。
7.在附錄一要求進行網站更新的情況下，在接到甲方要求網站更新的傳真2日內，按照要求對網站進行更新；
8.在附錄一要求進行培訓的情況下，對甲方1-3名技術人員進行培訓。第四條：驗收
1.驗收標準有以下幾條：
a.甲方可以通過任何上網的計算機訪問這個網站。
b.主頁無文字拼寫及圖片（以甲方提供的材料為準）錯誤。
c.網絡程序正常運行。
2.驗收期為5天時間。
第五條 違約責任
1.任何一方有證據表明對方已經、正在或將要違約，可以中止履行本合同，但應及時通知對方。若對方繼續不履行、履行不當或者違反本合同，該方可以解除本合同并要求對方賠償損失。
2.因不可抗力而無法承擔責任的一方，應在不可抗力發生的3 天內，及時通知另一方。
3.一方因不可抗力確實無法承擔責任，而造成損失的，不付賠償責任。本合同所稱不可抗力是指不能預見、不能克服并不能避免且對一方當事人造成重大影響的客觀事件，包括但不限于自然災害如洪水、地震、火災和風暴等以及社會事件如戰爭、**、政府行為等。
第六條 保密條款
雙方應嚴格保守在合作過程中所了解的對方的商業及技術機密，否則應對因此造成的損失承擔賠償。
第七條 以上條款如有未盡事疑，經甲、乙雙方協商后加以補充：
補充內容： 乙方需提供使用文檔，并根據使用文檔對甲方技術人員提供相關培訓等支持。并在交付后有免費代碼維護義務，并在雙方合作共贏的基礎上提供更多技術支持（比如有償的功能開發等項目）。
第八條 其它
1.如果本合同任何條款根據現行法律被確定為無效或無法實施，本合同的其他所有條款將繼續有效。此種情況下，雙方將以有效的約定替換該約定，且該有效約定應盡可能接近原約定和本合同相應的精神和宗旨。
2.附錄一規定的有效期滿，乙方未完成附錄一任務，超出期限每天扣兩百，超出期限后放棄該任務，按網站的費用雙倍賠償。
3.如乙方在期限內放棄該任務，按網站的費用雙倍賠償。3.本合同經雙方授權代表簽字并蓋章，自簽訂日起生效。
4.本合同一式兩份，雙方當事人各執一份，具有同等法律效力。
甲方（蓋章）：
乙方（蓋章）代表：
代表：
1.1 信息源選擇及規范制定
Nutch通過制定相應的URL規則來達到對限定的URL進行爬取，即過濾信息。默認情況下可以在相關的配置文件中進行配置，它用正則表達式來規范URL。當然，還可以自己編寫相應的插件等來實現所制定的URL規范。
1.2 信息預處理
這里的信息預處理是指將Nutch爬蟲所下載下來的內容轉變為Nutch索引器所能調用的文本。信息預處理過程主要涉及到如下內容：
（1）格式識別并抽取文本。一般情況下，Nutch爬蟲下載下來的文檔是HTML，但是網絡上還存在諸多類型的其他文本：txt、doc、pdf、xls、rtf等等，甚至還有多媒體的文檔格式。在進行索引之前，必然從這些下載下來的文件中抽取出文本信息，針對不同的格式文檔抽取方式也不同。Nutch默認對HTML、TXT能直接處理，而其他的有些已經實現但并沒有加載。目前有很多開源軟件可以抽取文本信息，如word文檔的poi、pdf文檔的pdf-reader等等。在二次開發時，需要對相應的文檔格式進行編寫抽取文本工具。
（2）信息過濾。這里的信息過濾是指從抽取的文本中濾去那些不希望使其存在的文本內容，這個過程也不一定是獨立的，可能會與上一個過程存在相交之處。舉個實例，比如針對某一個網站的某一部分網頁中的部分區域不希望被索引，那么可以編寫一個相關的插件來實現對這個網站的這類網頁進行過濾，去除這一區域內的內容。
（3）編碼格式的轉換。網絡上的信息編碼格式五花八門，并不是特別規范。一般情況下，Nutch處理后都能實現編碼的統一，但是有些信息卻不能很好地被默認程序轉換，這時候就應當對Nutch進行擴展，以實現編碼的轉換。
1.3 索引本土化構建
以過信息預處理后的信息可以直接為Nutch索引。在索引過程中，需要考慮的因素也有很多。一是中文類語言的分詞問題。這一點在前面實驗中已有詳細的分析并做了一些總結。二是信息的進一步處理，這一過程是在尋找最能表達原文語義的語詞集合。另外還有一些其他相關技術如詞干提取、停止詞、本體等等。這個過程是相當重要的一個過程，直接決定了查詢服務的效果。
1.4 排序規則制定
排序規則的制定并不僅僅影響到查詢結果，可以說它貫穿在了整個搜索引擎的工作過程中。因為能影響排序規則的因素有很多，比如說與用戶需求的相關性、系統業務需求等，具體的有如語詞在文獻中的詞頻、在整個文獻空間的詞頻、語詞位置等，甚至是信息時間都會影響到排序。因此在二次開發時，需要根據需求，針對性地制定排序規則，并把它反映在系統中。
1.5 查詢系統及用戶界面
Nutch的查詢系統是發布在Tomcat下的，它提供了一種類似于google的查詢界面，并且支持多語言。在實際的二次開發中，并不一定支持多種語言，可針對某一種語言進行改寫。另外還可以對查詢過程進行二次改發，改變它的查詢方式、添加分頁、增加summery等。對于用戶接口界面，則根據實際情況改寫即可。
UAP報表二次開發手冊
v.871 1.數據源定義
報表數據源可分為實體關系查詢，SQL腳本查詢和自定義查詢三個類型，如下圖所示：
圖1.1 其中數據源名稱和數據源描述是為了標識數據源以及說明數據源的功能。
1.1查看或修改現有數據源
“查看或修改現有數據源”是指對原先已經創建的數據源進行修改（系統預置的數據源不允許修改），或者可以在新建報表時選擇已存在的數據源，如下圖：
圖1.2 選“下一步”：
圖1.3 則列所有已存在的數據源，選擇其中一個，按“下一步”：
圖1.4 功能列表是數據引擎內部使用機制，直接選“下一步”：
圖1.5 這個是設置報表數據源的最后一個步驟，由于選定的數據源為自定義查詢類型，所以第一個頁簽為自定義查詢組件的相關信息（關于自定義查詢組件的具體情況，請查閱本手冊1.3單元）；第二個頁簽如下圖：
圖1.6 查詢結果列是指該數據查詢結果的具體情況，包括列名稱，列的數據類型，列的區域語言描述。這些信息將構成報表格式設計時的數據源信息（關于這部分內容的詳細情況請參閱UAP報表設計時幫助文檔）。
另一個頁簽為“過濾條件設置”，如下圖：
圖1.7 具體包括過濾條件名稱，過濾條件的區域語言描述，這個將在過濾條件的數據源下拉列表中出現，這些信息將用來設置從過濾控件讀去用戶輸入條件值來對查詢的結果進行過濾（具體情況清參閱本手冊2.2單元）。
之后，選擇“完成”即結束數據源定義而進入報表格式定義。
1.2實體關系查詢
在圖1.1步驟中選定“實體關系查詢”，點擊“下一步”則進入實體關系查詢類型的數據源定義：
圖1.8 這里必須要添加至少一個關聯實體，點擊“添加”，則可選擇系統已經定義好的實體：
圖1.9
選定實體，然后點擊“確定”：
圖1.10 點擊“下一步”（如果選擇了多個實體，則還需要定義實體之間的關系。關于如何定義一個實體以及如何定義實體之間的關系，請參閱數據引擎的相關文檔）：
圖1.11 接著必須添加結果列，即圖1.6中的“查詢結果列”。點擊“添加”：
圖1.12 這里彈出的列表為選定的單個實體或多個實體能查詢到的所有的結果列的信息。選定需要的查詢結果列后，點擊“確定”：
圖1.13 這個步驟中，“行數據權限”可以用來限制用戶查詢某些具體行數據的權限（行數據權限的設置以及其他高級功能的使用方法請查閱數據引擎相關文檔）。
1.3 SQL腳本查詢
在圖1.1步驟中選定“SQL腳本查詢”，點擊“下一步”則進入SQL腳本查詢類型的數據源定義：
圖1.14 SQL腳本查詢類型又分為SQL腳本和存儲過程兩個類別，可通過第一個頁簽的左上端的下拉列表中選擇相應的類別（具體如何定義兩種類別請查閱數據引擎相關文檔）。其他三個頁簽中，“查詢結果列”和“過濾條件設置”已經在前面的單元中說明，此處不在詳述。其中，這種數據源類型有一個“查詢參數設置”頁簽，如下圖：
圖1.15 如果腳本類型中選擇的是“存儲過程”，則此處可以使用“刷新”按鈕來獲取存儲過程所需要的參數；而SQL腳本類型則需要手動填寫參數的信息。需要注意的是，參數的名稱必須與存儲過程或SQL腳本的名稱完全一致。運行時查詢參數的具體值來源是通過過濾條件獲得的，因此查詢參數需要和過濾條件綁定在一起（綁定方法請參閱本手冊2.2單元）。
1.4 自定義查詢
自定義查詢是指提供一個COM組件（通常為VB6.0組件）或.NET組件（通常為C#組件）來提供獲取數據的方法（SQL腳本，存儲過程或數據庫臨時表）。關于自定義查詢組件的建立方法請參閱本手冊3.2單元。
在圖1.1步驟中選定“自定義查詢”，點擊“下一步”則進入自定義查詢類型的數據源定義：
圖1.16 其中數據服務信息指的是自定義組件的相關信息，關于自定義查詢組件的建立方法請參閱本手冊3.2單元。
2.報表過濾條件
2.1 過濾條件設計
除了UAP本身單獨提供了過濾條件的設計工具，報表本身也提供了專門為報表設計過濾條件的快捷方式。以下是報表設計過濾條件的入口：
圖 2.1
圖 2.2 點擊“標準條件”進入過濾條件設計器：
圖 2.3
界面說明：
是否支持高級條件：選此項后，在運行時過濾窗口中會出現“高級條件”頁簽，用于用戶自由選擇過濾條件的組合。
規則組件：此項定義由過濾控件回調的規則組件類。
是否取消二次開發：此復選項只有在以“U870”項目進入UAP時才會顯示，如果被選中，那么以其它項目進入UAP的過濾設計器不能新增和刪除過濾條件。
此處可新增或修改一個過濾條件。雙擊某個已存在的過濾條件，則進入這個條件的修改界面：
圖 2.4 界面說明：
語種：設置過濾條件項顯示的語種。
中文簡體名稱：過濾條件項的鍵值，唯一標識此過濾條件項，不能重復?？梢砸宰帜?、數字或漢字來命名。
標題：在運行時過濾窗口中顯示的文字，支持多語種設置。編輯類型：過濾條件項的類型，分別為文本框、參照、日期、數字、枚舉、SQL語句、自定義。
參照ID：當編輯類型選擇參照類型后，必須選定一個參照ID。比較符：過濾條件項比較符號。
小數位數：當編輯類型為數字類型時，此選項可以設置小數位數。分組：為過濾條件選定一個分組，在運行時將按照分組來顯示過濾條件項。
數據源：為過濾條件項選定數據源，可以下拉選擇或直接手工輸入。順序號：指定過濾條件項在運行時顯示的位置，如果不輸入，將自動產生。
是否常用條件：如果選中，將在運行時顯示在“常用”頁簽中。是否必輸：如果選中，在運行時必須輸入值，否則會出現提示信息。是否區間條件：如果選中，在運行時將顯示為兩個輸入框組合而成的形式，表示從值1到值2的意思。在運行時，用戶選擇或輸入的不是單值，而表示一個取值范圍。
是否多選：如果選中，表示此過濾條件項可以選擇多個值。
允許用戶修改比較符：如果選中，用戶在運行時可以通過濾設功能改變比較符。
作為或條件：如果選中，在運行時將以“或”條件來組合到過濾條件生成的SQL語句中，默認是以“與”條件組合的。
參照返回字段：當編輯類型為參照類型時，此選項表示參照返回的是哪個字段的值。編碼對應參照中的主鍵字段，名稱對應參照中的描述字段。也可以手工輸入要返回的字段名，一定要與參照中的字段名一致。
默認值、到：設置過濾條件項的默認值，將在運行時自動顯示。如果為區間條件，可以設置“到”默認值。
修改界面的第二個頁簽是過濾條件項窗口枚舉：
圖 2.5
界面說明：
枚舉(aa_enum)：指在U861中使用的枚舉型，此類型是在AA_Enum數據表中定義的。枚舉類型，枚舉類型名稱，是EnumType字段值。默認顯示，在運行時當用戶點擊下拉按鈕后顯示的可供選擇的項，注意是以“,”分隔的EnumCode字段的值。
枚舉類型：指明在Meta庫中的MetaEnumDef表中的枚舉，對應MetaID字段。
枚舉串：如果沒有在數據庫中預制枚舉類型，也可以通過此項輸入一個枚舉串。格式為“0{#}1{##}A{#}B”，在“{##}”前的為返回值，之后的則為顯示值，并且在返回值與顯示值中分別以“{#}”分隔。
只能定義以上三種枚舉中的一種，否則會出現提示信息。修改界面的第三個頁簽是過濾條件項窗口SQL語句：
圖 2.6
界面說明：
SQL文本框：在SQL文本框中輸入SQL語句，可以不用加別名。
標題：在運行時中顯示的列標題，標題數量與上面的SQL的字段對應，并用“,”分隔，例如“標題1,標題2”。
返回字段：用此字段的值構成過濾控件返回調用者的過濾SQL語句。顯示字段：顯示在運行時過濾窗口中的值。
在U870中，SQL語句類型的過濾條件主要為兼容以前版本，所以如果在U870中新建過濾條件時，請不要選用SQL語句類型，而改用參照類型。修改界面的第四個頁簽是過濾條件項窗口SQL語句：
圖 2.7
屬性說明：
參照樣式：當編輯類型選擇為參照類型時，可以指定參照的樣式，分別為彈出式和下拉式，默認為彈出式。
關于過濾最后值得特別指出的是，過濾條件之間可控制相互關系，例如兩個過濾條件都有參照，則可控制其中一個過濾條件的參照取值范圍由另一個過濾條件的取值來決定。此外還存在其他相關控制行為，這些功能都是通過規則組件來實現的。關于規則組件的詳細實現，請參閱過濾條件的相關文檔。
2.2 過濾條件與數據源的關系
此處主要說明如何把過濾條件跟數據源關聯起來，以達到由用戶輸入來實現查詢不同數據的目的。
對于實體關系類型的數據源，只要在過濾條件的基本屬性頁中選擇數據源的相應列就能實現，如下圖：
圖 2.8 用戶就可以在查詢報表時進行過濾：
圖 2.9
對于SQL腳本類型的數據源，無論是簡單的sql腳本類型還是存儲過程，都是通過將其參數與過濾條件進行綁定來實現的。如下圖：
圖 2.10 假如sql腳本或存儲過程中有兩個參數分別為：@planid和@filterstring，則必須要在“查詢參數設置”頁簽中分別為每一個參數設置其相關信息。然后再設計過濾條件：
圖 2.11 此處需要注意的是，“中文簡體名稱”必須以這樣的規則命名：“查詢參數設置”的參數為@pram，則“中文簡體名稱”為parm，兩者之間相差一個符號“@”。
需要指出的是雖然SQL腳本可以通過參數來綁定過濾條件，但是過濾條件綁定到參數的同時，還必須為此過濾條件指定一個數據源查詢結果列，查詢時輸入的過濾條件對該返回結果列同樣起作用。
對于自定義的數據源的過濾條件綁定與實體關系得數據源相似，但是設計者需要在自定義組件中自己處理由用戶輸入信息構成的sql串來實現對查詢結果的過濾。
3.報表系統API 3.1 自定義報表查詢入口
所謂自定義報表查詢入口指的是用UAP設計了一張自定義報表，除了默認的查詢入口：門戶->視圖->我的報表->自定義報表，另外為此報表設置單獨的菜單節點來進行查詢。只要在此節點的點擊事件處理函數中調用報表系統的以下接口就可實現：
A.Public Function OpenReport(_ sReportID As String, _ objU8Login As Object, _ Optional subid As String = “", _ Optional rawfilter As Object = Nothing)As Boolean
B.Public Function OpenReportNoneFilterUI(_
sReportID As String, _ objU8Login As Object, _ Optional subid As String = ”", _ Optional rawfilter As Object = Nothing)As Boolean
接口功能及使用說明：
這兩個接口是對象ReportService.clsReportManager中的函數;需要引用組件： ReportService.dll UFIDA.U8.UAP.Services.ReportFilterService.tlb 這兩個接口的功能是打開一張報表，兩個接口的差異在于前者在打開報表之前會先顯示過濾界面，而后者不會（例如在使用聯查報表的時候有時不需要進行過濾）。此接口在業務組在其需要打開一張報表時調用。
參數介紹： sReportID：
報表的ID，即將要打開的報表標識。objU8Login：
U8的Login對象，注意：這個對象必須是COM封裝的Login。subid： 報表所屬的子產品號，這個參數是可選的。注意：當指定了此參數，接口會在隨后的處理中按照subid[__]sReportID的規則拼接成真正的報表ID。rawfilter：
可選過濾條件對象（UFGeneralFilter.FltSrv或自定義的過濾條件對象），此對象中必須是ISelfFilter（見第四個接口）的一個實現。這個參數通常報表的自定義行為（如聯查）時，需要有過濾的情形時會使用到。
至于怎么在U8中設置自己的菜單節點，請參閱U8門戶相關文檔。
3.2 自定義數據源組件
報表的自定義數據源是指單獨寫一個組件來提供報表數據，這種數據源實現方法的優點強大的數據處理能力，這是其他類型的數據源所不具備的。實現方法為： 組件中必須實現以下接口: public interface IGetSql { void GetSql(IFilterArgs e);}
接口功能及使用說明：
此接口為報表提供自定義數據源。組件的提供方式為首先提供一個實現IGetSql的組件（COM組件只需有一個聲明相同的GetSql函數的類即可），之后將其綁定到報表的數據源（具體方法是請參考本接口示例）。組件的工作方式為報表系統會在展現報表的過程中實例化一個此種類型的對象，通過調用GetSql函數來獲取數據源。
參數介紹：
IFilterArgs參數是UFIDA.U8.UAP.Services.ReportFilterService.tlb中的類型，在報表系統調用自定義數據源組件的時通過此參數將組件需要的環境信息傳入，而自定義數據源組件則將其處理結果通過此參數返回給報表系統。
IFilterArgs中包含的常用接口： IFilterArgs.login： U8的Login對象
IFilterArgs.RawFilter： 過濾對象
IFilterArgs.DataSource.Type：
組件數據源返回類型，其值與對應類型為 0：SQL腳本 1：存儲過程 2：臨時表 其默認值為2 IFilterArgs.DataSource.Sql： SQL腳本或臨時表名稱
IFilterArgs.DataSource.StoreProcName： 存儲過程名稱 示例：
(1)以下提供一個名為CustomDataSample的vb6.0的dll，此組件中定義一個名為customData.cls類，其代碼如下（IFilterArgs的）：
Public Sub GetSql(e As IFilterArgs)e.DataSource.sql = “select * from AA_Bank” e.DataSource.Type = 0 End Sub
構造好組件之后，需要將組件綁定到報表的數據源，綁定方法如下：
假設組件名稱為：DataEngine.dll,而實現IGetSql的類型名稱為：Engine VB6.0組件的綁定方法：(注意：COM需要注冊，不要求具體存放目錄，一般推薦存放目錄為：..U8SOFTufcomsql)
圖 2.12
C#組件的綁定方法：(注意：.NET組件不需要注冊，但存放目錄必須是：..U8SOFTUAP)
圖 2.12
3.3 自定義行為組件
自定義行為是指在報表查詢結束后，設計者提供額外的功能來進行相關處理，比如聯查功能等。方法是實現以下接口：
public interface IExecute { void Execute(IActionArgs e);}
接口功能及使用說明：
此接口用來完成報表自定義行為的業務操作。組件的提供方式與IGetSql接口類似，不同的是其綁定到報表系統的過程（示例將詳細說明）。組件的工作方式為在自定義行為綁定到報表系統之后，報表展現界面的右鍵菜單中將相應的子菜單，觸發此子菜單后報表系統將實例化此組件實現IExecute類型的一個對象，并調用此對象上的Execute方法。
參數介紹：
IActionArgs是在進行自定義行為的時候數據交互的媒介，IActionArgs中的常用參數: IActionArgs.ReportID: 當前操作的報表ID IActionArgs.Login: U8的Login對象
IActionArgs.RelateData: 當前報表的相關數據對象，通過此對象中的接口GetData可獲得相關的數據
IActionArgs.CurrentColumnName:觸發自定義行為時報表所處的焦點行名稱
IActionArgs.FltArgs: IFilterArgs對象
自定義行為綁定到報表系統例子：(假設組件名為ExcuteSample，類型名為clsExc，定義方法參考IGetSql的示例)
圖 2.13
在報表設計界面點擊”自定義行為”的按鈕，將打開自定義行為的定義界面：
圖 2.14
點擊”新增”:
圖 2.15
設定ActionClass為”ExcuteSample.clsExc”, Caption為”自定義例子”,點擊”確定”即完成綁定操作。
保存之后打開報表，其右鍵菜單”其他”的子菜單中便出現定義的新菜單，圖 2.16
點擊此子菜單，便會調用類型clsExc中的Execute方法。3.4 自定義過濾
自定義過濾是指設計者可以自行構造一個過濾組件來實現報表的過濾，而不使用U8自身的過濾控件。實現方法是組建中實現以下接口：
public interface ISelfFilter { void ShowFilter(IFilterArgs e);}
接口功能及使用說明：
為報表提供自定義的過濾條件界面。組件提供方式與前述相關組件類似。組件的工作方式為將實現ISelfFilter的類型的一個實例作為OpenReport或OpenReportNoneFilterUI的第四個參數傳入，則在進行報表展現之前，報表系統將會調用此實例的ShowFilter方法，自定義過濾的結果使用e參數返回報表系統。
參數介紹：
IFilterArgs參數請參考IGetSql說明。
自定義過濾組件綁定到報表的方法例子(假設要綁定的組件名為CustomFilter，實現ISelfFilter的類型為clsFilter)：
在UAP中”報表定義”窗體的工具欄的”查詢條件”按鈕中選擇”自定義條件”，或在”報表定義”窗體的右鍵菜單的”查詢條件”菜單中選擇”自定義條件”，如圖：
圖 2.17
圖 2.18
之后再打開的定義窗體中輸入組件信息，如：
圖 2.19
點擊”確定”即可完成綁定操作。
點擊咨詢 