Using the ‘Open File’ and ‘Save File’ dialogs, GetOpenFileName and GetSaveFileName APIs

Recently, someone on the MSDN forum asked if there are any built-in ‘Open File’ and ‘Save File’ dialogs available in the Windows Mobile platform. The answer, of course, is yes. The APIs that get the task done are GetOpenFileName() and GetSaveFileName(). These APIs allow the user to select directories or files for opening or saving. I wrote a small application to demonstrate how to use these APIs. The application has a multiline edit control and menu options for opening or saving text files (see video at the end). When you open a text file, the files contents are shown on the edit control, and saving to a file writes the contents of the edit control to a user selected text file. Pretty simple.

First, lets take a look at GetOpenFileName() API, the DoOpenFile() method in the application reads the contents of the file and writes it to the edit control, here is the function: (error checking is left out, as usual)

1. Get the full path to the file
2. Read the contents of the file into a buffer
3. Convert the buffer into wide char
4. Display the wide chars on the edit control

BOOL DoOpenFile(HWND hDlg)
{
    TCHAR   szFile[MAX_PATH] = TEXT("\0");
    char    *szFileContent = NULL;
    OPENFILENAME   ofn;
    HANDLE hFile = INVALID_HANDLE_VALUE;
    DWORD dwFileSize = 0, bytesToRead = 0, bytesRead = 0;
   
    memset( &(ofn), 0, sizeof(ofn));
    ofn.lStructSize   = sizeof(ofn);
    ofn.hwndOwner = hDlg;
    ofn.lpstrFile = szFile;
    ofn.nMaxFile = MAX_PATH;
    ofn.lpstrFilter = TEXT("Txt (*.txt)\0 *.txt\0");  
    ofn.lpstrTitle = TEXT("Open File");
    ofn.Flags = OFN_EXPLORER;

    //get the filename the user wants to open
    if (GetOpenFileName(&ofn))
    {
        //ofn.lpstrFile contains the full path to the file, get a handle to it
        hFile = CreateFile(ofn.lpstrFile, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

        if (hFile == INVALID_HANDLE_VALUE)
            return FALSE;

        //get file size in bytes
        dwFileSize = GetFileSize(hFile, NULL);

        szFileContent = (char*)malloc(dwFileSize+1);
       
        memset(szFileContent, 0, dwFileSize+1);

        //read the files contents into a buffer
        if (ReadFile(hFile, szFileContent, dwFileSize, &bytesRead, NULL))
        {
            TCHAR *wszTemp = NULL;
            HWND hEdit = NULL;

            wszTemp = (TCHAR*)malloc(bytesRead*sizeof(TCHAR));

            //convert the chars in buffer to wide chars
            mbstowcs(wszTemp, szFileContent, bytesRead);
            hEdit = GetDlgItem(hDlg, IDC_EDIT);

            //set the content of edit control
            SetWindowText(hEdit, wszTemp);

            free(wszTemp);
        }

        //free resources
        free(szFileContent);
        CloseHandle(hFile);
    }

    return TRUE;
}

The APIs and the OPENFILENAME structure are explained well in the MSDN documentation, so I am not going to repeat the same things here. Follow the links.

The DoSaveFile() method in the application allows the user to save the contents of edit control into a file, here is the code:

1. Get the full path to the file
2. Read the contents of edit control into a wide char buffer
3. Convert the wide char into char (multibyte string)
4. Write the chars to the file

BOOL DoSaveFile(HWND hDlg)
{
    TCHAR   szFile[MAX_PATH] = TEXT("\0");
    OPENFILENAME   ofn;
    HANDLE hFile = INVALID_HANDLE_VALUE;
   
    memset( &(ofn), 0, sizeof(ofn));
    ofn.lStructSize   = sizeof(ofn);
    ofn.hwndOwner = hDlg;
    ofn.lpstrFile = szFile;
    ofn.nMaxFile = MAX_PATH;
    ofn.lpstrFilter = TEXT("Text (*.txt)\0*.txt\0");  
    ofn.lpstrTitle = TEXT("Save File As");
    ofn.Flags = OFN_HIDEREADONLY;
    ofn.lpstrDefExt = TEXT("txt");

    //get the filename the user wants to save to
    if (GetSaveFileName(&ofn))
    {
        HWND hEdit = NULL;
        DWORD dwTextLen = 0, bytesWritten = 0;
        TCHAR *wszEditText = NULL;
        char *szEditText = NULL;

        //ofn.lpstrFile contains the full path of the file, get a handle to it
        hFile = CreateFile(ofn.lpstrFile, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

        if (hFile == INVALID_HANDLE_VALUE)
            return FALSE;

        hEdit = GetDlgItem(hDlg, IDC_EDIT);

        //get the text length of the edit controls contents
        dwTextLen = GetWindowTextLength(hEdit);

        wszEditText = (TCHAR*)malloc((dwTextLen+1)*sizeof(TCHAR));

        memset(wszEditText, 0, (dwTextLen+1)*sizeof(TCHAR));

        //read edit controls contents into buffer
        GetWindowText(hEdit, wszEditText, dwTextLen+1);

        szEditText = (char*)malloc(dwTextLen+1);
       
        //convert the wide char read from edit control to char
        wcstombs(szEditText, wszEditText, dwTextLen);

        //save the contents into file
        if (WriteFile(hFile, szEditText, dwTextLen, &bytesWritten, NULL))
        {
        }

        //free resources
        free(wszEditText);
        free(szEditText);
        CloseHandle(hFile);
    }
   
    return TRUE;
}

Here is a video demo of how things work,  

 

Fun with menus Part II, Radio Menu Items and CheckMenuRadioItem()

Previously – Fun with menus – Part I

A few days back I set about trying to get radio items into menus. This is helpful if you want only one of the items in the menu to be active at a time, say, for e.g. a "Select Level" popup menu which has "Level 1", "Level 2" and "Level 3" subitems and only one of them needs to be shown as active or currently selected. You get the idea. No? Here, this pic should help,

Radio Menu Items 

A bit of searching led me to the CheckMenuRadioItem() API, and I thought, this is simple. I just need to get the handle to the popup menu, and pass the identifier of the subitem I want selected. And done. Turns out ‘get the handle to the popup menu‘ part isn’t very straight forward.

For future references in this post, here is the menu bar and the popup menu that I used in the resource script (refer pic above)

the menubar,
IDR_MENU SHMENUBAR DISCARDABLE
BEGIN
    IDR_MENU_POPUP,
    2,
    I_IMAGENONE, IDM_OK, TBSTATE_ENABLED, TBSTYLE_BUTTON | TBSTYLE_AUTOSIZE, IDS_OK, 0, NOMENU,
   
    I_IMAGENONE, IDR_MENU_POPUP, TBSTATE_ENABLED, TBSTYLE_DROPDOWN | TBSTYLE_AUTOSIZE,
    IDS_MENU, 0, 0,
END

the popup menu,
IDR_MENU_POPUP MENU DISCARDABLE
BEGIN
    POPUP "Menu"
    BEGIN
        MENUITEM "Toolbox..",    IDM_MENU_TOOLBOX
        POPUP "Speed"
        BEGIN
            MENUITEM "8x",        IDM_MENU_8X
            MENUITEM "16x",        IDM_MENU_16X
            MENUITEM "32x",        IDM_MENU_32X
        END
        MENUITEM "Settings..",    IDM_MENU_SETTINGS
        MENUITEM SEPARATOR
        MENUITEM "Exit",        IDM_MENU_EXIT
    END
END

 

What I did wrong

I looked up the functions available with menus and it seemed easy, LoadMenu(), GetSubMenu() and CheckMenuRadioItem() should do the trick, so here is the handler for the menuitem ‘8x‘, under WM_COMMAND; the handler tries to set ‘8x‘ as the current selection,

case IDM_MENU_8X:
    {
        HMENU hMenu = NULL, hSubMenu = NULL, hSubSubMenu = NULL;

        //handle to the menu bar
        hMenu = LoadMenu(g_hInst, MAKEINTRESOURCE(IDR_MENU_POPUP));

        if (hMenu)
        {
            TCHAR szText[128] = TEXT("");
            int i = -1;

            //handle to the menu "Menu"
            hSubMenu = GetSubMenu(hMenu, 0);

            MENUITEMINFO mii;

            ZeroMemory(&mii, sizeof(mii));
            mii.cbSize = sizeof(MENUITEMINFO);
            mii.fMask = MIIM_TYPE;
            mii.fType = MFT_STRING;
            mii.dwTypeData = szText;
            mii.cch = 127;
            i = GetMenuItemInfo(hSubMenu, 1, TRUE, &mii); // mii.dwTypeData = "Speed"

            ZeroMemory(&mii, sizeof(mii));
            mii.cbSize = sizeof(MENUITEMINFO);
            mii.fMask = MIIM_TYPE;
            mii.fType = MFT_STRING;
            mii.dwTypeData = szText;
            mii.cch = 127;

            //handle to the menu "Speed"
            hSubSubMenu = GetSubMenu(hSubMenu, 1);

            i = GetMenuItemInfo(hSubSubMenu, 1, TRUE, &mii); //mii.dwTypeData = "16X"

            i = CheckMenuRadioItem(hSubSubMenu, IDM_MENU_8X, IDM_MENU_32X, IDM_MENU_8X, MF_BYCOMMAND);
        }
    }
    break;
 

GetMenuItemInfo() api and MENUITEMINFO structure were used while debugging, just to make sure that the menu handles that I was getting were the right ones. All API calls LoadMenu(), GetSubMenu() and CheckMenuRadioItem() were successful, from the return values at least. There was one problem however, the radio item ‘dot’ never showed up. Then I tried to experiment a bit with getting menu handles by position, the result still the same. When I ran out of tricks to pull, I tried to set the radio menu using SetMenuItemInfo(), and a few random variations of GetSubMenu() by menu identifier and by position etc. Darn thing never showed up! It all meant one thing only, there must be something wrong with the menu handles themselves, even though they were valid.

The right way

So next I looked up the samples that ship with the SDK and found a CECamera sample that made use of radio menu items. From what I could tell, it looked like LoadMenu() isn’t the right way to get a handle to the main popup menu. Under WM_CREATE message when you are setting up the application and creating the menu bar using SHCreateMenuBar(), you also do the following,

            if (!SHCreateMenuBar(&mbi))
            {
                g_hWndMenuBar = NULL;
            }
            else
            {
                g_hWndMenuBar = mbi.hwndMB;
 

                //get a handle to the main popup menu
                g_hMainMenu = (HMENU)SendMessage(mbi.hwndMB, SHCMBM_GETSUBMENU, 0, IDR_MENU_POPUP);

                //set the default selection to 8x
                hSubMenu = GetSubMenu(g_hMainMenu, 1);
                CheckMenuRadioItem(hSubMenu, IDM_MENU_8X, IDM_MENU_32X, IDM_MENU_8X, MF_BYCOMMAND);
            }

 

So you send a message to the main menubar window, asking for the popup menu handle using SHCMBM_GETSUBMENU. g_hMainMenu and hSubMenu are both HMENU types. When the application showed up ‘8x‘ was selected by default. The handlers for 16x and 32x set themselves as the current selection, so under WM_COMMAND we have,

case IDM_MENU_8X:                   
    hSubMenu = GetSubMenu(g_hMainMenu, 1);
    CheckMenuRadioItem(hSubMenu, IDM_MENU_8X, IDM_MENU_32X, IDM_MENU_8X, MF_BYCOMMAND);
    break;

case IDM_MENU_16X:
    hSubMenu = GetSubMenu(g_hMainMenu, 1);
    CheckMenuRadioItem(hSubMenu, IDM_MENU_8X, IDM_MENU_32X, IDM_MENU_16X, MF_BYCOMMAND);
    break;

case IDM_MENU_32X:
    hSubMenu = GetSubMenu(g_hMainMenu, 1);
    CheckMenuRadioItem(hSubMenu, IDM_MENU_8X, IDM_MENU_32X, IDM_MENU_32X, MF_BYCOMMAND);
    break;
 

It worked. Video follows,

 

RSS Readers, Aggregators.. whats that again?

I am surprised by the number of people I meet who don’t know or have not heard about RSS Readers or Aggregators. So when I ask them "How do you keep track of news and blogs you follow?", they say "Well, I go to that website and check for updates". And I say to myself, "yes, the dinosaurs used to do the same".

So the timing of this Wired article couldn’t have been better,
How To Consume News Media


How to change the text of a softkey menu?

To change the text of a softkey menu item, all you have to do is pretend that they are buttons. Well, they are specialized buttons in any case. So in order to change its property (in this case the ‘text’) you will have to use the TBBUTTONINFO structure along with TB_GETBUTTONINFO and TB_SETBUTTONINFO messages. Lets dive into the code:



Note: Error checking is omitted for obvious reasons.



    TCHAR szText[128] = TEXT("");

    TBBUTTONINFO tbi;

    ZeroMemory(&tbi, sizeof(tbi));



    tbi.cbSize = sizeof(tbi);

    tbi.dwMask = TBIF_TEXT | TBIF_COMMAND;

    tbi.pszText = szText;

    tbi.cchText = sizeof(szText);

    tbi.idCommand = IDM_MARK_UNMARK;



    SendMessage(g_hWndMenuBar, TB_GETBUTTONINFO, (WPARAM)IDM_MARK_UNMARK, (LPARAM)&tbi);



    if (!wcscmp(szText, L"Mark"))

    {

        wcscpy(szText, L"Unmark");

    }

    else

    {

        wcscpy(szText, L"Mark");

    }



    SendMessage(g_hWndMenuBar, TB_SETBUTTONINFO, (WPARAM)IDM_MARK_UNMARK, (LPARAM)&tbi);

So we fill up the TBBUTTONINFO structure and then send TB_GETBUTTONINFO message to the menu bar. After this call returns, szText will contain the text of the menu item. We switch the contents of szText and then send a TB_SETBUTTONINFO message. And the text on the menu item changes.

 

Couple of seasons back I was working on an application which let the user "Mark" and "Unmark" dates on a calendar control. It was for a smartphone, so I thought this technique is quite handy and just qualifies for a post.



Here is a video of it in action,

 

Displaying a context menu in your application

Context menus really add to the user experience. You may decide to display a context popup menu when the user taps-and-holds or double-taps on the touch screen. In this post we will see how a few lines of code enable you to do just that.

 

While reading about popup menus I came across the WM_CONTEXTMENU message. According to the windows mobile documentation that I referred this message is sent to a window when the user right clicks on the window’s client area. Since I haven’t yet seen a windows mobile device which supports right click functionality, I decided to leave it at that. And for this demonstration I display my context menu whenever the user double clicks (or double taps) on the screen. Remember that for your window to recieve a WM_LBUTTONDBLCLK message when the user double clicks, you should set the CS_DBLCLKS style of your WNDCLASS structure when you do a RegisterClass(). Without this your window will not recieve the double click message.

 

If you are comfortable with the gesture api’s, which Windows Mobile 6.5 supports, then you could use the GID_HOLD message. This message is sent when the user taps and holds on the screen for a specified amount of time.

 

When my main window recieves a WM_LBUTTONDBLCLK message, I call the following function:

//error checking omitted on purpose

POPUP_ITEMS pi[] = {

    {IDM_POPUP_ABOUT, TEXT("About")},

    {IDM_POPUP_EXIT, TEXT("Exit")}

};



int ShowContextMenu(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)

{

    POINT pt;

    pt.x = LOWORD(lParam);

    pt.y = HIWORD(lParam);



    ClientToScreen(hWnd, &pt);



    HMENU hMenu = CreatePopupMenu();



    for (int i=0; i< sizeof(pi)/sizeof(pi[0]); i++)

    {

        InsertMenu(hMenu, 0xFFFFFFFF, MF_BYPOSITION | MF_STRING | MF_ENABLED, pi[i].id, pi[i].szText);

    }



    return TrackPopupMenu(hMenu, TPM_LEFTALIGN | TPM_TOPALIGN | TPM_RETURNCMD, pt.x, pt.y, 0, hWnd, NULL);



}



The POPUP_ITEMS structure is defined to hold an integer and a string,



typedef struct _popup_items_

{

    int id;

    TCHAR szText[128];

} POPUP_ITEMS;

In the function, I first get the client co-ordinates of the point where the user double clicked and convert them to Screen co-ordinates. TrackPopupMenu() api, which displays the popup menu, expects the co-ordinates to be passed w.r.t the screen.

 

CreatePopupMenu() creates an empty menu. Use InsertMenu() api to add items into the menu and TrackPopupMenu() will display the popup menu.

 

When you set TPM_RETURNCMD flag in the call to TrackPopupMenu(), the function will return with the identifier of the menu item which the user selected. If the user clicks outside, without selecting anything, then the function simply returns zero. These functions are simple to use and the MSDN documentation will suffice. I have provided links to msdn above.

 

Finally, here is the video,

 

Applications: Painting problems with windowed directdraw app

Well, the painting problem that I mentioned in my last post is solved. Thanks to Joel for helping me out (:

 

When I look in retrospect, the answer was in the question all the time. Painting problem, WM_PAINT message. It was stupid of me to have missed that (; But looking at the bright side I have a much better understanding of how WM_PAINT works now. The only thing that I needed to do was to display the frame every time my window got a WM_PAINT message. So that our client area is re-drawn and is displayed correctly. Just call DisplayFrame() inside WM_PAINT. That is all.

 

Here’s a video of how things are working now, pretty smooth (:

 

How to embed an exe inside another exe as a resource and then launch it

While working on a utility project today, I stumbled upon wanting to embed an executable inside another executable. Sounds fun doesn’t it? And what is even more fun is to be able to launch the embedded exe!

 

Basically, here’s how it works. You embed Foo.exe inside Bar.exe. And by embed I mean, add Foo.exe as a resource in Bar.exe. And then from Bar.exe’s code, you can launch Foo.exe using CreateProcess().

 

So before answering the "Why?" lets answer the "How?"

 

Rename Foo.exe to Foo.txt. We do this just to be safe and to prevent the resource compiler (manager) from throwing unwanted errors. Now add Foo.txt as a normal resource in Bar.exe. Create an entry in Bar.exe’s resource script as below:



IDR_FOO     RCDATA       "Foo.txt"

And of course, you need to #define IDR_FOO in the resource header file. Just make sure its a unique value.

 

The steps are:

 

1) From within Bar.exe’s code, get a pointer to the first byte of Foo.txt
2) You should know the size of Foo.txt in bytes.
3) Using the pointer copy that many bytes into a separate file. ("\\Voila.exe")
4) Call CreateProcess() on "\\Voila.exe"
5) And voila!

 

