Quite many people found the message “Missing Separator Error” when building GCCE target. Usually this happens because the path to GNU CSL ARM compiler is not correct. The line that causes the problem is usually generated by cl_bpabi.pm, in sub GCCLibPath. The subroutine will try to execute this:

arm-none-symbianelf-g++ -print-libgcc-file-name

to find the path to GCC include files.

So in case anyone else is having the same “missing separator. Stop”,
just check if you can run:

arm-none-symbianelf-g++

If you can not run it, then somehow “arm-none-symbianelf-g++.exe” is not
on the path or the path that you set in the system is wrong/mistyped.

After using Carbide C++ for about 8 months, I think Carbide is not so bad. For my main open source project (Symbian bible), I still prefer Linux with my custom Makefile. The good thing about Carbide is that you can easily debug your project in the emulator. This is still impossible to do in Linux. For the commercial version (Professional onward) you can even debug on the device.

For the commercial version, the GUI designer is quite OK for many kinds of applications. You can create dialogs in minutes which usually takes hours. The GUI designer will not be too useful if you are building games, or applications that only have one view (”one screen”). The GUI designer is extremely useful for developing application with many data forms. As for the advanced features like performance tools or tools for the OEM, I have never tried it.

So is Carbide C++ for you? This tool is useful at least for one thing: debugging using emulator. If you need to do on device debugging or designing many applications with many data forms, the it might be useful for you to upgrade to the non free version. For me, I think I will do most of my project using the command line. If I can do debugging or use the emulator in Linux, then I would probably use Linux.

I was seriously considering buying a professional license to Carbide C++, but now I am not sure anymore. C++BuilderX 1.5 Mobile Edition was a great product by Borland, or at least is was going to be great, but the decided not to continue with it. With the Carbide C++ professional edition (and with C++BuilderX mobile)  I can develop simple GUI for Symbian very quickly. Building a GUI in Symbian involved editing resource files, and writing many classes.

I am a bit disappointed with many bugs in Carbide 1.2. The bugs are also inconsistent, so I can’t get myself used to it. Sometimes the GUI editor spits out error messages, and it is not clear on how to workaround it. Most of the time, I can not find an easy way to add an event handler. The default action for a view is to exit from an application, and there is no easy way to override the action.

I thinkI am going to write more, once I use this thing more.

When I released my utility: LogExport, I didn’t think that many people will use it, but I was happily surprised to know that many people use it, and give comments on my blog. LogExport is just a very simple application, it reads your call/sms log, and export them to a CSV file. In this post, I will explain the inner working of LogExport.

LogExport uses Symbian API to access the call log (the classes are: CLogClient, CLogFilter, and CLogViewEvent). Because there might be many entries, I must use Active Object and progress bar to show the export progress. Nothing fancy here, but to find format of each field, I needed to do some experiments (e.g: does the field contains a comma, if so it must be escaped to display properly in CSV). I also need to find the event type for Wifi, which was not documented when I wrote the app (I don’t know whether they have document it now), The value of event.EventType().iUid should be 0×1000595F for Wifi.

You can download the source code here.

RBuf is an interesting descriptor class introduced in Symbian 8.0. Based on RBuf, Penrillian has created RStringBuf which provides functions very similar to the other descriptors - but which manages its own memory allocation for all the common string operations (e.g. no need to extend the descriptor manually for Append or Insert).

I am currently rewriting the rendering engine for my Symbianbible, and I need a class that is similar to RStringBuf. My bible reader supports multiple Symbian platform (UIQ 2, UIQ 3, Series 60, Series 60 3rd edition, Series 80, Series 90) so I can’t use the RStringBuf from Penrillian since it depends on RBuf.

Rather than rewriting RStringBuf from scratch using existing descriptor, I decided to write my own RBuf class that is similar to Symbian’s RBuf. It is not difficult, since the source codes of other descriptors implementation are available in file UC_DES16.CPP and UC_DES8.CPP on old EPOC SDK (although it is incomplete). I only implemented the RBuf16, but implementing RBuf8 would not be so different.

