[Reposted from Christian Helle's Blog] 

The one thing that irritated me the most about the Windows Phone 7 emulator the first time I used it was that the host computer keyboard is not directly mapped to the emulator. This means you by default have to use the software input panel that is built in Windows Phone 7.

I immediately looked for a solution and found some MSDN documentation on the keyboard mappings for the emulator.

To enable the keyboard in the emulator - press the PAGE UP key or PAUSE/BREAK key.

To disable the keyboard in the emulator - press the PAGE DOWN key PAUSE/BREAK key.

If you want to learn more then I suggest you check out this article called Keyboard Mapping for Windows Phone Emulator

[Reposted from Christian Helle's Blog]

I finally managed to find the time to complete my puzzle game for Windows Phone 7. This will be my first attempt to publish anything on the marketplace. Let's see how it goes!

If you're interested in how I made the game then I'll be more than willing to share. I might be able to post code directly as this is soon be available commercially, but I can always give some tips and share knowledge.  I wrote a step by step article on how to Create a Puzzle Game for Windows Phone 7 using XNA that might be of interest to you. The puzzle game logic is described in this article and I pretty use the same logic.

[Reposted from Christian Helle's Blog] 

Apparently most Motorola devices support 2 Bluetooth Stacks: Microsoft and StoneStreet. To switch which stack to use you would have to make some changes in the registry and restart the device.

[HKEY_LOCAL_MACHINE\SOFTWARE\SymbolBluetooth]

"SSStack"=DWORD:1

0 = Microsoft Stack 
1 = StoneStreet One Stack

The StoneStreet One Stack is supported in all devices except the ES400 and MC65. For the Microsoft stack, any device running Windows Mobile 6.1, Windows Mobile 6.5.x and Windows CE 6.0

Motorola recommendeds using the Microsoft stack for new development and I strongly agree with Motorola on this!

[Reposted from Christian Helle's Blog] 

Not so long ago I had a project that involved Bluetooth communication from a windows mobile device to some custom designed hardware. Everything went smoothly with only a few bumps during the scope of the project. When we had the applications on the field, certain users where running on devices that used the Widcomm Bluetooth Stack and that gave us a few headaches. For one, our system doesn't use any security features in bluetooth hence it doesn't not require pairing. Our security architecture is service based and checks for certain keys being passed back and forth to an online service. Very standard stuff. The problem we had with the devices running on a Widcomm Bluetooth stack was that the user was always prompted to pair even though the device did not require pairing. The application was not designed to handle user input aside from logging in/out and some diagnostic features. The application was designed to just run quietly in the background with the device tucked in the users pocket.

Since quite a few devices use the Widcomm Bluetooth Stack I needed a quick fix/hack to avoid the user having to pick up the device and click "Yes" on the security prompt to communicate with the device. The fix had to be as simple as possible and had to run without disrupting the user. My not so clean solution was to create a small application that does nothing but check if the Widcomm security pairing prompt app was running and if so send a keystroke event to simulate the user clicking on "Yes".

The Widcomm security prompt app main window uses the class name Broadcom_BTWizard with the window name Bluetooth. I check if this window exists and send the F1 keyboard event to simulate clicking on the left hardware button on the device

Here's a code snippet in C#

[DllImport("coredll.dll")]

static extern IntPtr FindWindow(string lpClassName, string lpWindowName);

[DllImport("coredll")]

static extern void keybd_event(byte bVk, byte bScan, int dwFlags, int dwExtraInfo);

const int KEYEVENTF_KEYUP = 0x02;

const int KEYEVENTF_KEYDOWN = 0x00;

static bool running = true;

static void CloseBroadcomWindowWorker()

{

    while (running)

    {

        var hwnd = FindWindow("Broadcom_BTWizard", "Bluetooth");

        if (hwnd != IntPtr.Zero)

        {

            keybd_event((byte)Keys.F1, 0, KEYEVENTF_KEYDOWN, 0);

            keybd_event((byte)Keys.F1, 0, KEYEVENTF_KEYUP, 0);

        }

        Thread.Sleep(5000);

    }

}

[Reposted from Christian Helle's Blog] 

Not so long ago I wrote a Puzzle game for Windows Phone 7 using XNA. The game was really simple and had no menu or state management. Luckily, I recently stumbled upon a sample on MSDN that describes the basics of implementing game state management using XNA.

To try things out a bit more I modified my existing puzzle game and included the sample game state management code. The results are pretty amazing!

Here's how my Puzzle Game for Windows Phone 7 looks like now:

[Reposted from ploeh blog]

Recently I attended a workshop where we attempted to migrate an existing web application to Windows Azure. It was a worthwhile workshop that left me with a few key takeaways related to migrating applications to Windows Azure.

The first and most important point is so self-evident that I seriously considered not publishing it. However, apparently it wasn’t self-evident to all workshop participants, so someone else might also benefit from this general advice:

Before migrating to Windows Azure, make sure that the application scales to at least two normal servers.

It’s as simple as that – still, lots of web developers never consider this aspect of application architecture.

Why is this important in relation to Azure? The Windows Azure SLA only applies if you deploy two or more instances, which makes sense since the hosting servers occasionally need to be patched etc.

Unless you don’t care about the SLA, your application must be able to ‘scale’ to at least two servers. If it can’t, fix this issue first, before attempting to migrate to Windows Azure. You can test this locally by simply installing your application on two different servers and put them behind a load balancer (you can use virtual machines if you don’t have the hardware). Only if it works consistently in this configuration should you consider deploying to Azure.

Here are the most common issues that may prevent the application from ‘scaling’:

• Keeping state in memory. If you must use session state, use one of the out-of-process session state store providers.
• Using the file system for persistent storage. The file system is local to each server.

Making sure that the application ‘scales’ to at least two servers is such a simple sanity check that it should go without saying, but apparently it doesn’t.

Please note that I put ‘scaling’ in quotes here. An application that runs on only two servers has yet to prove that it’s truly scalable, but that’s another story.

Also note that this sanity check in no way guarantees that the application will run on Azure. However, if the check fails, it most likely will not.

I recently stumbled upon the Microsoft Advertising SDK for Windows Phone 7. At the client side, it provides a control called AdControl that retrieves banner information based on the specified ApplicationId and AdUnitId. In order to use the Microsoft Advertising’s ad delivery system, you first need to create a Microsoft pubCenter account.

Here's some information extracted from the help file included in the SDK:

The following C# code instantiates a new AdControl and sets mandatory targeting parameters.

AdControl ctrl = new AdControl();

ctrl.ApplicationId = "testapplication";

ctrl.AdUnitId = "testadunit";

this.ContentGrid.Children.Add(ctrl);

The following C# code instantiates a new AdControl with manual ad rotation. 

string applicationId = "testapplication";

string adUnitId = "testadunit";

bool isAutoRotation = false;

AdControl ctrl = new AdControl(applicationId, adUnitId, AdModel.Contextual, isAutoRotation);

ctrl.Width = 480;

ctrl.Height = 80;

this.ContentGrid.Children.Add(ctrl);

<Grid xmlns:adctl="clr-namespace:Microsoft.Advertising.Mobile.UI;assembly=Microsoft.Advertising.Mobile.UI" Grid.Row="1">

   <adctl:AdControl Height="80" Width="480" AdUnitId="Test" ApplicationId="Test" AdModel="Contextual" />

</Grid>