Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.

Running the emulator from Carbide.c++

From Wiki
Jump to: navigation, search
Article Metadata
Created: ltomuta (25 Sep 2008)
Last edited: hamishwillee (04 Nov 2012)

In Carbide.c++ (or later), when you first click the Run or Debug button you are prompted to choose the way your application is going to be run.

Here are the options:


If you chose the "Emulator", Carbide.c++ will start epoc.exe and you will debug your application as "hosted" by the emulator. You will have to start the application yourself, from its shell icon and you can then stop it at any time without the emulator itself closing.

If you chose your application, it would be that exe that would be started and it will in turn cause the emulator to start. The application is already running as soon as the emulator is fully loaded and you can get to it by using the task switcher. However, as soon as you close the application, the emulator itself closes.

Don't worry if you have missed that dialog, you can edit your options later, here's how the run/debug configuration should look in each of the cases.

The "Emulator" setup:


The "Application" setup:


The same configuration options are available for both Run and Debug modes. Here are some of the implications of your choice:

Run configuration's implications

The "Application" mode is the default one (earlier versions of Carbide.c++ don't really give you an option), so for a Carbide.c++ beginner this is most likely the most common run mode.

As mentioned before, in the "Application" mode the emulator shuts down as the developer closes the application or if application's main thread panics. The later could explain why the emulator appears not to be able to start when launched from Carbide.c++. It also means that you will not be able to see the panic code as the emulator is no longer there to show you the Extended panic code.

Also to consider that the application is started very early so there might be problems if it tries to access a server which cannot yet start.

Debug configuration's implications

A frequent question that arises in a developer's mind is "Why can't I modify my application and then resume the debugging without having to restart the emulator?"

The minimal requirement for being able to recompile the application is that you stop its execution so that the binary can be replaced with the new version. However, as discussed above, in the "Application" configuration the emulator gets closed as soon as you close the application.

On the other hand, this problem does not exist in the "Emulator" mode. If this is the configuration is selected the following Debug scenario is possible:

  • Set breakpoints in your code as needed then hit the Debug button (or F11)
Carbide.c++ switches into the Debug perspective and the emulator gets started
  • Navigate in browser's shell Menu and start your application, debug it as needed
  • Then you have learned where the problem is, exit the application through its usual exit point (e.g. Options -> Exit)
The emulator is still running
  • Change Carbide.c++ to its "Carbide C/C++" perspective
  • Modify the code as needed and recompile
All should go OK unless you have made changes that require the resources to be rebuilt, that would require the emulator to be restarted
  • Switch back to the Debug perspective of Carbide.c++ and then start the application in the emulator
The breakpoints are still valid and you can again debug your application.

See also How to debug with emulator on the fly

This page was last modified on 4 November 2012, at 23:45.
73 page views in the last 30 days.