You can download my implementation here: RStringBuf_1_1.zip

I have ported S60Dict to 3rd edition. There is no special steps involved in porting this program since it does not use any strange stuff. You can download the source code and binary from: http://tinyhack.com/freewarelist/s603rd/2007/02/26/s60dict-for-3rd-edition/.

The easiest way to learn about the descriptor is trough the equivalent code in C. In this post, I will write a short comparison, this article is inspired by the explanation about Symbian Descriptor on the the Professional Symbian Programming (I said inspired, my explanation is different, and the code in the copy of the book that I have is sometimes incorrect). In this part I will talk only about constant/immutable strings.

In C, if you define something like this:

static const char hellorom[] = "hello";

Then the string “hello” will be on a non-modifyable memory space (may be in ROM or RAM, but it can not be modified).

The equivalent code in Symbian is:

_LIT(KHelloROM, "hello");

Everything is still easy to understand here: you can not modify the contents of KHelloROM or hellorom. Something to note is that in Symbian the string is not NULL terminated, the length of the string is recorded in KHelloROM.

Now, in C, you can also have a pointer to the same location:

const char *helloptr = hellorom;

We can have that in Symbian:

TPtrC helloPtr(KHelloROM);

helloPtr contains a pointer to KHelloROM, and the length of the descriptor pointed by that pointer. You may think it is a bit strange: why do we need to store the length again?. The reason is that we can have a pointer to the first n part of the string, like this:

TPtrC ptr2(KHelloROM().Ptr(), 2);

If you try to display/print ptr2, it will say the string “he”.
Continue reading »

On Series 60 3rd edition, pressing the END key will kill your application instead of bringing it to the background. In some applications, this behaviour is unwanted (e.g: Instant Messaging application), and the old behaviour is preferred.

To handle the END key, you can create a method HandleWsEvent, and intercept the KAknUidValueEndKeyCloseEvent, you can save the state of the of the app then exit, or saving the application state then go to background, or just go to background.

#ifdef __SERIES60_30__
void CS60BibleAppUi::HandleWsEventL (const TWsEvent &aEvent, CCoeControl *aDestination)
{
  
switch (aEvent.Type()) {
        case KAknUidValueEndKeyCloseEvent:
        {
            /*do something, like saving the state.
If you want your program to exit, call  CAknAppUi::HandleWsEventL(aEvent, aDestination);*/
            break; /*or just go to background*/
        }
        default:
        {
            CAknAppUi::HandleWsEventL(aEvent, aDestination);
        }
    }
}
#endif


S60 3rd edition phones comes with different screen size (unlike thre previous editions that has fixed size screen or has a compatibility screen mode), so you must make your code resizeable, and some series 60 phones can have their orientation changed (by twisting the phone).

In your AppUI class, add HandleResourceChangeL method:

void CS60BibleAppUi::HandleResourceChangeL(TInt aType)
{
     CAknAppUi::HandleResourceChangeL( aType );
     if ( aType == KEikDynamicLayoutVariantSwitch )
     {
         /*call sizechanged on all views*/
         iSettingView->SizeChanged();
         iKeyBindingView->SizeChanged();
     }
}

Continue reading »

Building the target for the phone is easy like the previous versions:

abld build gcce urel

But building for the Windows target is not so easy, you can use Carbide, or set your environment correctly. To use carbide, you can import your bld.inf, and just click on build. To use command line build, you can follow the instruction at http://www.sciabarra.com/blog/ or check out Webkit, and run build -e > env.bat (but adjust the EPOCROOT to the correct value, which is usually “C:\Symbian\9.1\S60_3rd_MR_X”, where X is the revision number).

You need to modify the package file, you can see the sample files included on the SDK, here is a list that you must change:

1. Change target uid for 3rd edition: 0×101F7961
2. EXE and DLL should go to \sys\bin (flat, all exe and dll goes here), not \system\apps\appname anymore
3. Place resource files in \resource\apps\
4. Registration files should go to: \private\10003a3f\import\apps\