Let’s dive into the code: (from the entry point of Bar.exe)



    HRSRC hrsrc = NULL;

    HGLOBAL hGlbl = NULL;

    BYTE *pExeResource = NULL;

    HANDLE hFile = INVALID_HANDLE_VALUE;

    DWORD size = 7168;//hardcoding the size of the exe resource (in bytes)



    hrsrc = FindResource(hInstance, (LPCWSTR)IDR_FOO, RT_RCDATA);

    if (hrsrc == NULL)

        return FALSE;



    hGlbl = LoadResource(hInstance, hrsrc);

    if (hGlbl == NULL)

        return FALSE;



    pExeResource = (BYTE*)LockResource(hGlbl);

    if (pExeResource == NULL)

        return FALSE;

   

    hFile = CreateFile(L"\\Voila.exe", GENERIC_WRITE|GENERIC_READ, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);



    if (hFile != INVALID_HANDLE_VALUE)

    {

        DWORD bytesWritten = 0;

        WriteFile(hFile, pExeResource, size, &bytesWritten, NULL);

         CloseHandle(hFile);

    }





    int ret = CreateProcess(L"\\Voila.exe", NULL, NULL, NULL, FALSE, 0, NULL, NULL, NULL, &pi);

First, we find the resource using its resource identifier and then load it. Next we use LockResource() to get the pointer to the first byte of the resource data, which in this case would be the executable code. One downside, if you may say so, is that you need to know the exact size of the executable beforehand. Of course its easy to find out and I think its not a problem to hardcode because the size of the embedded executable won’t change. But if you still insist, then you can read it from the registry or a file or something.

 

