|
» Subscribe » Favorite Links » What is S60? » Freeware & Trials » S60 devices » Hints and tips » About this blog |
» Blognotes (15) » Bugs and Workarounds (4) » Build tools (5) » Carbide.c++ 1.1 (4) » Carbide.c++ 1.2 (8) » Carbide.c++ 1.3.x (9) » Carbide.c++ 2.0.x (12) » Carbide Plug-Ins (4) » CodeWarrior (2) » FAQ (6) » Future directions (25) » General (48) » Off-topic (5) » On-device debugging (13) » Performance Investigator (2) » Product features (18) » Product releases (16) » Screencast (14) » Support (36) » Tool setup (6) » UI Designer (8) » Usability (18) » Work in Progress (14) » Write-build-debug (4) |
|
» Tracing in Carbide C++ » How the Capability Scanner Works » Show All Variables » EclipseCon - tank of ideas for Carbide! » New tool, new license. |
|
Subscribe to RSS feed For email notification, please click here » |
This is one of the subjects that we like to talk the least. Historically s60 and Symbian programmers had a lot of Printf statements in their code for code coverage and we tried to steer them away from doing it toward debugging with TRK or stop-mode JTAG debugging. But frankly, there are timing problems that can't be solved with debugging; this is where Tracing comes to plate, since it can provide precise info with the timestamps on code execution. Not to mention programmer's desire to reap rewards from the investment in previously instrumented code.
Nokia has hardware-assisted tools that help in getting the tracing info from an s60 target and internal developers are quite familiar with it. Unfortunately these tools are not available for third party s60 and Symbian (UIQ, MOAP) developers.
So what can Carbide provide to these developers and not require them to buy expensive tracing hardware/software solutions? Right now the only solution is run-time gathering of tracing info (printfs) while debugging with TRK. For this users have to enable "View unframed messages from communication port" option in the 'Debugger' tab of their TRK launch configuration and start a new debug session. This solution is rather limited since TRK simply listens on the output port and redirects the messages to the console within Carbide. It is up to the developers to insert timing and other application info into the output data. The info inside trace output console of Carbide can't be sorted, grouped or manipulated in any other way. Also it assumes that TRK is running on target and will not be suitable for tracing that precedes TRK launch. I would like to improve this functionality and was looking into what else is already available for other third party Symbian developers.
One tracing solution that I discovered is utrace/btrace provided by Symbian:
To summarize it Symbian provides APIs and a plug-in tool that helps developers to instrument code, then users build their apps and run it on device. The output file is generated in Symbian file system, which users have to transfer to PC and view in an editor of their choice. Now, we could make some Carbide plugins that would simplify the transfer of the file for viewing into Carbide and add the sorting/graphing/analysis to the imported data or even create a direct link to the target and display run-time updates, based on the updated tracing into.
There are other less featured facilities in Symbian framework that provide tracing support, like flogger library. But since they don't provide nothing more then we already have with TRK tracing capabilities I will not discuss it here.
If you use tracing extensively in your work and can provide any other ideas we would really appreciate it.
Mike Trujillo just posted a demo of how to use the capability scanner. If you've not used this feature before this is a pretty good (and short) video tutorial to check out. The Capability Scanner is currently supported on all S60 3rd edition SDKs. If you want to know how it works behind the scenes read on...
When debugging your app in Carbide we will show your variables and their values so you can see how things are working. But there are some subtleties about which variables we show that can occasionally be confusing.
Carbide will usually show you the variables in a function that are live and in scope. That means we don’t show variables from other sub-scopes within the function: so if you have used a variable named “I” in multiple for-loops within a functions we will only show the one that is relevant. Also the compiler may reuse storage space for a local variable and the value won’t make any sense so we don’t show those either.
This normally works well but we’re only able to determine the list of relevant variables because if information left by the compiler. In some rare cases all of the compilers we use in Carbide can make mistakes and exclude variables that you want to see. To work around these miscues we added an option to show all of the local variables, even ones that may be redundant or confusing.
With this option on you will see all of the variables including the multiple “I”s and ones that may no longer have accurate values.
Most of the Carbide features are based on direct customer feedback. In more rare occasions we take some risks and implement something that is not what customer tells us he wants but rather us being proactive and implementing a feature that we think would be beneficial. Some of these features are generated in internal discussions, studying industry trends and competition. Once a year an Eclipse Conference event is taking place in Santa Clara, Ca.
http://www.eclipsecon.org/2008/
This year I got a chance to go. And I would greatly recommend it to anyone who is doing open source development or simply looking for some ideas. First day of the conference is probably the most useful; it has 4 2-hour tutorials. The next 3 days are general talks and bird of feathers (general discussion about a particular field of Eclipse development) in the evening. Somehow the conference is structured so that the most interesting/useful info is in the beginning of the conference and then it kind of tapers off. I was pretty overwhelmed by all the tutorials, talks and the amount of information I received at the conference. 3 days would really suffice :) Beside useful info that one would learn at the conference, which I will discuss in detail in the future posts, it is a great place to meet people who are genuinely passionate at what they do; check out the competition; get info on the latest industry trends from the industry leaders and familiarize yourself with some of the latest features coming into Eclipse that will be available in Carbide sometime later this year or early next year.
Probably the most interesting announcement that was made at the conference is that Microsoft is working hard to get interoperability between Eclipse plugins and Visual Studio. The way I understand it is that we will be able to take Carbide plugins and drop them into Visual Studio and it should work. I would really simplify Nokia's task of maintaining two versions of Carbide (Eclipse based and Visual Studio based).
I personally met couple Microsoft employees and personally think that they can be trusted :) Another important thing that we can’t take advantage of but maybe you can is Rich Client Applications – a growing field where one would use all Eclipse infrastructures minus IDE menus to create custom applications and then run it on any platform (Windows, Symbian, and Linux).
PS. If you check out the pictures of the conference you can get an erroneous idea that it was all fun and partying. Somehow the pictures don't do long days of learning justice...
Now that Carbide.c++ v1.3 is out, we've been getting a number of questions from customers about licensing. Many of our customers using version 1.2 aren't sure if they can simply use their 1.2 license with the new 1.3 version. However, they quickly discover that it doesn't work and end up contacting support to get a new license.
So to help alleviate this, here are the steps a customer who has a license and current support contract for version 1.2 needs to take:
You can get a new license from the web site where you activated your v1.2 license.
* Login to https://pro.forum.nokia.com/user/UserLogin.jsp
* Click Your Account
* Click Manage My Licenses >>
* Check the License Upgrade box by your license
* Do NOT click Save Changes >>
* Click Shopping Cart >>
* Click Proceed to checkout
* Go back to Manage My Licenses >> and reactivate your license
This should allow you to obtain your new license for version 1.3. If you encounter problems during this process, you can always contact us at: license.carbide@nokia.com
When using on device debugging in the previous versions of Carbide, there were quite a few limitations when debugging libraries. Almost all these limitations are addressed in 1.3 release. By default, all the executables from the SDK for a particular build configuration will be targeted automatically for debugging. To further illustrate, lets say you have the application main executable "app1.exe" which links against multiple libraries like lib1.dll and lib2.dll. Lets assume that lib1 is a static dll and links against another static dll say lib2.dll and lib3 is a polymorphic dll. Also assume that you have a ECOM plugin say plugin1.dll as part of this application.
In Carbide 1.2, you were able to debug lib1 and lib2 fine since lib1 is a direct static dependency and is available from the dependent library list of the main executable that is being launched. Since lib2 is a polymorphic dll, the debugger would get a notification when the dll is loaded. It was not possible to debug lib3.dll in 1.2. Also it was not possible to debug plugin1.dll. The limitation was that nested static dependent libraries were not targeted for debugging and there was no library load notification for ECOM plugins, even if there is one, it would have been missed anyway since the ECOM plugins are loaded at OS bootup time.
In 1.3, we have added support in Carbide where Carbide debugger would try to get the load address of all the executables either built as part of the project or imported into executables view. The load address of the static libraries is available as soon as the process is launched, so lib1 and lib3 would be targeted right after the process is launched. Like before, lib2.dll would be targeted when the dll loaded notification comes from the target. Carbide debugger would be able to get the load address of the ECOM plugin as well since it is loaded at bootup time and so it will also be targeted.
Also another addition in 1.3 is that when you attach to a process, then also the Carbide debugger would try to get the load address of the untargeted executables. This is very useful if you are debugging a client server application, where the client launches the server or the server is already running. In this case, once you start debugging the client application, you can attach to the server at which time the Carbide debuggerwould try and get the load address of the dependent libraries of the server application.
For those of you who don't want to read Frank's magnum opus below on Bugzilla, here's the executive summary:
We got lots of positive comments from those of you who participated in the Carbide.c++ v1.3 beta about opening up our Bugzilla database; it dramatically improved response time and got issues resolved much faster than working via e-mail or the Forum Nokia Pro support portal. Since everyone liked it so much, we've decided to make Bugzilla our primary support channel. For those of you who don't yet have accounts, you can find our site here:
https://xdabug001.ext.nokia.com/bugzilla/
You'll want to use the "Create a new account" link the first time you go there; it will ask you for the e-mail address that you want to receive updates on. Once your login is validated you can submit any problems, questions, and suggestions there and we'll get back to you as quickly as possible.
We look forward to hearing from you.
Frank and Vasili and I spent this past week at EclipseCon in Santa Clara. We use the Eclipse IDE platform and the CDT C/C++ tools as the foundation for Carbide so it was an important opportunity to talk to people in those communities. We had an opportunity to talk about our experiences developing Carbide and especially all the feedback we have received from people who have used other C/C++ tools. It was great to meet and catch up with other people from Nokia and developers from other companies creating C++ tools. We also got to join a number of discussions about the future direction of the Eclipse platform and advocate for things that would enhance Carbide, like a more flexible project system. As we begin to plan our next major release we’re looking at some new technologies in Eclipse and CDT, including a new way for the product to update itself and some new debugger features, so it was a great way to learn about those. Most of the Eclipse community’s business is done in the open using mailing lists and bugzilla, but you can still learn a lot by chatting people up at the evening receptions and hanging around the hotel bar.
Having a great IDE is extremely important for any toolset. Despite the fact that some people still prefer writing their code in emacs or vi editors, the majority of the development these days is done in IDEs. And the choice of the IDEs available for developers and tool vendors to choose from is shrinking. In fact, there are only two viable choices left. Namely: Eclipse and Microsoft Visual Studio.
Without speculating which IDE will end up on top, I think that only one will dominate in the future. Right now Nokia has Carbide tools based from both IDEs. My personal preference is Eclipse/Open Source based one. I have to admit here that I was a big fan of CodeWarrior (CW), mostly because of a lot of personal effort put into developing CW for Symbian/s60. Eclipse IDE has a lot of advantages in comparison to CW and simply makes a better business proposition.
I know there are still a lot of CW and VS developers for s60 and I know first hand how reluctant we are to switch between IDEs when developing s60/Symbian apps. It is an investment that is well worth it for me.
Though we are not controlling the features that are going inside Eclipse, Nokia tools team has contributors to Eclipse platform and constantly working on implementing the IDE features that I and s60 developers want or are promising.
I think that most of the developers are not as passionate about the tools and IDEs as me and my friends/colleagues on the Carbide C++ development team and only use the tools that are available or mandated by their business units. I hope that the fact that a lot of people on our team, including my-self, take tools development personally will make Carbide C++ tools more trustworthy and desirable to use.
The Carbide debugger team is working on improvements to on-device debugging in the next several releases. Our ultimate goal is plug-and-play. In other words, you connect your device, Carbide detects it and you can debug your projects on that device. We're not there yet, but we would like to make your on-device debugging life easier along the way to that goal.
We've identified many little things that bug people in our many debugging user interface elements such as the launch wizard pages, lauch configuration tabs, data views, etc. If you have anything you would want to add to our list, we want to get your suggestions. For example, is there a list or table that isn't sorted like you would like? Is there an option that's misnamed or in the wrong place? Are there options that are missing? Is your debugging work-flow hampered because the UI is not arranged in the most natural way for how you work? What is your pet-peeve about the way we present on-device debugging?
You can add comments to this entry or log them as enhancement requests to our bugzilla.
We just noticed a glitch in the S60 3rd FP2 SDK: The capability definition files are out of date. The consequence is that if you run the capability scanner against this SDK is will likely miss most of your capabilities and report that you don't need any.
Luckily the solution is easy: Just delete the 'capabilities' folder and contents under:
Then run the scanner again. Carbide contains the most recent capability definitions for all the S60 3rd SDK editions to date so when they aren't in the SDK, Carbide will use the ones installed in the IDE.
Tim
The beta cycle for Carbide 1.2 last year nearly killed the Carbide Support team. To avoid that in the Carbide 1.3 beta cycle we did something users had been asking us to do for a long time, open our bug database. So we did.
There was a lot of historical resistance in the group to opening up the database, and some discomfort in knowing that everything entered could be seen by countless viewers. However, everyone knew something better had to be done, otherwise the "support tsunami" as I referred to it, would overwhelm the work required to actually fix bugs and get the latest release out the door on time. So we had meetings, we planned, we experimented some, and arrived at a solution that addressed all of the concerns we had.
Now you too can enjoy the open nature of our bug fixing process.
If you have a bug to report, or an enhancement request, you can now go to https://xdabug001.ext.nokia.com/bugzilla/, register yourself, and submit the bug using Bugzilla. Once registered you are entered into the Carbide.c.public group, which enables you to see all the bugs submitted by Carbide users. Once submitted the bug is seen both by the Carbide support team and engineers. From that point on any action we take on the bug will cause you to get a message so you can easily track the progress being made to solve your problem. It's especially important to watch for them as many times we may need additional information from you so we can isolate and solve the core problem and not just the symptom
When the bug is fixed you'll be notified of that as well. When that happens you can immediately verify the fix by downloading the Carbide development build containing the fix and letting us know if we were successful. If the development build doesn't fix the issue then you need to let us know. If we don't hear from you, we'll assume your problem was solved, wait 3-4 weeks and then close out the bug report.
During the Carbide 1.3 beta cycle many people found the interaction and immediacy of using Bugzilla to submit bugs, and that the turn around time and level of communication with the Carbide team were vastly better than anything experienced before. Needless to say we will continue to use if until something better comes along.
And just so you know, the Carbide Support team survived the beta cycle with ease.
Starting with Carbide.c++ release 1.2 we've introduced public APIs for Carbide 3rd party Carbide development. These APIs are also being used by internal Nokia tools teams and other Symbian OS licensees. However, I do occasionally get a technical question from plug-in developers that don't even know there are APIs to access Carbide project info. So in those cases, a quick start might help to ease into Carbide development.
Continue reading "A Quick Tour of the Carbide.c++ SDK APIs " »I really like debugging with TRK but everytime i leave TRK running on device, my phone battery is ehxasted in ~10-12 hours!
This could be the internal TRK power drain or simply the fact that when TRK stays in front, phone doens't enter power-saving mode(the screen is always lit). The former would be really difficult to isolate/fix and the later is rather easy to fix! Need to investigate how to enable power-save mode when running trk.
Wikipedia’s Software Testing Controversies [as of publication of this blog entry] summarizes the questions facing testers, developers and managers today. Should testing be Agile or traditional, exploratory or scripted, manual or automated? Our organization has had to answer all the issues, and oh, the difficulty! Continue reading "Automation is a Key Carbide.c++ Development Goal" »
This is off-topic for this blog, but readers of this blog may be interested to know about a new tools project. With S60 Feature Pack 2, Nokia has introduced Web Runtime. It brings widgets to the S60 platform. Widgets are application based on standard web technologies: HTML, CSS, and JavaScript. There's quite a bit of information about widget development on Forum Nokia.
We just started a limited-access alpha test program for Web Runtime tools. If you're interested, follow the link below to request access to the program. Please make sure to answer the questions or your access may be delayed.
http://groups.google.com/group/nokia-wrt-tools-beta
Watching some of my colleagues work and seeing come comments from our users, I believe a common and very useful UI feature in Carbide is often overlooked. I'm referring to the structured viewer filter. Many views and dialogs in Carbide have filter fields that can be used to narrow down a view full of data to display only the data you are interested in.
In a previous post, Tim suggested using CTRL-Shift-R to bring up the "Open Resource" dialog which can be used to find any file in your workspace. There is a filter field in this dialog, as well as in the CDT "Open Element" dialog that works at the language level. By the way, for those of us who can't easily remember keyboard shortcuts, these dialogs can be found in the "Navigate" menu.
It can often seem like a daunting task to find exactly the right setting in the Preferences window. Recently, a user asked how to change the tabs preference in the editor. Opening up the Preferences window and typing "tabs" in the filter field, gets you there without having to pore through all the settings.
There are filter fields all over Carbide. Whenever you see them, you can use them to narrow your search and filter out all the things you are not interested in.
One of our usability goals for Carbide is to make it easier for people to launch a debug session without using the launch configuration dialog.
Ideally, when you select the Debug command or hit the Debug button, the necessary info is pulled from the project and the debug session starts. Where more information is required the wizard asks for any required settings, then launches the debugger. You should only have to use the launch configuration dialog in advanced cases to go back and adjust specific settings.
Yet it seems some people still need to open the dialog to configure and launch a debug session. My question is why? Do we need to change the settings in the launch wizard or change the default values we derive from your project? Do we need to add more specialized launch types?
If you are using the launch configuration dialog please let us know which of the settings you are having to change so we can simplify the launch process. I've created a bug to capture feedback about this, or you can leave your comments here.
The Executables View is new in Carbide 1.3, here is a quick tour:
In earlier versions of Carbide you could see executable files in the C/C++ Projects View and expand them to see their source files. This was OK for a first try but had a number of problems we wanted to fix with a new Executables View.
Most people said it was cumbersome to expand executables in the Projects view and browse their source files. When using the Projects view we also couldn't easily provide information about how the debugger would find missing source files. We needed a specialized view for displaying and managing the executables you are building and debugging.
The Executables View will show you the executables built by all of your projects in the workspace as well as any you have imported for debugging. If you want to import additional executables you can just drag them into the view.
There are also some additional columns that we didn't want to present by default but will show you extra information about each executable and source file:
This week I was helping a colleague in Dallas with a breakpoint problem. He was setting a breakpoint but the debugger wasn't stopping and the editor was showing a warning symbol over the break.
When the debugger can't determine where to set a breakpoint you will see a little warning symbol on top of the breakpoint. This usually means that there hasn't been an executable loaded that was built with the source file the breakpoint is in. So if you are debugging with the emulator but you haven't opened your app yet then your breakpoints will be shown this way. When you do something that causes your code to get loaded then Carbide will install the breakpoints in the correct place and the warning marker will go away.
When using the emulator you can see exactly what bits of code are loaded by turning on the "Show System Messages" option in the launch configuration dialog. I used this to verify his executable really was loaded when it appeared to be.
If you are sure the source file with the breakpoint is in code that gets loaded and executed then the problem may be that Carbide's debugger isn't loading symbols for the executable. We need to load the compiler-generated symbols for an executable so we can translate the source location of the breakpoint into an address in memory where we can tell the debugger to stop. If we don't load symbols for an executable then this won't happen and the break will remain unresolved.
Loading symbols for an executable is required to set breakpoints but there is also a performance hit each time we do it. So Carbide tries to guess which executables you are interested in debugging and only loads symbols for those files. Normally this includes any executables produced by any of the projects in your workspace for the SDK you are debugging in. But my Dallas colleague had set the breakpoint in a source file for a library he wasn't building. The library he was building was calling it but the debugger didn't know that. The debugger wasn't loading symbols for that library and so couldn't determine where to set his breakpoint.
If you open the Executables View you can see a list of the executables Carbide thinks you are interested in debugging. If you want to add more to this list just drag the executable file into the view and the debugger will be able to set breakpoints in that file too. Once we added his other executable in then the breakpoints lost their warning symbol and worked correctly.
Along with the rest of Nokia, the Carbide.c++ team has been applying Agile development methods lately and after several iterations, we've been steadily improving our process.
What does this mean to Carbide.c++ users? One of the main things this means is that our focus in involving our customers in our development process has sharpened greatly. You can be much more directly involved in making Carbide.c++ the best development tool it can be!
We've had great success for the past several releases with our beta program. Additionally, we've stepped up our focus on automated unit testing so that our nightly builds are of a much higher quality, and because of this, we've been able to make our nightly development builds available publicly. Our users can log bugs directly in our bugzilla bug tracking system, and when the bug is fixed, you can download the latest build with the fix.
So, help us make Carbide.c++ great! Get involved!
Not exactly what Sir Paul had in mind, but one the most overlooked features I've seen Cabride developers completly miss out on is Eclipse's resource history tracking. Every time you save a file after editing in Carbide, a copy of the file is kept in the workspace under the ".metadata\.plugins\org.eclipse.core.resources\.history\" folder. During the course of a day you may be working on several updates to a file or files and only want to keep a few of them. You can compare any two revisions in time my simply selecting the file, right-clicking and choosing Compare With > Local History...
If you select the latest version and another previous date while holding down the CTRL key, you can then open the context menu and select Compare with Each Other.
Then the Compare Editor opens up and you can choose what changes you want to keep which changes to merge out before you check your code in.
It can also be handy to check out how Carbide and other source generation plugins are modifying sources and project files. For example, you can use the visual MMP INF editors over time and use the local history cache to see how the visual editor is modifying the underlying text files.
Even cooler, the Eclipse platform keeps these histories around even when you delete the files. So if you are re-arranging files and/or deleting sources you can select a project, right click and choose Restore from Local History...
Wa-la! Now you can get back to where.... you get the idea.
And of course, all this functionality ties in quite nicely with the Team featreus (version control add-ins) where you can view and compare histories of files from source repositories and compare your working workspace sources to existing versions from your version control system.
That (fake) Steve Jobs has been pretty hard on his Development Tools team lately.
Woah! At least we get 3 meals a day! Good thing we've wrapped up our development on Carbide 1.3 on time and get to see the spring thaw. Developer tools is tough business - it's not all glamour, fame, and Hollywood parties you know.
(I'm pretty impressed by any one that can work a little humor into Development Tools?)
I'm working on a presentation for this year's EclipseCon titled "Visual Studio Users and Eclipse" A lot of people using Carbide have also used Visual Studio and have given us lots of feedback about their experiences trying out a new C/C++ environment. While the C/C++ people are very active in the Eclipse community the crowd at EclipseCon has more of an enterprise/java/open source background. So I hope to use the presentation to build awareness around some of the issues people have when they come to Eclipse from Visual Studio. Some of these are unique to Carbide, some are things we can contribute to the Eclipse community, and some are things we need to convince other contributers to pay attention to.
In Carbide 1.3 we added a set of Visual Studio key bindings, a couple new editor commands, better contextual launching for the debugger, and other usability improvements in response to your feedback. If you can suggest other things we can do to Carbide to make it more accessible to VS users please leave a comment or file a bug and I'll try to work them into my presentation.
And if you find yourself at EclipseCon be sure to come by and say hello.
I want to start by stating that I am not part of the debugger team, so my experiences with on-device debugging are more from the point of view of a Carbide user. Recently, I had reason to do some on-device debugging. I decided to try using bluetooth to connect my release phone to the debugger. Since this was a release phone and not an RnD phone, I used Application TRK rather than System TRK. I understood I would be limited to debugging my own application, but that was fine for my purposes.
Reading the Carbide.c++ help on run-mode debugging, I found Application TRK in the plugin directory mentioned in the help (plugins\com.nokia.carbide.trk.support_<version>\trk) and installed it using Nokia PC suite. However, I had a difficult time getting my serial port over bluetooth up and working, so I'd like to give some tips on how I got it to work.
First, I had to install the general bluetooth drivers for my lenovo ThinkPad. I already had PC suite running, but I needed the machine's manufacturer driver package in order to have serial over bluetooth. Apparently, the microsoft drivers don't provide serial emulation over bluetooth, so I needed the full WIDCOMM package from the manufacturer.
The way that TRK currently works with bluetooth is that it has a setting labeled "port." However, this is not the COM port on the host machine, but rather an internal index to the serial over bluetooth service. Which index is assigned to which bluetooth service is not exactly visible, so you may have to try many different "port" settings on the TRK interface on the phone. I start with 1 and go up from there, but more on that later.
When I opened the bluetooth configuration dialog on the machine, I found a tab for local services and on it there was a bluetooth serial port service assigned to COM port 7.
Tip 1: I could never connect to this COM port, so I found that deleting the preassigned one and creating a new one seems to yield better results. My new one was assigned to COM port 9.
Tip 2: Since I had to try different "port" settings on the TRK interface on the phone, and each time I had to wait to see which one it tried to connect to, I found it was better to set all of the local bluetooth services except the serial service to "manual" rather than "automatic." This way, when I connected to the wrong service, it failed right away and I didn't have to look on my machine to see which service I had connected to and wait for the connection to timeout.
Tip 3: Once you connect to the serial port, don't test the viability of the connection using the debugger. The first time I tried to connect to the serial port, I could not debug and it was not clear why. I kept getting the message that the port was in use. In any case, using the debugger to drive the testing of the COM port means you have to actively do something. On the other hand, you can use HyperTerminal (Start/Programs/Accessories/Communications/HyperTerminal) to listen to the COM port for you. And when you try to connect from TRK, a successful connection will cause the TRK message to appear on the HyperTerminal screen.
Now, you are ready to debug. Just make sure that you disconnect HyperTeminal first, or you'll get a message that the COM port is in use. And this time, you can actually do something about it.
Reading the comments from the survey from the 1.3 beta list, I noticed that there were several comments about missing usability features in Carbide. I'd like to address one of these that I use quite often.
One user complained that Visual Studio allowed him to view source files side by side. He wanted to view the header and source files for some class, side by side, and lamented that Carbide did not allow this. Well, it does and it's very easy to do! In fact, in Carbide you can split the editor area into as many slices as your screen size will allow. The editor area is the area in the middle where source files open. In the default Carbide C/C++ perspective, the Project Explorer and Symbian Project Navigator are on the left side. The Outline is on the right, and accessories kinds of views are tabbed on the bottom (Problems, Console, Properties, different hierarchy views, etc.).
When a source file is opened, it opens in the main editor area in the middle. As more source files are opened, they are tabbed in the editor area. But that's not the only way they can be viewed. Carbide is very drag-and-drop enabled and restructuring the editor area is achieved with drag-and-drop. To split the editor area into two, you need at least two editors open. Just grab the tab for one of them and drag it all the way to the right (or left, or top or bottom) and a rubber band will be displayed showing how the editor area will be split up. Just release the mouse to confirm and presto! Multiple side by side editors. Repeat as necessary and you can tile your editor area as much as you want. To remove a split, just close the last editor in that portion, or simply drag the last editor back into another existing portion.
We hear a lot about how starting a debug session with the emulator can be slow. One way to improve turn around time is to make your changes and rebuild your application while the emulator is running. This can really save time but there are a couple tricks to learn and some important limitations.
The first step is to make sure Carbide will launch the emulator instead of your application. For S60 3.1 and later SDKs Carbide will launch the application by default so you'll need to modify the launch configuration. Open the launch configuration dialog and make sure the emulator setting looks something like this with epoc.exe at the end:
After the emulator starts you can open your app and debug normally. But when you want to make changes don't kill the debug session or exit the emulator. Instead exit your app but leave the emulator running then make your changes, rebuild, and reopen your application.
How it works
Since the linker will want to write a new version of your executable file you can't rebuild your app if either Carbide or the emulator keep the existing one open. Carbide keeps the executable open during a debug session but if you rebuild it the debugger will close the file, wait for the build to complete, then reload the file and reset all of the breakpoints. The emulator will keep the executable file open while your app is running. Sometimes just exiting the app will release the file, but often the emulator will continue to keep the file open. Usually exiting back to the standby screen will convince the emulator to release the file so you can rebuild.
Limitations
After the emulator closes the executable file you will be able to change your code and rebuild it. But you can only do this with the executable portion of your app; once the resources are loaded by the emulator they are never unloaded and can not be rebuilt. So if you need to make a resource change you'll need to terminate the debug session, make the changes, and start a new one.
Also if you are not using Carbide to rebuild your app the debugger won't know about the build and won't unlock the executable file so it can be replaced with the new one.