Creating the package file is easy, just type: makesis filename.pkg

Create certificate file (see the SDK, you can copy paste the command line), and sign your application:

signsis s60biblev3.sis s60biblev3.sis symbianbible.cer symbianbible.key password


OK, you are ready to install your application.

In your source code the macro __SERIES60_30__ is defined, you can use this to create a portable code. Ok, lets start changing the code (this is the essential part of the source code change, you should ).

The most important change is in the function E32Dll, you must change it to E32Main:

#ifdef __SERIES60_30__
GLDEF_C TInt E32Main()
{
    return EikStart::RunApplication( NewApplication );
}
# else
GLDEF_C TInt E32Dll( TDllReason )
{
     return KErrNone;
}
#endif


but you must include this header:

#ifdef __SERIES60_30__
#include <eikstart .h>
#endif

Continue reading »

I have always wanted to write this, but never had the time to do it. Porting to Series 60 3rd edition is quite easy, if you have designed your application correctly, but takes quite some time because of the details. There are applications that will be hard to port (those that “hacks” the system) because of the new security model, but for most applications, porting to 3rd edition is quite easy.

First you need to create a new bld.inf and MMP file, usually you just need to change the target to WINSCW GCCE and add gnumakefile icons.mk if you are planning to use SVG icon (I think you should, and this article assumes that you are). Its rather difficult to explain the contents of icons.mk, just copy from the Series 60 Examples, and edit the svg filename. You can create the SVG icon using InkScape (free).

Change the MMP file as follows:

1. Change target type to EXE
2. Name the target file from name.app to name.exe
3. Map your old uid from 1xxxxxxx range to Fxxxxxx range, i.e change the first hex from 1 to F (or request a new one from www.symbiansigned.com)
4. Change the stack size just in case it is not enough for you, add epocstacksize 0x5000. If your application needs large amount of heap, change also the epocheapsize.
5. If your application needs special capabilites, add CAPABILITY

Continue reading »

Someone just lend me a Nokia 7710 for the development of Symbian bible. Nokia 7710 is the only phone on the Series 90, and is the last Symbian UI from Nokia that has not been supported by Symbian Bible. Porting to this platform is quite easy since it has almos the same concept with the Series 80, I only need to change a small amount of code to get it working.

The difficult part is how to get everything works comfortably for the user. Using Nokia 9300, in full screen mode I can still access the CBA using the hardware key, but on Nokia 7710 this is impossible (the CBA is virtual). My solution was to move some the CBA functionality (goto verse and history) to button A and B (the did not document this button, the code is EStdKeyDevice4 and EStdKeyDevice5), and to togle fullscreen I use the Escape Key (the right bottom button, the keycode is EStdKeyEscape).

You must also be careful if you are using the joystick on the Nokia 9300, the scan code for the center/fire key on the Nokia 7710 corresponds to the right joystick key on Nokia 9300 (i was surpised because hitting the fire key advances the verse one line ahead).

I haven’t looked at this bug very far, but when I load Gulim font (a Chinese font without latin glyphs, I converted it from a free font on the Internet), the messaging application does not display anything when I open a message (the list is fine). After I tested pasting Chinese bible text from S60Bible, I noticed that the messaging application is using the gulim font (so I can see the Chinese txt).

I am loading the font using this code:

for (TInt i = 0; i < entries->Count(); ++i)
{
Int id = 0;
tmpFontPath.Copy(KFontDir);
tmpFontPath.Append((*entries)[i].iName);
CEikonEnv::Static()->screendevice ()->AddFile(tmpFontPath, id);
}


Can it be because of the ID (I am just starting from 0). If I can change a font for other application, can I change the system font?

I will try to solve this later at home.

Update: This is the problem:

http://www3.symbian.com/faq.nsf/0/BA5F628A350FBFEB80257336001D0C68?OpenDocument

