Symbian Developer site is back with a bang.

Yes that's my post ;).

I returned to the Symbian Foundation Developer Forum (http://developer.symbian.org now!) after a long time. And the changes to the site is shocking. The graphics though weird, add a carnival like atmosphere to the site. For the first time I felt that the stiff upper lips have loosened a bit at Symbian and there is certainly a change.
There's lot of catching up that needs to be done, so am going back to the SF developer site. Catch you there. :)

Forum Nokia - Remote Device Access(RDA) shortcut added.

Forum Nokia Remote Device Access(RDA) is a very useful service. But finding the exact link can be a real task. So am adding a shortcut here on the blog, so that it can be easily accessed. For people reading this is the link to Forum Nokia - Remote Device Access.

Nice little paper on Symbian panics.

Just wanted to share an informative white paper on the Symbian panics by the MacroBug guys. Not surprisingly, it mentions that KERN-EXEC 3 was the most common error that they faced while developing a phone.But they also mention that it was the most easiest to fix!! You can read the whole paper out here.

RConnection::Attach needs TConnectionInfo!!!

I had been fighting it out for some time to get the disconnection up and working. I had tried all the steps mentioned at various forum posts and wiki, but the first step of attaching to a connection would never succeed and would always return KErrCouldNotConnect(-34), which was always a mystery to me. Checking all the documentation and capabilities alike I just could not figure out what the problem was. Then I saw an old post on NewLC.com which mentioned that the RConnction::Attach needed TConnectionInfo instead of the TConnectionInfoV2 as is shown in the SDK documentation in the following location.

» Symbian OS v9.2 » Symbian OS guide » Comms infrastructure » Using Sockets Server (ESOCK) » Using Sockets Client » Connection Management » Connection Management overview

So remember this tip and save loads of time :).

Why ...

..isn't there a function like RFs::FileExists() / RFs::FolderExists() ? ..does the S60 emulator take so long to load?? ..is setting item interface so minimal?? ..is the desired setting item type always missing?? ..does RInteger have static functions NewL instead of having simple Create or Open functions,the way other 'R' classes have?? .. to be continued.

"(command-line defines):: identifier expected" error fix.

As you can see postings here at Symbiangeek have been scarce. The work load is taking a toll and the only thing now I can blog is the errors that I get during Symbian C++ programming :( . Well the error in question was this pathetic, completely misleading error:

(command-line defines):12: identifier expected

This is the error code reported in Carbide.c++ while building a background exe. Anyways the culprit turned out to be, the macro declaration in the project mmp.

MACRO MYMACRO 1

To remove this error just corect this macro declaration to:

MACRO MYMACRO=1

Well, thats it from my side. Ciao.

Solving KERN-EXEC 3 : a few more tips

After seeing the feedback on the KERN-EXEC3 solving blog post, it became clear that it was time to post a more elaborate post to help fix those elusive KERN-EXEC 3 (we will call them KE3's)panic. So here are some more detailed pointers to fix the KE3 issue:
1. If you have any member variables which are pointers to objects owned externally,try to convert them to references so as to avoid deleting them accidentally. This is more of a tip to avoid KE3 rather than to fix them.

class CMyClass {
private:
 //CMemVarNotOwnedByMe* iMemVar;
 // Better to have a ref to an externally owned object.
 CMemVarNotOwnedByMe& iMemVar;
};

If having references is not possible, a note of such member variables should be made in the class declarations.

class CMyClass {
private:
#warning ("DO NOT DELETE CMyClass::iMemVar ") 
  CMemVarNotOwnedByMe* iMemVar;
};

2. Double deletion of pointers will lead to KE3. So you need to be sure as to who owns a particular object.

AknsUtils::CreateBitmapL() // Transfers the CFbsBitmap ownership to the caller
CGulIcon::Bitmap() // Does not transfer CFbsBitmap ownership, unless bitmaps are externally owned

So while the bitmap returned by AknsUtils::CreateBitmapL() needs to be deleted, deleting the one returned by CGulIcon::Bitmap() will cause a KE3 in cases where the bitmap is not set to be externally owned.

3.Setting TPtr's to pointers which deref to NULL is a sure shot recipe for KE3's.

 char* charPtr = NULL;
 TPtr8 tPtr((unsigned char*)charPtr,10);
 tPtr.Append(TChar('a'));// Here you have a KE3!!!

So a NULL check before setting the pointers would be a good decision.

4. When an application runs out of memory it gives an OOM, but when it runs out of stack space then it would usually be seen as a KE3. A GUI application would usually get around 80kb of stack space, if you try to put a huge variable like a big TBuf or something, then the code will KE3.

 const int KGreaterThanThreadStack = 100*1024;
 TBuf stackBuf;

While this code will work on the emulator, it will cause a KE3 on the actual device at the point when the function where this variable is declared. If such a variable is to be used, then better allocate it on the heap.

5. In UIQ 3.0 devices it is reported that while loading a dialog ,switching a view or selecting a menu, the application crashes with KE3. The solution to it would be to increase the stack size. So if something is working perfectly in UIQ 3.0 emulator and under nearly the same circumstances(all needed resources & settings file needed present) it's crashing with a KE3 on the device, then increasing the stack size could be one of the solutions.

6. While porting code from other platforms, the usage of stack especially would need to be checked. Just too many or too big stack variables would cause a KE3, which can be agonizingly hard to figure out. So while porting code, if it's giving a KE3, then do try increasing the stack size.

7. Other things to cross-check once would include a check of the destructor code to ensure that all of the "only" owned objects are destroyed properly.

8. CApSettingsHandler::RunSettingsL can also crash with a KE3 if the application stack size is not enough!!. So the remedy is to add the following line to your application's mmp.

// Doing this specifically for CApSettingsHandler else it can give a KERN-EXEC 3
EPOCSTACKSIZE   0x5000

I have tried to cover as many scenarios as possible ,but if you have come across some other scenario which caused a KE3, please do mail me or reply to this post.I would surely add that scenario as well with the essential credits.
Please let us know if this post was useful or not.

Also do check out : Getting the maximum stack & heap memories for application.

S60 5th Edition SDK v1.0, Language packs and extension plug-ins released.

Nokia released a v1.0 of the S60 5th edition SDK which is the latest version of the SDK after v0.9. In addition to the SDK a Arabic and Urdu language pack and an 5th edition SDK plug-in also has been released.
S60 5th Edition SDK v1.0 for Symbian OS can be found here.
Extensions Plug-ins for S60 3rd Edition and S60 5th Edition SDKs for S50 3rd edition FP2 and 5th edition SDK can be found here.
Language Plug-ins for S60 SDKs for Symbian OS for S50 3rd edition FP2 and 5th edition SDK can be found here.