Symbian開發(fā)中的若干問題轉帖

本貼以后做為一些小問題的解決方案帖，遇到問題能夠通過網絡簡單解決的問題會不定期的來這里更新下，給自己和有同樣問題的人留個Mark：

在bld.inf和mmp中判斷SDK平臺版本

有時候工程中不同的SDK需要在bld.inf中選擇不同的mmp，抑或不同的SDK需要在mmp中包含不同的路徑。這種需求想必做跨SDK平臺開發(fā)的人應該會遇到的，那么該如何解決呢？

我們知道類似__S60_50__和__SERIES60_3X__之類的宏，在bld.inf和mmp中是無法使用的，那么又該如何操作呢？有個大德從makefile的原理出發(fā)，為我們解決了這個問題，詳情可以參閱如下連接的日志描述

http://www.devdiv.net/space.php?uid=8511&do=blog&id=1010

他提到的方法是純從makefile原理出發(fā)的，相對來說高深了不少了，受后面回帖中的啟發(fā)，可以比較各個平臺SDK中Epoc32\include\variant\下的hrh文件（一般都是symbian_os.hrh文件），從而假如有不同的宏定義，就可以拿來用了，基于這個原理人家發(fā)現(xiàn)了3rd版本和5th版本SDK之間可以使用一個宏SYMBIAN_C32_SERCOMMS_V2。

受它的啟發(fā)，我發(fā)現(xiàn)在新的Symbian ^3 SDK中epoc32\include\variant路徑上多了一個platform_paths.hrh，而我們在^3SDK編譯環(huán)境下，必須在mmp中增加新的頭文件包含路徑APP_LAYER_SYSTEMINCLUDE，而宏APP_LAYER_SYSTEMINCLUDE正好在platform_paths.hrh定義的，所以我們要把工程在^3版本SDK和其他SDK區(qū)分的時候，只要使用這個宏就可以了。形式可以采用如下一些示例

//bld.inf

#ifdef APP_LAYER_SYSTEMINCLUDE

Rp*_X3.mmp

#else

Rp*_v5.mmp

#endif

//*.mmp

#ifdef APP_LAYER_SYSTEMINCLUDE

APP_LAYER_SYSTEMINCLUDE

#endif

//.cpp

#ifdef APP_LAYER_SYSTEMINCLUDE

#include <es_enum_partner.h>

#endif

bldmake error directory epoc32 does not exist

安裝好Nokia 的開發(fā)環(huán)境后，運行hello world 應用即出現(xiàn)如下問題：

bldmake error directory...\epoc32 does not exist

在網上查了半天，多半是需要重新安裝SDK。其實，SDK和Carbide完全可以裝在不同的分區(qū)。關鍵問題是你工作的workspace在哪。我的情況是:

hello工程位于C:\Symbian\Carbide\workspace，

而SDK在D:\S60\devices\Nokia_N97_SDK_v0.5\epoc32。

后來，我發(fā)現(xiàn)Carbide的File>Switch workspace菜單中顯示當前的workspace指向D:\Develop\mobile\Symbian\Carbide\workspace。當我試圖指向真實的workspace，即：C:\Symbian\Carbide\workspace，Carbide再次顯示時，上述菜單中就根本沒有該workspace。于是，我將workspace 復制到D盤，即：D:\Symbian\Carbide\workspace ，然后切換到該workspace,build成功！

結論：通過上述問題，明白了其實SDK和Carbide都不是說一定要裝在C盤，但是工程文件和Workspace必須在同一個目錄。

Symbian編譯時的Error -1073741819錯誤

完整錯誤信息類似下面這樣：

make[1]: *** [\Symbian\9.2\S60_3rd_FP1_2\EPOC32\BUILD\...\Gif_Reader.o] Error -1073741819

make[1]: *** Waiting for unfinished jobs….

make[1]: *** Waiting for unfinished jobs….

make[1]: *** Waiting for unfinished jobs….

make: *** [TARGETMGATE] Error 2

