在pb中匯入*.sr*檔案時,老是出錯,總是提示少這個,缺那個,怎麼辦?
PB-IDE不同於其他的IDE,其他的如c++等ide均不是Just-In-Time 編譯的,所以直到點編譯時間才會提示錯誤行;而PB不同,一旦有錯誤就無法匯入和儲存入庫。
*大家注意到IDE中debug部分的小人表徵圖,一點它就可以馬上運行程式,其原理也在於在PBL中已經存在一份通過及時編譯而產生的二進位,這也是Just-In-Time 編譯的好處。
在做sr匯入時這個問題尤甚。那如何正確匯入呢?
PB匯入需要檢驗幾個方面:1.祖先是否存在?2.外部參考的對象是否存在(當然還包括它的祖先)?3.文法是否正確?
*為什麼存在問題1,2呢,因為1就是自身的type,2,就是變數或者控制項的type;在oop中,如果無祖先,那自己這一級什麼也不是;3就好理解,就是Just-In-Time 編譯攔住你不讓你把有錯誤的檔案往裡面import。在從低版本匯入到高版本時也存在這個問題,因為文法有改動。當然高版本也可以匯入低版本,前提是修正其文法的不同之處。
在做反編譯匯入時,遇到的最大問題就是:1.匯入順序你不知道先後,上述問題1,2,就成為攔住你的首要問題,當然如果存在語法錯誤,而祖先均存在,會即刻提示,但是它是不成功的,必須在外部修正文法後,才能重新匯入。
當然解決的方法有兩個:
1. 如果使用PB反編譯大師 PB DeCompiler來匯入,它會輸出全域對象按繼承和引用分析時產生的順序列表(這個工具如何排定順序呢,其實就是在分析時,遇到非系統內部定義的類型[如window,commandbutton]之外的類型,如my_toolbar時,它就將自己暫時壓入棧,並提出my_toolbar這個對象來分析,而分析my_toolbar時也是如此,假設它的祖先是my_toolbar_ancestor,就必須等待my_toolbar_ancestor分析完先,大概的意義就是繼承自系統內部基類的對象我們必須先分析,再分析後繼的對象,直到全部分析完所有對象,取得所有對象的公用介面[properties
and functions]後,才能開始分析代碼並還原代碼,可見,反編譯工具的工作量和複雜性是相當的),你可以參考,但是因為對象太多,比如15個PBD,或者甚至80個PBD,你是很難從sr這種方式來匯入完成一個巨型項目的。所以要恢複工程,首選的是直接匯出PBL+Pbw+Pbt方式,然後optmize,然後再full-build方式,這是最快的最簡單的方式。
當然發覺部分對象存在問題時,或者你有部分sr比如未丟失,有備份等,可以在1這種方式完成後,匯入,因為其他對象已經存在,所以不會提示缺少祖先。
2. 缺少祖先等提示,這個問題不是簡單可以通過調整匯入順序來搞定的,因為對象的繼承和引用何其複雜,sr當時本身也是用來做少量對象在不同工程和檔案之間輸入和輸出之用,並非用於全部的整體項目匯入和匯出,除非,它關閉Just-In-Time 編譯!所以如果pbl中存在要匯入對象的祖先或者是引用的外部對象的話,那匯入時就非常正確而無任何提示,做法:
a。新增一個pbw,新增一個pbt,比如預設是abc.apl。
b。然後附加其原工程的所有的pbd上來,這樣該工程其實就有了各個對象的public介面。然後首先將反編譯的apl源碼,粘貼到建立立的abc.apl的source edit中,儲存,無誤後關閉。
c。建立pbl,名字和原來的pbd一致,或者有所區分,如inv.pbl,然後往裡面匯入inv.pbd中的sr檔案,此時,應該是不會報錯了,有錯的話,可能是一些語法錯誤,sr匯入方式,需要你的sr準確無誤,所以需要你在IDE外修正。當然方法也不是沒有,那就是建立一個對象,然後在source edit中粘貼,儲存,報錯的話,按提示位置修正,因為在ide中修正時有編譯器提示,比在外部用記事本修正那是要容易得多。
3. 當然如上2的方法也用於巨型工程的逐步恢複,因為pbd很多,很難避免反編譯的錯誤,致使IDE載入時崩潰,這時,就可以先附加PBD到工程中,再逐步附加PBL上來編譯,逐個擊破。走一點曲線方式來完成。亦或是只需要恢複少數幾個pbl,也是採用如上2的方式,因為沒必要全部的PBL都來編譯,徒自增加難度。
以上操作如有錯誤敬請指正。