Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Adobe AIR Development

Posts: 1,269
Registered: ‎12-29-2010
My Device: PlayBook, Z10 LE, Dev Alpha C

Re: How to trace()?

[ Edited ]

I am getting seemingly random behavior from trace() statements in FB 4.0.1.  I imported the FullRSSReader.fxp sample project and created a Blackberry Tabler AIR Application run configuration for it, with Application Deployment Mode set to Development mode.  The only thing I had to do for this sample project was update it to use the 0.9.1 playbook SDK.  It deploys and launches fine on the simulator, and the first time I deployed and launched, the trace() statements from FullRSSReader.as were going to my FB console ... but many runs later since then they have ceased.  I also can't get trace() statements to come to my FB console for another hello world project I wrote, even though they were working before as well.  I have power cycled the playbook VM, closed and restarted FB and VMWare player, and even rebooted the whole darn computer to clear out any possible debug processes that might be running, and trace() statements are still not working.  If anyone has had similar experience and gotten their trace statements working again please chime in. 


Edit/Update:  I may have been running a run configuration and not a debug configuration (and therefore not realizing that I wasn't connected to the debugger).  Also, my local IP address can sometimes change when I reboot computers on my local network and/or power the whole shebang down.  I double checked my debug configurations vs. my local IP address and although they matched this time, they may have been mismatching on some of the runs that wouldn't trace.  The sessions that wouldn't trace were probably just not connected to the debugger and I just didn't realize it.  Still getting used to FB ...  but, one suggestion from this for other folks having debug problems - double check your current local IP address vs. the debug config's debug host IP address & make sure they are still the same.  I changed, saved, changed back, and re-saved mine just for kicks and my trace statements work again.

Posts: 1,008
Registered: ‎12-12-2010
My Device: Passport (Red Limited Edition)
My Carrier: Mobile Vikings

Re: How to trace()?

Thank you for tip, I will try it out.

jtegen wrote:

I too get trace() to work sometimes and getting the remote debug to work from the simulator has been problematic.  Though I still have trouble getting my environment to work to debug from the simulator, local debug has been nice by using Alcon (http://blog.hexagonstar.com/downloads/alcon/).  Other than levels of debug, it shows continuous on FPS and memory usage, plus it has a nice object inspector that shows an object in a tree form.  Very simple library to install and API.


The author mentioned he is working on a remote connection.  If you like the tool, let him know you too would be interested in a remote debug control session.


BlackBerry Certified Builder for Native Application Development -- Proud member of the Belgian BlackBerry Developer group
Samples: Park in Ghent
Feeling generous? Nominate me for BB Elite member!
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: How to trace()?

(Note for readers, the OP edited his posting above to include details of why the problem occurred... it may not be obvious at first glance, but look at the second paragraph for an answer.)


By the way, there's one thing you can do to avoid some problems resulting from changing addresses.  If your simulator is given an address in a particular network, it appears VMWare will generally continue to give it that address, or at least other addresses in the same network, each time it's run, even after a reboot.  For example, if you sim starts at, then you may never see anything that isn't in the 192.168.40.xxx address.  (I can't say that's certain, just that I observe this behaviour.)


If this is indeed the case, I believe VMWare will always be reserving the first address in that network for your hosting machine, which means you could use (in the above example) all the time as the address for your own machine in the appropriate place or with the "-connect" option at the command line.


A second option if you have a local network with addresses managed (via DHCP) using a local wireless router.  Generally DHCP addresses are handed out on a short-term "lease", which can expire in an hour, or a day or a week.  Even when a lease expires, however, the DHCP server typically reserves addresses for quite a while and hands them out again to the same machine (based on MAC address) if it shows up again any time soon.


What this means is that if you switch VMWare so that the Network Adapter settings specify a "Bridged" connection instead of the default connection (which I believe is Host-only), then both your host/desktop machine and the simulator will have addresses handed out by your own network's DHCP server, and those addresses will rarely, if ever, change.  This is what I do, and neither my host nor simulator addresses ever change now.


Note one security caution: on a bridged network, anyone else on the same network could "see" your simulator (that is, see any open ports on the network) and connect to it (e.g. using telnet) when it's in development mode.  They won't see the screen, but they could definitely get inside the simulator and do things like grab the code for your application, or just mess with your mind by, for example, turning off development mode.  So don't use "bridged" networks for VMWare if you have a little brother who's a budding hacker Smiley Happy, or any other time you're on a non-private network with other users you don't trust.

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!