S60 Open to new features

A new feature for Carbide v2.0 is the remote connections UI framework. The framework allows Carbide users to create remote connection data objects that are stored in the workspace, can be exported and imported, and can be shared among multiple instances of use (for now, on-device launch configurations).
One of the benefits is that once a remote connection object is created and its data is specified, it can be named and reused without having to specify the data again. Another is that if the data changes, all uses of that object pick up the change. Finally, the active status of services over the connection can be seen at any time.

Debugging multiple processes at once in Carbide can be a little tricky but this is an area where we're making some improvements for 2.0. When you are using the emulator then Carbide is really debugging epoc.exe and not the individual Symbian OS processes. So if you terminate debugging one of the processes you'll take down the entire emulator. But when debugging on a real phone then you can terminate each process individually.

You can also right-click on a process in the debug view and "Terminal/Disconnect All". This will take everything down but we've discovered a couple issues with this command that we still need to fix for Carbide 2.0, so for now I recommend terminating each process individually.

Last week we took a slight detour in our development cycle to spend time with an Agile consultant Pete Behren of Trailridge Consulting, to help us improve our understanding and implementation of our Agile process. From my viewpoint it was amazingly successful and the chance to get an independent assessment of our progress.

When we started the Agile process a year ago we had only a single day of training and some book reading to get started. These new efforts were first seen during the Carbide 1.3 development cycle which led to more frequent beta releases, improved communication with our customers via the opening of our Bugzilla bug database, nightly builds for faster feedback on bug resolution, and a host of internal process changes that made things more efficient, more reproducible, and more accountable. Even with all the changes behind the scenes Carbide 1.3 was easily the least stressful release we had ever produced.

Needless to say, we were hooked.

One thing that can confuse some users that are new to Eclipse and Carbide.c++ is the concept of the workspace and how Carbide.c++ makes use of it. Adding to this confusion can be the root directory concept along with some of its limitations, so I figured I would create a screencast for this. So without further delay, take a look at this introduction to these concepts:

You can find this and other videos at: http://wiki.forum.nokia.com/index.php/Carbide_Training_Videos

Got ideas for screencasts you'd like to see? Leave us some feedback here and we'll get on it!

I've been working with Ravi to plug a hole in our debugger use cases for Carbide 2.0: usually if you start a debug session in Carbide it will determine what executables you are interested in and let you set breakpoints there. But what if you decide you want to debug additional DLLs after a debug session has started? You can't do this in Carbide 1.3 without terminating the debug session and starting over again. In Carbide 2.0 you can now import additional DLLs (dragging them into the Executables View is easiest) in the midst of a debug session and then set breakpoints etc. This makes it easier to enlarge the scope of the debug session without having to terminate the while thing, import the new DLLs and then start debugging again.

My work this week on Carbide 2.0 was focused on cleaning up problems dealing with executable files. Several people had reported cases where their executables remained locked after a debug session. I was able to reproduce at least one of them and put a fix into the next nightly build.

I also cleaned up an assortment of minor issues with the Executables View and added a "Remove" button to let you easily remove executable files you import for debugging. You can only remove the ones you import since the others reflect the files generated by the projects in your workspace.

Eclipse contains a host of features and sometimes finding what you want is pretty obscure and simply searching the help may not be, ahem, helpful. As an example, bug #7457 describes a lack of regular expression help in the Find/Replace dialog. It's actually there but not if you look in the Keys preference panel or search the Eclipse documentation.

Here's what to look for and how it works.

With some customers already taking a look at the Milestone 1 release for v2.0, we are getting some questions about licensing errors. The Carbide.c++ Licenses folder is currently blank when you download the tool and this is what will cause the problem.

For now, the current tool will accept v1.3 licenses. We have also posted a temp license on the main page of the Google Group. Here is a link:

http://groups.google.com/group/carbide_cpp-v2-beta/web/license-PRO-Sept.lic

To install the license:

Open up the IDE,
Click Help -> Carbide Licenses -> Install License
Then paste the contents of the license file.

In Carbide 1.3 we picked up a new feature from CDT that had been missed by CodeWarrior users when moving to Carbide: the ability to right-click on a variable and view memory. This week I revisited an issue that also came up with CodeWarrior: what happens when you "View Memory" on a variable that's stored in a register?

Ordinarily we assume you want to look at the chunk of memory were the variable's value is stored. We find out where it is located and open a memory monitor on that address. This does the what you would want in most cases except when the compiler has used a register to store the variable's value. In Carbide 1.3 you get an obscure error message if you attempt to view memory on a variable in a register. For Carbide 2.0 I could have just cleaned up the error message but recalled that when we had this issue when CodeWarrior we fixed it to use the value in the register as the memory location. This isn't completely consistent with how we treat other variables but at least does something more useful than display an error.

We are closing in on the release of Carbide.c++ v2.0M1 to begin public testing. As those of you in software development know this is an exciting, exhausting, and terrifying time as everyone involved works to make sure that the first public revealing of a new product release goes smoothly.

We have several exciting improvements for you to delve into, not the least of which is our update of Carbide to use the latest Eclipse 3.4 and CDT 5.0 Ganymede releases for Carbide.c++ 2.0. Lots of basic platform and C/C++ improvements should make for an exciting release.