這只是在整個過程中的一部分出現(xiàn)，最后提示還是***Build Complete，carbide的problems里也沒有任何對應的代碼位置提示，很容易誤解成sdk或這編譯器壞了，網上有人說重裝sdk，有人說clean一遍項目。其實這是由于代碼里寫了一些貌似合法但實際不對的寫法，舉個具體的例子就是拿對象類型的變量強制轉換成指針使用，比如

CCoeControl& iParent;

((CTestAppView*)iParent)->foo();

這樣，就會導致這種build錯誤。

小結：這種問題很難查，壓根不好找原因，后來還是從以下博客看到的http://blog.k-res.net/?p=625

新手求助 關于Esock_client 14錯誤

我看了網上關于這個錯誤的介紹是說 描述符類型問題。但是我這個錯誤 感覺好像跟描述符的大小有關，代碼如下 ：

    HBufC8* iRecvData;

    void SendDataJabber::RecvInfoL()

    {

        TBuf8<367> buf;

        TRequestStatus status(KRequestPending);

        iSocket.Recv(buf, 0, status);

        User::WaitForRequest(status);

        User::LeaveIfError(status.Int());

        delete iRecvData;

        iRecvData = NULL;

        iRecvData = buf.Alloc();

    }

如果buf長度設為365的話，會正常進行。如果超過365在waitfor這里就會無響應，如果去掉waitfor，就會報出這個Esock_clinet14錯誤。我不太明白難道socket接收還會限定長度嗎？

希望有前輩指點。

其實這個問題，像我們這種從事Symbian已經兩三年的人確實不敢犯的，但是我們現(xiàn)在跨平臺實現(xiàn)，需要使用外部buffer，那該如何使用AO的異步，下面是我采用的方案：

在類內聲明成員變量

TPtr8 *iTempBuf;

在Recv的AO中使用類似如下代碼

iTempBuf = new TPtr8(iBuf, iLen);

iSocket.RecvOneOrMore(*iTempBuf, 0, iStatus, iDummyLength);

否則局部變量在異步的recv操作中必然會引發(fā)

Timer in Symbian Development

（1）TTime::HomeTime() / TTime::UniversalTime()

最常見的時間獲取手段，精度不高；因涉及一定的運算過程，效率較低。適用于需要以常規(guī)“年月日時分秒”方式使用時間的場合。在EKA2平臺下，其精度與低階系統(tǒng)時鐘（Nanokernel Timer）一致，通常為微妙級別。通過 HAL::Get(HAL::ENanoTickPeriod, result) 可以獲的具體精度。

注意：它們使用的是系統(tǒng)時間，這是可以被其它進程修改的。

（2）User::TickCount()

傳統(tǒng)的Tick計數器，精度通常僅為1/64秒（可能隨硬件有差異），適用于精度要求較低的場合。通過 HAL::Get(HAL::ESystemTickPeriod, result) 可以獲得具體精度。

注意：在休眠（Standby）狀態(tài)下，TickCount將停止計數，所以User::TickCount()在休眠狀態(tài)下將“損失”計時！

（3）User::NTickCount()

低階系統(tǒng)時鐘（Nanokernel Timer），通常提供微妙級Tick。通過 HAL::Get(HAL::ENanoTickPeriod, result) 可以獲得具體精度。

注意：Symbian OS 6.x 沒有此API。與TickCount不同的是，User::NTickCount()在休眠狀態(tài)下不“損失”計時。

精度為微妙級，但是函數返回時毫秒級的數值。

（4）User::FastCounter()

返回值類似于Tick，提供Symbian OS所能支持的最高精度，通常比TTime::HomeTime()更準確。（如果硬件不支持high resolution timer，則毫秒級時鐘替代）而且，因為它采用快速的exec call讀取一個硬件寄存器的數值，效率很高。通過 HAL::Get(HALData::EFastCounterFrequency, result) 可以獲得其具體精度。

注意：在每次終端從休眠狀態(tài)激活后，它將同步至正確的數值，也就是說User::FastCounter()在休眠狀態(tài)下其實也是不“損失”計時的。

另外，User::After(), CPeriodic也會在休眠狀態(tài)下“損失”計時，所以在手機這種特殊的應用環(huán)境中，需要特別注意不同定時器在“休眠”狀態(tài)下計時的差異。

Carbide C++中SBSv1與SBSv2的區(qū)別

