A common source of confusion for our users is the distinction we make between 'what' and 'where'. We generally search for 'what' (which is the text you can enter on the main form), centering the results on the 'where' (which is the location shown just below). If you want to change the location, or if you want to search for an address, you need to click on 'Choose a new location'; you can then enter the address on the Location screen and click 'Find' (note: the screen shots shown below come from a test version of the app we run on the desktop; the menus at the top will be on the bottom on your phone, accessible via the two softkeys; I just used the desktop version here as it was quicker for me):
I run a mostly Windows-only setup at home these days. My home setup consists of:
- an SBS2003 server mostly for Exchange mail, which also runs FreeBSD in a virtual machine to keep some older services running on Apache (primarily the redirector from my domain to Live Spaces and my subversion repository).
- a Windows Home Server, which has taken over the file server functionality from SBS2003, as I like its more flexible file replication
- a media center PC running Vista Ultimate
- a kitchen internet appliance running Windows CE
- Vista Ultimate PCs for each of my kids (and a laptop for the wife)
- a desktop PC and a Tablet PC for me with Vista Ultimate
- an oldish Mac Mini G4 which was running Leopard
We get a lot of people reporting problems with their hardware keyboards on phones like the VX6800. When they press the letter keys instead of letters they get numbers and symbols.
Unfortunately this is a problem with the IME (input method editor) in the phone. IMEs are often customized by the phone OEM or the mobile operator to add functionality like predictive text input. For a number of phones, an IME was added that breaks text input from the keyboard with all .Net Compact Framework apps. In many cases we're the only such app on the phone, so users understandably think its a bug in our program. We wish it was - in that case we could fix it - but there really isn't anything we can do other than complain.
One thing we have found is that our zoom UI is not very discoverable. It'll probably change in the future as a result; it seems we over-engineered it in the current app. But until we come up with a replacement, here are some tips:
- obviously you can use the menu Zoom In/Zoom Out to change the zoom by one level
- if you hit the D-Pad center button you will go into 'zoom mode'. While in this mode you can use the right soft key or the D-Pad center button to increase the zoom level, and the left soft key to decrease the zoom level. You can also pan the zoom box around the map with the D-Pad direction keys. If you don't press any buttons for about two seconds, then the selected zoom will be performed, and zoom mode is exited
- if you have a touch screen, you can also quickly double tap on a map location to zoom in to that location
I hope this helps!
A few people have asked how to limit search results to residential addresses.
When you're in the list of search results, if you click "Menu" then select "View", you will see checkboxes for business and residential. By checking or unchecking these you can restrict results to just business, just residential, or both.
Several new Sprint phones come with Live Search for Mobile already installed, with a launch icon on the home page. Unfortunately if you update the application then this icon stops working. We changed where the app gets installed whereas the icon Sprint added has a hard-coded path.
There is a simple fix, however. Install this CAB file on your Sprint phone and the icon should work again.
If you live in an area where there is no traffic coverage, you may not want to have the Traffic icon taking up precious real estate on your home screen. There is a way to re-order the icons, although it is not for the faint of heart. You need to edit the preferences.xml file in the \Programs\Live Search directory.
In this XML file there is a section with tags \<il>, and within this are entries with tags \<it> and \<ip>. The former stands for "icon tag" (starting with zero) and the latter for "icon position" (starting with 1). By changing the \<ip> values you can re-order the icons.
While I'm at it, you can also remove locations from the recent location list; these are in elements that start with \<rt>. A lot of people ask how to do this. It's worth mentioning though that you don't really need to do it; unused locations will eventually drop off the list. The list maintains the 15 most frequent and most recent locations. The number of questions we get about this does suggest that 15 is overkill and we may shrink the number down in future.
If you mess things up when editing the preferences.xml file and the app won't start, just delete the file. The app will create a new clean preferences file for you when it next runs.
Windows Mobile 6 phones are out and about, and several of them have built-in GPS. Some people find that the GPS doesn't work well with Live Search for Mobile, so I hope this post will help explain why GPS can be tricky. Note that you should make sure you are running the latest version of Live Search (from December '07) as this has some improvements in the timeout handling which will help.
First of all, the phones are pre-configured to use the GPS Intermediate Driver, but Live Search does not know about these phones so by default GPS is not configured. Make sure you have Live Search set to use GPS Intermediate Driver (go to Menu-Settings from the main form to access the GPS settings).
After 3 months we have finally released the latest version of Live Search for Mobile. The Windows Mobile client now features speech input, better location handling, hours of operation on search results, better movie poster sizing. and gas prices. We spent about half the time on bug fixes and stability improvements. It's a great release; get it at http://wls.live.com on your phone (download direct via your phone's browser).
Assertions can be great for detecting unexpected state in your code. But when a state violation is caught in an assert, the next question is usually "How did I get here?".
A simple but effective way to track down this kind of issue is the following: in each class instance allocate a StringBuilder member (called, for example, stateLog). Then, at each point in the class code where the state changes, log the change with an appropriate message (usually a helper method that takes a string message is appropriate here - it should append the message plus a snapshot of the relevant member variables to the stateLog). Now, whenever you have an assertion, you can append stateLog.ToString() to the assertion message.
It's basically like printf debugging where the printfs all get recorded but don't actually get printed until/unless they become relevant. Keeping this code in your debug builds is a great defensive technique, can catch hard to repro bugs, and can save you having to step through the debugger.