I was wondering why did the Nokia 7710 emulator and the real device shows the small icon (25×20) instead ofthe large icon (64×50) on the Desk. It took me a while to realize that my image size is 64×51 instead of 64×50, and it seems that the application launcher (or Desk), doesn’t like that size, and picks up the next “correct” size.

Actually this is a bit offtopic for this blog, but I’ll write it anyway. I liked my Nokia E61, the screen is a lot wider and has more colors than my previous phones, and I can get a free DivX player for this device (actually almost any S60 devices are supported now) from http://mobile.divx.com/login/ (registration needed).

In Windows, to Encode a DVD to be viewed on the device, I use DVDx (with XVid Codec that you can download from http://sourceforge.net/projects/ffdshow. This program is very easy to use, and it is quite fast.

In Mac (I am using Mac OS X Intel/MacBook), I use Handbrake” to rip the DVD, but I still don’t know why it wont play on the mobile DivX player. The solution is to convert the resulting file using ffmpeg.

To encode almost any movie format, including the output of Handbrake (I have only tried MOV, MP4, WMV and AVI tough), just type:


ffmpeg -i inputfilename.avi -vcodec xvid -b 256 -acodec mp3 -ab 64 -s 320x240 outputname.avi


And you get a playable file for the E61, and for those of you who don’t know, you can select ‘Data Transfer’ instead of PC Suite to transfer data directly to the memory card (this works on Mac OS X also).

A very kind person who wish to remain anonymous has donated me a Nokia 9300 so I can port S60Bible to S80Bible, this was my first attempt to port an application from Series 60 to Series 80. So how difficult the port was?

Surprisingly, porting to Series 80 is not as hard as I thought it would. First you must get your self used to the SDK (which is almost 100% the same with Series 60 SDK). Few weeks before, I had a project with my friend to create an application to post news on the go from Nokia 9500 Communicator, so I am already getting used to the SDK and tools.

Second, you must rewrite the application user interface (you did separate your engine from the user interface right?). This is not as difficult as it sound because Series 80 has more APIs compared with Series 60, for example I don’t have to rewrite Color selection dialog because it is already a standard in Series 80. I don’t have to make the application search for bible files automatically because user can open them using file selection dialog.

Series 80 has a wide screen to display dialogs. Most of the Views on Series 60 can be transformed into dialogs which uses less code since you don’t have to create containers classes.

Of course not everything is so smooth, some functions are not available in Series 80 (for example the AknUtils class is not available) and you must rewrite those functions. If you are drawing directly to the screen, you also need to use offscreen bitmap in Series 80 to prevent flicker. In fullscreen mode you can feel the flickr, which is strange since i have no problem with Series 60 even on the 3rd edition which also has large screen (Nokia E61).

Here are some lessons learned from the porting process:
Continue reading »

After almost two years since my last post, I decided to come back and write my experience programming Symbian devices. I have ported my open source project S60Bible to Series 80 and Series 60 version 3, and have gained some experiences to share, and hopefully this time I will post regularly.

When i began to blog on this site, i planned to write some short tutorial so people can get started coding symbian without having to read a lot of documentation. But writing tutorials turns out to be quite boring, and i never can get a tutorial done without a deadline (like the one i’ve done for a magazine). Well, lets just see whether i’m going to write another tutorial or not.

I’ve never had any problem with the old gcc compiler that is used in the Symbian SDK, but i also never noticed that it was a very old compiler from 1998. But fortunately there are a group of people which is nice enough to create a new version of gcc compiler for ARM/THUMB based on gcc version 3.0.

And here is the link to the Symbian GCC Improvement Project: http://sed.inf.u-szeged.hu/symbian-gcc/index.php

I’ve tried the compiler, and its working fine. The only small difference that i encounter is that some warnings are printed about the absence of newline on the end of the file (unlike the previous version that gives no warning). None of my applications are big enough or slow enough for testing the code savings or the code improvement of the new compiler, but i think the gcc 3.0 is much better than the previous version.