Once you get the pointer, just copy all the bytes into another file, using WriteFile() API.

 

And finally do a CreateProcess() on the file you just created.

 

If you happen to know any alternate ways of doing this, please leave a message.

 

And coming to the important question of  "Why would any sane person want to embed an exe within an exe?" Well, you will have to wait till the next post to find out (;

 

Aloha!
 
Update:
I have changed the code above to copy all the 7168 bytes into "Voila.exe" in one go, instead of copying byte after byte. And just to be clear this is not a production code, it is just to demonstrate what can be done. Of course, creating the file "Voila.exe" in the root folder is not ideal and it may fail on many devices, and you also need to clean up by deleting the exe file, which can be done using the DeleteFile() API. Ideally, "voila.exe" should be created not in the root folder but instead using SHGetSpecialFolderPath() API passing for e.g. CSIDL_APPDATA. I left out all these details because I thought they were trivial for this post.
 

Applications: Appending text to a multiline Edit control

Today I was developing a small utility application where I needed to append some text to a multiline edit control. When I ran through the list of Edit control messages, I could not find any that could be used to append text. WM_SETTEXT was overwriting the previous contents. And doing a WM_GETTEXT first, appending to it and then WM_SETTEXT seemed like an overkill.

 

A little bit of searching led me to EM_REPLACESEL message. This message is used to replace the currently selected text in the edit control with the specified text but there’s a bit more to it. If there is no selected text in the edit control then the specified text is inserted at the current caret position. Since what I was using was a read-only edit control this works for me but I am not sure if it will work in all cases. I wonder if we need a SETCARETPOS message. So anyways, here’s how to append text in an edit control:



HWND hWndEdit = GetDlgItem(g_hDlg, IDC_EDIT_BOX);


SendMessage(hWndEdit, EM_REPLACESEL, (WPARAM)FALSE, (LPARAM)str);

Applications: Getting device information (embedded exe, rapi and more)

I was working on this application which runs on the PC and gets information about the windows mobile device which is connected to the PC over active sync. Now there are a couple of ways in which you can do this:

 

1) Create a PC app which gets all the information using RAPI api’s and displays it.

 

