The other day I was in a situation where I had an image that changed to another image when the user mouses over it. Usually I will do this in one of two very standard ways:

• The typical javascript approach: using the onMouseOver and onMouseOut events to swap the images.
• The typical css approach: an element that sets its background-image attribute to the default image, and changes its background-image attribute to the rollover image when the :hover pseudoclass is activated.

Unfortunately, neither of these solutions were optimal as I was looking for a pure-CSS solution (so no javascript) and needed the image to have its own <img> tag (so no background-image). After playing around with my selectors a little, I came up with this little gem:

The HTML:

<div class="buttonContainer">
 <img class="rest" src="link_rest.png" />
 <img class="roll" src="link_roll.png" />
</div>

The CSS:

div.buttonContainer img.roll {
 display: none;
}
div.buttonContainer:hover img.roll {
 display: inline;
}
div.buttonContainer:hover img.rest {
 display: none;
}

This neat CSS trick leaves the images in the html and changes the image on rollover with minimal mark-up. It works by abstracting the :hover pseudoClass to the container, loading both images into the page, and controlling the rollover effect using the images' display attribute.

One word of caution: some older browsers (I'm looking at you, IE6) have poor support for the :hover pseudoclass, which renders this example ineffective; thus if you're supporting a lot of legacy browsers, this may not be for you. However, if you need a rollover that uses actual image tags and want to avoid using javascript, this may be just what you need.

The voicemail number, if available, may be stored in various locations on the Windows Mobile phone device depending on the type and carrier. In most cases, the number will show up somewhere in the registry. From experience I have found them in one of several locations under HKEY_CURRENT_USER:

\Software\Microsoft\Vmail\PhoneNumber1
\Software\Microsoft\Vmail\PhoneNumber2
\Software\Microsoft\Vmail\UserProvidedNumber1
\Software\Microsoft\Vmail\CarrierProviderNumber1
\System\State\Messages\vmail\VMailNumber
\Palm\State\Messages\vmail\VMailNumber

On some GSM devices however the number isn’t always updated properly in the registry. In that case you would have to fetch it direct from the SIM card. In fact it is probably safest to fetch it from the SIM card first since this ensures a more accurate number.

If you do some internet searches and dig through some of the 3GPP specifications for (U)SIM (i.e. 3GPP TS 31.102, 51.011) you will find that the voicemail number is stored in the EF_MBDN (Mailbox Dialing Numbers) file located at either 6FC7 for 3G devices or 6F17 for 2G.

We can get the voicemail file from the SIM using the SIM Manager API. Note that some of these are privileged functions. You also have to make sure to add “cellcore.lib” as a dependency to your project. The code would look as follows:

// include the SIM Manager API
#include 

// set the voicemail addresses
#define EF_MBDN_2G 0x6F17
#define EF_MBDN_3G 0x6FC7

std::string getVoicemailNumber()
{

std::string number;
HSIM hSim = 0;
HRESULT hr = S_OK;

// initialize
hr = SimInitialize (0, 0, 0, (LPHSIM)&hSim);

if (S_OK == hr)
{
    DWORD address = EF_MBDN_2G;
    SIMRECORDINFO simRecordInfo = {0};
    simRecordInfo.cbSize = sizeof(SIMRECORDINFO);

    // check the 2G address for the file
    hr = SimGetRecordInfo(hSim, address, &simRecordInfo);

    // The file may hold more than one number for devices with
    // multiple lines; however we will assume only one line.
    // A valid file needs to be "linear" type and at least 14 bytes.
    if ( S_OK != hr ||
         SIM_RECORDTYPE_LINEAR != simRecordInfo.dwRecordType ||
         simRecordInfo.dwItemCount == 0 ||
         simRecordInfo.dwSize < 14 )
    {
        // no valid 2G file, check the 3G address
        address = EF_MBDN_3G;
        memset(&simRecordInfo, 0, sizeof(simRecordInfo));
        simRecordInfo.cbSize = sizeof(SIMRECORDINFO);
        hr = SimGetRecordInfo(hSim, address, &simRecordInfo);
    }

    if ( S_OK == hr &&
         SIM_RECORDTYPE_LINEAR == simRecordInfo.dwRecordType &&
         simRecordInfo.dwItemCount > 0 &&
         simRecordInfo.dwSize >= 14)
    {
        // allocate the specified size
        LPBYTE buf = (LPBYTE)LocalAlloc(LPTR, simRecordInfo.dwSize);
        DWORD bytesRead = 0;
        
        // read the SIM file
        hr = SimReadRecord(hSim, address, SIM_RECORDTYPE_LINEAR, 1,
                buf, simRecordInfo.dwSize, &bytesRead);

        if (S_OK ==  hr && bytesRead >= 14)
        {
            // handle the bytes received
...

Now that we have the file, we need to interpret the bytes into a useful number. The 3GPP specifications show the EF_MBDN structure as follows:

Bytes        Description                                 M/O  Length
----------------------------------------------------------------------
1 to X       Alpha Identifier                             O   X bytes
X+1          Length of BCD number/SSC contents            M   1 byte
X+2          TON and NPI                                  M   1 byte
X+3 to X+12  Dialling Number/SSC contents                 M   10 bytes
X+13         Capability/Configuration2 Record Identifier  M   1 byte
X+14         Extension 6 Record Identifier                M   1 byte

The first few bytes (1 to X) are the optional identifier. In most cases it will just show the words “voicemail”. The last 14 bytes describe the voicemail number with up to 10 bytes representing the number as binary coded decimals. For our purpose we can ignore Capability/Configuration2 Record Identifier and Extension 6 Record Identifier. The way to interpret the bytes is described in the 3GPP specifications 31.102 clause 4.4.2.3 for EF_ADN (Abbreviated dialing numbers). We can proceed to get the number from the bytes as follows:

...

        // use the last 14 bytes
        char data[14];
        memcpy(&data, &buf[bytesRead-14], 14);

        // byte 0 (X+1) is the length of dialing number
        int length = data[0];

        std::stringstream ss;

        // TON and NPI determines the type of number
        // see 3GPP specifications 31.102 clause 4.4.2.3
        if (0x90 == (0xF0 & data[1]))
        {
            // add the + for international numbers
            ss << '+';
        }

        // convert the BCD bytes to Ascii chars
        for (int idx=2; idx < length+1; idx++)
        {
            // break the byte into 2 nibbles
            BYTE nibble[2];
            nibble[0] = data[idx] & 0xF;
            nibble[1] = (data[idx] >> 4) & 0xF;

            for (int i=0; i<2; i++)
            {
                if (nibble[i] == 0xA)
                {
                    // 0xA represents a *
                    ss << '*';
                }
                else if (nibble[i] == 0xB)
                {
                    // 0xB represents a #
                    ss << '#';
                }
                else if (nibble[i] < 0xA)
                {
                    // add the number
                    ss << (char) ('0' + nibble[i]);
                }
            }
        }

        // set the voicemail number
        ss >> number;

Now that we have the voicemail number we should free the buffer and sim handle and return the number:

        // free the buffer
        LocalFree( buf );
    }

    // deinitialize
    SimDeinitialize( hSim );
}
return number;

}

There are a couple of things to note. Here I’ve handled both the 2G and 3G cases, however it is probably better to detect which type is being used beforehand. Also note that I have assumed the case of only one voicemail number. For a multi-line scenario you would have to check if there are more than one number stored in the SIM file. For a more detailed look on how the numbers are stored please refer to the 3GPP specifications.

Labels: Windows Mobile

When working on a project that involved creating a custom dialer for Windows Mobile devices, one of the more important tasks is enabling the detection of the Send (green, off-hook) and Hang-up (red, on-hook) button presses at all times. The difficulty with this feat is that the Windows Mobile OS has specific needs for these buttons so you have to be careful with how you go about using them.

For example the Send button is used for launching the phone application (cprog.exe by default), and also perform phone related tasks like making and answering calls or calling a contact. The Hang-up button is used to minimize dialogs and hang up active calls.

On some devices the Hang-up button can have other behaviors such as acting as a power button or enabling keyboard lock. It’s important to know these facts, because depending on what you intend to do with the Send or Hang-up buttons, you may cause existing features of the OS to not function.

There are several methods to detect the Send and Hang-up buttons, but only a few methods will let you safely co-exist with the existing features of the Windows Mobile OS. I’ll first talk about obtaining the key presses through use of keyboard hook (SetWindowsHook) and why you shouldn’t use it. This is the first method I used for the project but quickly learned about the various limitations. If you do an Internet search for “Windows Mobile SetWindowsHook” you will obtain several pages explaining how to use SetWindowsHook on the device to detect each key press. Using this method to detect the Send or Hang-up keys you may discover several set backs.

1. You are not just intercepting the Send or Hang-up keys but every key press so you’ll have to be extra careful about handling them.
2. If an existing application already has the keyboard hook, you may not be able to use it. On a device like the Palm Treo 700/750 you may find that the Key-guard feature no longer works. This is because the Palm Key-guard also relies on the keyboard hook and can no longer use it if another application has control of it.
3. You may find that certain features that rely on Send/Hang-up no long work. For example you can no longer dial a number from Contacts with the Send button.

There are ways around these limitations of course, but it would require a lot of manual handling from your application.

Another method of key detection is the use of hotkey registration. Microsoft provides us with the “RegisterHotKey” function which essentially allows you to register any button with your application window as a hotkey using the virtual key codes (VK_TTALK for Send, VK_TEND for Hang-up). What this does is, when the registered key is pressed; it will send you a WM_HOTKEY message, even if your window is not in the foreground, allowing you to handle it.

However there are a couple limitations when dealing with the Send and Hang-up keys. You may find that attempting to register either buttons as a hot key will fail. The reason is that the TaskBar (PPC) or Tray (Smartphone) already has Send button registered as a hotkey and the phone application has the Hang-up button.

You can forcibly “steal” the hot key using either the “UnregisterHotKey” function or the hidden “UnregisterFunc1” function; however taking the hot key away from their respective owners would render some features useless as with the cases when using “SetWindowsHook”.

After some experimentation I have found that there is a unique way in which you may register the Send and Hang-up buttons (and possibly other buttons) as hot keys. I’ve discovered that it is possible to register a button using 0x2001 as a modifier (some others will work as well such 0x2002, etc). What this does is it will generate a WM_HOTKEY message for you when pressing the Send button without interfering with the existing hot key registration held by the TaskBar or Tray or phone application. The limitation here, however, is that you will only get “one shot”; that is, only one WM_HOTKEY is generated and successive key presses will have no notifications. The solution is simply to register the key again. The code would look as follows (note that error and results checking are left out for simplicity)

// setup the window to receive the hot key message
ON_MESSAGE(WM_HOTKEY, &MyappDlg::OnHotkey)

...

// define some of the values to use for registering hot keys
#define ONE_SHOT_MOD        0x2001
#define VK_TTALK_ID         0x07
#define VK_TEND_ID          0x08

...

// register the Send and Hang-up buttons with the unique modifier
::RegisterHotKey(m_hWnd, VK_TTALK_ID, ONE_SHOT_MOD, VK_TTALK);
::RegisterHotKey(m_hWnd, VK_TEND_ID, ONE_SHOT_MOD, VK_TEND);

...

// wait for and handle the hot key messages
afx_msg LRESULT MyappDlg::OnHotkey( WPARAM wParam, LPARAM lParam )
{
switch (lParam >> 16)
{
case VK_TTALK:
// reregister VK_TTALK to get the next key press
::RegisterHotKey(m_hWnd, VK_TTALK_ID, ONE_SHOT_MOD, VK_TTALK);
// handle the keypress...
break;
case VK_TEND:
// reregister VK_TEND to get the next key press
::RegisterHotKey(m_hWnd, VK_TEND_ID, ONE_SHOT_MOD, VK_TEND);
// handle the keypress...
break;

...

 

So there you have it. Each time the Send and Hang-up buttons are pressed you get a notification and you don’t have to worry about interfering with the normal operations of each button.

Labels: Windows Mobile