01-02-2011 02:54 AM - edited 01-02-2011 03:34 AM
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.
01-02-2011 04:38 AM
Thank you for tip, I will try it out.
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.
01-02-2011 08:51 AM
(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 192.168.40.128, 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 192.168.40.1 (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 , or any other time you're on a non-private network with other users you don't trust.