2) Create two binaries, one for the PC and one for the WinMob device. The PC app launches the WinMob app remotely using RAPI API’s, the WinMob app runs and writes all the information it can gather into a file on the device. The PC app then remotely reads this file and displays it to the user. The let down is that you need to create/maintain two binaries but the advantage is that you are not limited to the RAPI api’s, all device API’s are at your disposal.

 

3) Create a PC app which uses the embedded exe approach. This is a bit loony but works (; And yes, this is what I used in my app.

 

Let me digress here for people who do not know about RapiConfig.exe. RapiConfig is tool that ships with the Windows Mobile SDK’s and can be used to test out CSP’s (Configuration Service Provider) by using provisioning XML’s. RapiConfig works over Active Sync. So basically you run this tool from command line like:



C:\>RapiConfig /P config.xml



This command has the same effect as calling DMProcessConfigXML() API on the device with config.xml’s contents.

And then I came across the DeviceInformation CSP. The DeviceInformation service provider, as the name gives it away, provides information about the device and it can also be used to set information but we won’t go into that. So you give this service provider an XML like this:



<wap-provisioningdoc>

    <characteristic type="DeviceInformation">

       <parm-query name="OperatingSystem" />

       <parm-query name="OperatingSystemVersion" />

       <parm-query name="Product" />

       <parm-query name="ProductVersion" />

    </characteristic>

</wap-provisioningdoc>



and it spits out the response like this:



<wap-provisioningdoc>

    <characteristic type="DeviceInformation">

        <parm name="OperatingSystem" value="Microsoft Windows CE"/>

        <parm name="OperatingSystemVersion" value="Version 5.2 (Build 1235)"/>

        <parm name="Product" value="Windows Mobile® 6 Standard"/>

        <parm name="ProductVersion" value="CE OS 5.2.1235 (Build 17740.0.2.0)"/>

    </characteristic>

</wap-provisioningdoc>

So while developing this application I thought I could use some of RapiConfig. I shouldn’t have to write everything from scratch. I’ll just find out the SDK installation directory on the PC somehow, run this tool with my xml, parse the output xml and display it. But wait, what if the PC does not have the SDK installed. This simple application can’t depend on that. And that is when I had this crazy idea of embedding RapiConfig.exe within my application (; I wrote up a small test app to find out if this approach would even work. It did. You can get the details here in my previous post.

 

So thats the way it works. The application first extracts the embedded RapiConfig exe and the xml file into the current directory where the app is running from. Then it runs RapiConfig passing it the extracted xml. After RapiConfig completes executing and terminates, it creates a RapiConfigOut.xml in the same directory. The application opens this output xml, parses it and displays the information to the user.

 

If no device is connected then RapiConfig keeps waiting for the device to connect. To prevent this I used a few RAPI api’s in my application to find out if a device is connected using Active Sync, and only if it is, I launch RapiConfig exe. Otherwise, I display a message saying "Please make sure the device is connected.. blah bla"



A few points worth jotting down



(*) After extracting the RapiConfig exe, I was calling CreateProcess() on it to launch it:



wsprintf(lpCmdLine, L"/P %s", XML_FILENAME);

ret = CreateProcess(EXE_FILENAME, lpCmdLine, NULL, NULL, TRUE, 0, NULL, NULL, &sui, &pi);

But this didn’t work for me. The output XML was the exact same as the input xml, without any data. Launching the same extracted exe from command line worked! How was this possible? I tried a couple of things with SECURITY_ATTRIBUTES, inheriting handles etc but none worked. The documentation for CreateProcess() mentioned that the first parameter to it maybe be NULL, in that case lpCmdLine parameter should include the exe name. And when I gave this a try, it worked! So now you call CreateProcess() like below:



wsprintf(lpCmdLine, L"%s /P %s", EXE_FILENAME, XML_FILENAME);

ret = CreateProcess(NULL, lpCmdLine, NULL, NULL, FALSE, 0, NULL, NULL, &sui, &pi);

(*) Some while back I had tried to fiddle with RAPI. I had tried to launch an exe on device remotely from the PC. But it didn’t work. Turns out I was calling CeRapiInit() incorrectly. I was calling it directly, not on any object but actually you need to call it on the IRapiSession interface. I should really be reading the documentation carefully before jumping to the code (;





Here are a few snapshots of the application, this is with craddled emulator.

Oh and the DeviceInformation doesn’t give you the resolution of the device. I used CeGetSystemMetrics() to get that part of information. And if there is any other details that you would want on this app, please leave a comment.

Good day!