Mika Raento’s blog

The SDK documents E32USER-CBase 65 as

The panic is raised as a result of a call to the Pop() and PopAndDestroy() static member functions of the CleanupStack class. The panic occurs when an attempt is made to pop more items from the cleanup stack than are on the cleanup stack.

That’s not true. E32USER-CBase 65 is triggered from PopAll() or PopAndDestroyAll() if the current cleanup stack is not the one for which TRAP was called. PopAndDestroyAll() is called when you call User::Leave().

I triggered this when I had no new TRAP() around a leaving piece of code after having created a CEikonEnv, which creates a new cleanup stack.

Simple thing, but the documentation pointed me in the wrong direction so took a while to figure out.

On Win32 and other windowing systems you can walk the window tree and ask windows for their type, state, contents etc. On Symbian there is no such built-in introspection.

However, it is possible to get access to a lot of information with enough hacks:

• Use a FEP so your code gets loaded into all apps
• Use various methods (control stack, window tree, container structure) to find out about windows and controls
• Detect/Guess/hardcode the control class and use the native methods to ask it for contents

http://github.com/mikaraento/tts has a complete example. It’s the code from a project I did for a client that refused to pay in the end. Enjoy.

(note that the code is by no means complete and will for example crash on FP2 AFAIK)

This is something I guess everybody who writes a HTTP POST using MHTTPDataSupplier goes through… (at least that’s what it looks like on the forums). I didn’t find a clear answer so I thought I’d write it down myself.

GetNextDataPart() needs to return _the same buffer_ until ReleaseData() is called, and it will get called several times for the same part. If you don’t respect that the transaction will terminate with KErrCorrupt.

This slots into a project based on hello_openc

from scons_symbian import *

target     = "googletest_main"
targettype = "exe"
libraries  = ['libstdcpp', 'libc', 'euser']

# Static libs
staticlibs = ['libcrt0.lib']

uid3 = 0xA0001314

sources = ['../src/googletest_main.cpp',
           '../../../third_party/googletest/src/gtest-all.cc',
           '../../../third_party/googletest/test/gtest_unittest.cc']

includes    = ['../data', '../inc', '../../../third_party/googletest', '../../..']
sysincludes = [
  join(EPOC32_INCLUDE, "stdapis"),
  join(EPOC32_INCLUDE, "stdapis/stlport"),
  '../../../third_party/googletest/include'
]
defines     = ['_STLP_NO_WCHAR_T']

SymbianProgram( target, targettype,
    sources = sources,
    includes    = includes,
    sysincludes = sysincludes,
    libraries   = staticlibs+libraries,
    defines     = defines,
    epocstacksize = 8192,
    epocheapsize  = (0x1000,0x100000),
    uid3 = uid3,
    resources = [ "../data/googletest_main_reg.rss" ]
)

BTW, for running tests that use UI in the emulator you want to wait for the emulator to start up some more than it has by the time you hit your main(). Use something like

void WaitForMenuExe() {
#ifdef __WINS__
  scoped_ptr<TFullName> fulln(new TFullName);
  TUint32 menu_uid = 0x101f4cd2;
  while(true) {
    TFindProcess find;
    while (find.Next(*fulln) == KErrNone) {
      RProcess p;
      p.Open(find);
      if (p.SecureId().iId == menu_uid) {
        p.Close();
        return;
      }
      p.Close();
    }
    User::After(10 * 1000);
  }
#endif  // __WINS__
}

Leak checking is part of good programming practice (as leaked objects normally point to bugs in general). Symbian has its leak checking macros, but they aren’t completely trivial to use with Googletest (googletest has been designed with a whole-program reachability-based leak checker in mind, like OS X’s ‘leaks’) – googletest itself allocates memory in some cases.

The easiest way to add Symbian-style leak checking is to use a test fixture. Just add an instance of HeapChecker as the first member of your test fixture. HeapChecker looks like:

Header:

#ifndef TESTING_PUBLIC_HEAPCHECK_H_INCLUDED_
#define TESTING_PUBLIC_HEAPCHECK_H_INCLUDED_

#include "third_party/googletest/include/gtest/gtest.h"

// HeapChecker is a scoped object that checks whether any memory has been
// leaked over its lifetime. It is used together with googletest test fixtures:
// it checks whether the test had any failures which cause allocations and
// in that case doesn't do the checking. It is meant to be held as
// the first member of a test fixture.
class HeapChecker {
 public:
  HeapChecker(testing::Test* test);
  ~HeapChecker();

 private:
  testing::Test* test_;
  int alloc_count_;
};

Code:

#include "testing/public/heapcheck.h"

#include <e32std.h>
#include <ecom/ecom.h>

#include "third_party/googletest/include/gtest/gtest.h"

namespace {
bool any_failures = false;
}

HeapChecker::HeapChecker(testing::Test* test) : test_(test) {
  if (any_failures) return;
  User::__DbgMarkStart(EFalse /* aKernel */);
  alloc_count_ = User::Heap().Count();
}

HeapChecker::~HeapChecker() {
  REComSession::FinalClose();
  if (any_failures) return;
  TInt ignore_alloc_count = 0;
  if (test_->HasFailure()) {
    ignore_alloc_count = User::Heap().Count() - alloc_count_;
  }
  User::__DbgMarkEnd(EFalse /* aKernel */, ignore_alloc_count);
  if (test_->HasFailure()) {
    any_failures = true;
  }
}

Using a base test fixture for all your tests is good practice, as it’s the best way to insert custom checks – the actual test runner in Googletest doesn’t have (enough) hooks.

Googlemock – arguably the best C++ mocking framework now works on Symbian (winscw and gcc-e – I haven’t tried rvct). Although I’m obviously biased I really recommend it for all your mocking needs. Requires a recent OpenC.

If you have problems getting everything working on Symbian I’d be interested in hearing them – here or via e-mail.

Automated UI testing is annoying in general and Symbian doesn’t really provide anything to make it easier. There are many aspects to testing UIs, but one is testing the actual drawing and layout. A necessary conditions for such tests is the ability to exercise drawing code and capture the drawn output in a test.

Symbian programming – automated UI tests shows how to create a fully functioning application environment – CAknEnv (CEikonEnv), CAknAppUi (CEikAppUi) – in your unit test so that you can instantiate a CCoeControl-derived class and how to capture the control’s output to a bitmap and from there into a file.

I was one of the very first round of Forum Nokia Champions in 2006. Last year (in the autumn of 2008) I was not re-selected, which is pretty understandable as I had not done anything externally visible since joining Google at that point.

Since then we actually launched Google Latitude and open sourced the Jaiku S60 client which were enough to win membership once again.

I finally updated the Symbian Programming pages for 3rd edition. The major update is that the source code pointers now point at the Jaiku S60 client (rather than the old ContextPhone sources), which is fully ported to 3rd ed.

After all the griping over the years I have to admit that things have gotten significantly better. Most of the article updates consisted of adding ‘This is now a documented and supported platform feature, see this [Forum Nokia wiki page]‘. Which is neat.