自從上次裝了個Symbian ^3 0.9的SDK之后，一次導入工程的時候發(fā)現(xiàn)Carbide編譯器彈出如下的選項

一時茫然不知道該如何選擇，百度一下，找到如下鏈接

http://hi.baidu.com/71167609/blog/item/654f71443e607b8cb2b7dc92.html

內容如下

SBSv2 only works with recent versions of Symbian OS9.5. Both SBSv1 and SBSv2 are GNU make based build systems. SBSv1 uses Perl to generate make files, while SBSv2 uses Python. Select the appropriate builder for your project. When building for SBSv2, the builder will set EPOCROOT to the absolute path (including drive letter) to the kit for the active build configuration. It will also add the path to the sbs bin directory to the start of the PATH variable. This is derived from the SBS_HOME environment variable. For SBSv2, all build configurations (platform/target), including the built-in platforms (WISNCW, ARMV5), are declared in xml files in the \sbs\lib\config directory. The Build Configurations selection page will display only those kits known to support SBSv2.

目前而言，我覺得還是選擇SBSv1好些。

This Project does not support program "BUILD_HELP" for platform "GCCE"

使用Carbide C++ 2.3以上的版本，用向導生成一個新的工程中，有時編譯時會碰到如題中的錯誤提示。這個錯誤的原因是Carbide中的一個bug，有時會把文件的路徑中的“\”改成“/”，比如，

inf文件中正確的路徑應該如下：

..\help\build_help.mk

但是Carbide C++向導中生成的錯誤路徑如下：

../help/build_help.mk

碰到如題中的錯誤時，只要把路徑中的“/”改成“\”就可以了。

導入工程編譯時遇到"strict subs"報錯問題

在導入第三方編寫的工程時，如果遇到類似如下報錯

Bareword "GCCE" not allowed while "strict subs" in use at \Symbian\9.1\S60_3rd_MR\EPOC32\BUILD\Symbian\Carbide\lab\SMSExample\group\/Platform.pm line 14.

Bareword "GCCE" not allowed while "strict subs" in use at \Symbian\9.1\S60_3rd_MR\EPOC32\BUILD\Symbian\Carbide\lab\SMSExample\group\/Platform.pm line 29.

Compilation failed in require at C:\Symbian\9.1\S60_3rd_MR\epoc32\tools/ABLD.PL line 161.

BEGIN failed--compilation aborted at C:\Symbian\9.1\S60_3rd_MR\epoc32\tools/ABLD.PL line 161.

通常是因為bld.inf文件中缺少PRJ_PLATFORMS項的內容導致，默認情況下可以加入如下代碼解決

PRJ_PLATFORMS

DEFAULT

使用RSendAs報LaunchEditor kern-exec 3錯誤

由于習慣了用MTm來編輯和發(fā)送短信，所以對于其它方式不太習慣，目前有個項目需要使用到手機自帶的短信編輯器發(fā)已經定稿短信內容但是沒有定收件人的情況，在使用如下代碼時，剛開始用的好好的，結果在E72上報LaunchEditor kern-exec 3錯誤。

       RSendAs sendAs;

       User::LeaveIfError(sendAs.Connect());

       CleanupClosePushL(sendAs);

       RSendAsMessage sendAsMessage;

       sendAsMessage.CreateL(sendAs, KSenduiMtmSmsUid);

       CleanupClosePushL(sendAsMessage);

       sendAsMessage.SetBodyTextL(aText);

       sendAsMessage.LaunchEditorAndCloseL();

       CleanupStack::Pop();        //sendAsMessage

       CleanupStack::PopAndDestroy();        //sendAs

最后通過論壇搜索到，帖子說“所有FP1 和5th手機上均正常，而在E72,6720,6730和5630等手機上只是把消息悄悄放到了草稿箱而不是打開短信編輯界面”，我查看了下，的確是這樣的，草稿箱創(chuàng)建了好多這種短信哦。那為什么在Symbian S60 3^rdFP2的機子上都會有這個蹊蹺的問題呢，沒有跟蹤源碼不知道，不過跟蹤到又能怎么辦，為此還是聽高人說

“RSendAsMessage在5th中增加了設置編碼的函數，但是據反應無效果。所以RSendAsMessage這個API無論在哪個平臺，對于中文使用者來說，都不應是首選。

使用CSendUi吧，兼容性更好一點。但是要注意把CSendUi的實例作為成員變量使用，否則有些機型上會沒效果。

RSendAsMessage出現(xiàn)無效果的情況，可以也將其作為成員變量試試。”

其實本人經過測試使用RSendAsMessage做為成員變量依然無效，而CSendUi不用成員變量也是可行的，具體代碼如下

       CSendUi* sendAppUi = CSendUi::NewLC();

       CMessageData* message = CMessageData::NewLC();

       CParaFormatLayer* paraFormatLayer = CParaFormatLayer::NewL();

       CleanupStack::PushL(paraFormatLayer);

       CCharFormatLayer* charFormatLayer = CCharFormatLayer::NewL();

       CleanupStack::PushL(charFormatLayer);

       CRichText* messageBodyContent = CRichText::NewL(paraFormatLayer,

           charFormatLayer);

       CleanupStack::PushL(messageBodyContent);

       messageBodyContent->InsertL(0, aText);

       message->SetBodyTextL(messageBodyContent);

       sendAppUi->CreateAndSendMessageL(KSenduiMtmSmsUid, message, KNullUid,

           EFalse);

       CleanupStack::PopAndDestroy(messageBodyContent);

       CleanupStack::PopAndDestroy(charFormatLayer);

       CleanupStack::PopAndDestroy(paraFormatLayer);

       CleanupStack::PopAndDestroy(message);

       CleanupStack::PopAndDestroy(sendAppUi);

如何區(qū)分安裝和卸載

有些程序會有一個需求即安裝和卸載的時候分別做不同的操作，簡單的控制，可以通過將兩個不同操作分別封裝于兩個后臺exe程序中，將這兩個exe程序在PKG中分別用“FR,RI”和“FR,RR”來標記前者安裝時操作，后者卸載時操作。

但是這樣并非一帆風順，因為覆蓋安裝的時候，雖然不會執(zhí)行帶“FR,RI”標記的程序，但是會執(zhí)行帶“FR,RR”標記的程序，這個時候假如不影響操作的話，那就無所謂，假如需要做到區(qū)分的話，那就需要用到如何區(qū)分安裝和卸載的知識點——Symbian (Check Install)判斷安裝程序是安裝還是卸載。

可以參看如下鏈接的信息

http://wiki.forum.nokia.com/index.php/TSS000468_-_Receiving_notifications_for_installation_events

顯然在3rd上，可以通過該方法來實現(xiàn)區(qū)分安裝和卸載。根據之前的經歷，這種應該是使用PS方式實現(xiàn)的，不過我們這里不用考慮實時監(jiān)控，所以直接調用如下代碼就可以了。

    TInt instStatus = -1;

    User::LeaveIfError(RProperty::Get(KUidSystemCategory,

        KSAUidSoftwareInstallKeyValue, instStatus));

    vBuf.Copy(_L("instStatus =0x"));

    vBuf.AppendNum(instStatus, EHex);

    .........

    TInt appUid;

    User::LeaveIfError(RProperty::Get(KUidSystemCategory, KUidSwiLatestInstallation, appUid));

    vBuf.Copy(_L("instAppUid =0x"));

    vBuf.AppendNum(appUid, EHex);

    .........

需要包含如下兩個頭文件

#include <e32property.h>

#include <sacls.h>

在3rd上測試基本上是正確的，可以用如下枚舉值直接進行比較。

    enum TInstOp

    {

        EInstOpNone = 0x00000000,

        EInstOpInstall = 0x00000001,

        EInstOpUninstall = 0x00000002,

        EInstOpRestore = 0x00000004

    };

    enum TInstOpStatus

    {

        EInstOpStatusNone = 0x00000000,

        EInstOpStatusSuccess = 0x00000100,

        EInstOpStatusAborted = 0x00000200

    };

不過測試中也遇到過一次0x202，所以判斷安裝和卸載，直接跟2進行比較的方法有點欠科學，最好還是位與一下進行比較的更合適些。