on the wish of the one or other user I extended the RDP AutoLogin code and we now reached level 4.

The new code simply has only one extension, it supports the color depth selection. Also the color depth and other settings are visible on the dialog of Remote Desktop Mobile, the settings itself are done via the Default.rdp file. But you are right, RDP_AutoLogin also controls some of the dialog items directly.

Source code

...
Domain:s:
ColorDepthID:i:3
ScreenStyle:i:0
DesktopWidth:i:640
DesktopHeight:i:480
UserName:s:rdesktop
...
ServerName:s:192.168.128.5
SavePassword:i:1
...

The color depth setting supports two modes, 8 Bit with 256b colors (ColorDepthID:i:1) and 16 Bit with ~65000 colors (ColorDepthID:i:3).

Source code

REGEDIT4
 
[HKEY_LOCAL_MACHINE\Software\RDP_autologin]
"FitToScreen"="1"
"FullScreen"="1"
"Status"="connecting..."
"Save Password"="1"
"Domain"=""
"Password"="Intermec+2004"
"Username"="rdesktop"
"Computer"="192.168.0.130"
"DesktopWidth"=640
"DesktopHeight"=480
"startOnExit"="\\rdp_keepBusy.exe"
"execargs"="noRDPstart"
"UseMouseClick"="0"	//added with version 3 to switch between mouse and keyboard simulation
"ColorDepth"=1		//added with version 4 to enable switching between 8 and 16 Bit colors

The code changes are small. Some code addition to read the value from the registry and some to write the rdp file:

Source code

void readReg(){
...
        //ColorDepth new with version 4
        if(RegReadDword(L"ColorDepth", &dwTemp) == 0)
            dwColorDepth=dwTemp;
...
}
void writeRDP(){
...
			else if(wcsstr(rdpLines[c].line, L"ColorDepthID")!=NULL){
				wsprintf(szTemp, rdpLines[c].line, dwColorDepth);  //3=HighColor(16Bit) or 1=(8Bit) color
			}
...
}

Additionally I have added a new project to the solution to enable to set all the settings not only via the registry but using a GUI application. RDP_Autologin_Settings is born:

As you see, there is also a small file browser integrated. The default OpenFile dialog of Compact Framework does not allow you to browse all directories, but only “\My Documents”.

RDP AutoLogin Settings Editor (exe): DOWNLOAD:RDP AutoLogin Settings editor - (Hits: 36, size: 10.45 kB)
source (Visual Studio 2008 WM5 SDK project): DOWNLOAD:RDP AutoLogin Settings editor Source Code - (Hits: 29, size: 21.23 kB)

RDP_AutoLogin (exe): DOWNLOAD:RDP AutoLogin Executable - (Hits: 31, size: 6.78 kB)
source (Visual Studio 2008 WM5 SDK project): DOWNLOAD:RDP AutoLogin Source Code - (Hits: 27, size: 56.85 kB)

RDP_KeepBusy (exe): DOWNLOAD:RDP KeepBusy (executable) - (Hits: 24, size: 3.17 kB)
RDP_KeepBusy (vs2008 WM5 SDK project): DOWNLOAD:RDP KeepBusy Source Code - (Hits: 28, size: 12.92 kB)

Have fun

Josef

Bookmark It

I want to summarize the role of function keys in Windows Mobile, former Pocket PC, as I got several questions each week on how to use or enable Function keys in this or that application.

Here is a simple information about how function keys work in Windows Mobile.

As example you have a web application which shows F3 and F4 as shortcuts to previous/next page:

SAP ITS Mobile screen Intermec Browser

Without some prepare this screen will not react on function keys! As the screen shows Intermec Browser (IB) with a SAP ITS Mobile form, you are able to define settings in IB to be able to really use the Function Keys.

Windows Mobile uses Function Key values for its own purpose. The usage can be retrieved by looking at winuserm.h of a Windows Mobile SDK:

Source code

//winuserm.h
...
#define VK_TSOFT1   VK_F1               // Softkey 1
#define VK_TSOFT2   VK_F2               // Softkey 2
#define VK_TTALK    VK_F3               // Talk
#define VK_TEND     VK_F4               // End
...
#define VK_TRECORD      VK_F10          // Record
#define VK_TFLIP        VK_F17          // Flip
#define VK_TPOWER       VK_F18          // Power
#define VK_TVOLUMEUP    VK_F6           // Volume Up
#define VK_TVOLUMEDOWN  VK_F7           // Volume Down
...
#define VK_TSPEAKERPHONE_TOGGLE VK_F16
#define VK_END_ALL_DATA_CALLS   VK_F15
...
#define VK_TSTAR    VK_F8               // *
#define VK_TPOUND   VK_F9               // #
...
#define VK_SYMBOL   VK_F11              // Symbol (SYM) key
 
#define VK_REDKEY   VK_F19              // Sent by a keypad that has a special red function key
#define VK_ROCKER   VK_F20              // Arrow keys came from a Rocker
#define VK_DPAD     VK_F21              // Arrow keys came from a DPAD
#define VK_ACTION   VK_F23              // Sent with VK_RETURN when doing Action on PPC rockers
 
#define VK_VOICEDIAL  VK_F24            // Key used to kick off voice dial recognition
#define VK_KEYLOCK    VK_F22            // Key used to lock the device
#define VK_KEYUNLOCK  VK_F25             // Key used to unlock the key lock
 
// Chorded keys.  DONE is VK_RWIN + VK_F6 and MOJI is VK_RWIN + VK_F7
#define VK_DONE     VK_F6                 // <OK/Close> hotkey code
#define MOD_DONE    (MOD_WIN | MOD_KEYUP) // <OK/Close> hotkey modifiers
 
#define VK_MOJI     VK_F7                  // Key used to switch between FE language layouts
#define MOD_MOJI    (MOD_WIN | MOD_KEYUP)  //Modifiers so MOJI goes to the shell
...

You see that many FunctionKey values are assigned to OS specific functions like Phone, END, Volume Up/Down etc.

So, you can normally not use Function Keys in your application to provide shortcuts to function calls. This is also true for client applications like Terminal Emulators (TE) like NaurTechTE and Intermec TE (ITE), browser based applications like Internet Explorer Mobile or Intermec Kiosk Mode Browser (IB), thin clients like Java client apps (ie. SAP ITS Mobile) or Remote Desktop client apps (ie Remote Desktop Mobile, zaDesktop).

Some of the kiosk mode apps provide a way to enable you to use Function Keys (see example at top). They can do so, as they use API calls like UnregisterFunc1 or AllKeys(TRUE) or GXOpenInput (deprecated!). These APIs instruct Windows Mobile OS to NOT catch and use Function Keys but handle them like ‘normal’ keys.

If you are the coder of an application using CPP, CSharp (C#), VB.NET, CPP or JAVA, you can use the Microsoft API function AllKeys(TRUE) in your code and Windows Mobile will not tamper the function keys.

If you are not the coder you may use UnregisterFunc1 (see my post “Freedom for Function Keys“). But be warned, there are applications that even then will not process Function Keys or do not forward them. For example Internet Explorer Mobile (IEM) will NOT process Function Keys except for internal functions like help or full-screen. Another bad example is Remote Desktop Mobile (RDM). It does not support Function Keys, even if you un-register them before you launch RDM, Function Keys will NOT be processed or transmitted to the host application. An alternative to RDM with function key support is rdesktopCE.

When you use UnregisterFunc1, you can check the Function Keys using a tool like KeyTest3AK. It will show the keydown and keyup values of keys and shows what happens if you use AllKeys():

More posts about AllKeys

Bookmark It

there are now more and more full VGA rugged devices coming. And some customers are still using Remote Desktop Mobile to run there application on the small screens. Unfortunately some of the coders use application screen layouts hard coded to QVGA (240×320). Now with a VGA capable Windows Mobile device they get weird screens on the device.

The client (Remote Desktop Mobile) sends the server information about there screen sizes. As a VGA device can display 480×640 pixels, the hard coded 240×320 applications only use a quarter of the screen. The texts are very small and more or less unreadable.

The terminal server gets client resolution information:

Unscaled (left) VGA display of a QVGA application (with “Fit remote desktop to screen” NOT CHECKED) and on the right the same application with internal autoadjust to workscreen size:

As you can see in the right image above this line, it is no problem to show a form designed for QVGA to scale nice with the use of some code (as using WorkingArea.Width/Height and a table layout). But in the left image you see what happens to hard coded designed applications.

If you have the source code, you should change the design of your dialogs to be resolution aware, so it scales fine for QVGA and VGA (and whatever comes next).

If you do not have the code or can not change the application, you have to tell Windows Mobile to behave like the Remote Desktop Mobile application is NOT HI_RES_AWARE. That means you need to hack the exe file. I took a look at the Windows Mobile 6.5.3 wpctsc.exe (the Remote Desktop Mobile executable) and did not find the HI_RES_AWARE resource, so the OS must use the other mark to see that wpctsc.exe is HI_RES_AWARE. And yes, indeed, the PE header shows that wpctsc.exe has a subystem version of 5.2. With some PEInfo tool, you can hack the major subsystem version and just change it from 5 to 4.

When you start a application that is not HI_RES_AWARE, the Windows Mobile 6.5.3 OS will scale all UI elements for the application and the app will look fine and not only fill a quarter of the VGA screen. After changing the major subsystem version number, the first thing you will notice is the more coarse display of the menu items in the menu bar:

Left is the HI_RES_AWARE original app and on the right we have the hacked one (take a closer look ate the ellipses around the menu items).

When you use the hacked, not HI_RES_AWARE, application, the terminal server will see the client supports QVGA only (Client Resolution) and your hard coded application screens will look the same as on a QVGA capable device:

The attached wpctsc.exe is the hacked one with a subsystem major version number of 4 instead of 5. Use this on your Windows Mobile 6.5.3 device at your own risk. The file is not signed as the device I work with are not requiring signed exe files. The change to the exe file (after I dumped the OS files to my PC using itsutils) was simply done with mgeeky’s PEinfo code at GitHub.

If you can not copy the file on top of the original one on the device (\Windows\wpctsc.exe), you can use the syscache feature. Copy the wpctsc.exe to \Windows\System\SysCache directory and reboot the device. If the directory does not exist you just have to create it manually.

If you want to get the old wpctsc.exe back, just delete the file you copied. As the original wpctsc.exe is part of the OS (a XIP file), you can not delete the file but you can copy a file with the same name on top of it. When you delete this copied file, the original is back in place. So, there is no harm in testinng the exe.

Bookmark It

as MS does not change it, the Remote Desktop Mobile application still disconnects a session after 10 minutes idle time.

Although there is a solution for Windows Mobile 6.1 (http://www.hjgode.de/wp/2009/09/18/wm6-1-remote-desktop-client-disconnects-after-10-minutes/) based on the posting of Rafael (MS Support), this will not work with Windows Embedded Handheld (WM6.5).

The TSSHELLWND will not react on mouse_event and you have to replace the calls by SendMessage and send the WM_MOUSEMOVE to the Terminal Server Input window.

The attached application will do so but it will start only on Int*rm*c devices. It sends a mouse_move message all 4 minutes to the TS input window and so the idle timer will not timeout.

If you ever need to stop RDMKeepbusy from running in the background, you will need StopKeepBusy which is part of the executable download.

For visual control, RDMKeepbusy shows a small blinking line in the task bar:
green = Remote Desktop window found and input window is active
yellow = Remote Desktop window found, but no input window active
red = Remote Desktop window not found

Bookmark It

Intro and Background

Some times ago I found that message of Jay Sorg and retrieved a copy of his code for a native rdesktop win32 version. I played a little and got the code compile with Visual Studio 2005 with the Windows Mobile SDK.

I tried to implement windows clipboard support to enhance the transfer of texts between the client and server, but unfortunately I was not successful yet. Hopefully someone jumps in and helps enhancing the code and adds some features.

Rdesktop is open source and you can go with the wince implementation here, but if it does not work for you, you have either change the code yourself (and publish it) or find someone that is able to do for you.

There is a template uiports/xxxwin.c in the actual rdesktop source you can use as a starter to compile the actual rdesktop version for windows mobile if you manage to get all the dependencies to work. If you success, forget this post and go with this version (maybe you leave me a note?).

Why another Remote Desktop/Terminal Server Client?

The Windows Mobile Remote Desktop Client (or Remote Desktop Mobile, RDM) lacks some useful features available in the Windows CE version or the Desktop Windows version:

• No automated login
• No kiosk mode
• Function keys are not sent to server
• …

The first item is essential if you like to start a Terminal Server session without user intervention.

The second item is important for using RDM in a production environment.

The third item is useful to run applications on the Terminal Server (TS) that use Function keys.

Commercial RDM

There are some commercial remote desktop clients available for windows mobile:

• Mochasoft RDP client
  “Windows 200x servers and terminal servers are not supported, as to a Microsoft patent license.”
• zaDesktop
  This is currently in an early state.
• RDP Finster
  Not really clear where this comes from.

I assume some of the commercials are either using mstscax or rdesktop code. Some time ago MS published the RDP documentation. Maybe the commercial apps did start from there. Going with the TSC COM library mststcax would be great, but who has the doc for this? For desktop PCs it is documented but not for windows mobile. If someone has a doc to this leave me a note. Then we can start to write a TSC around this library.

There are also some rewritten TSC for the desktop not using mstscax. One is called ProperJavaRDP and maybe a good starting point to rewrite a dotnet based native TSC for windows mobile.

Usage of the free opensource rdesktop-ce

You can start winrdesktop on windows mobile either with an ini file or with command line arguments:

Sample winrdesktop.ini

(place either in program dir or in root)

[main]
server=192.168.128.5
port=3389
username=YourUserName
password=YourPassword
bpp=16
geometry=1024x768
#fullscreen

server : provide the server IP or DNS host name
port : provide the port to use for RDP, usually 3389
username : provide the login user name for the terminal client session
password : provide the password of the user
bpp : define the bits per pixel to be used (number of colors per pixel)
geometry : define the size of the remote desktop window width x height An application to be used on windows mobile devices should match the screen size of the device. For example 240×320 (QVGA). Otherwise the user has to scroll the window to get access to all of the remote screen.
fullscreen : currently not supported

UPDATE 23. nov 2010:

fullscreen now supported. Fullscreen will switch rdesktop to not show a caption and no menu bar. If geometry matches the device’s screen size, there will also be no scrollbars.

This screenshot was taken of an app I wrote running on a Windows 2003 server of a QVGA device with following winrdesktop.ini:

[main]
server=192.168.128.5
port=3389
username=rdesktop
password=rdesktop
bpp=16
geometry=240x320
fullscreen

Rdesktop usage

Command line

WinRDesktop [-g widthxheight] [-t port] [-a bpp]
    [-f] [-u username] [-p password] [-d domain]
    [-s shell] [-c working directory] [-n host name]
    server-name-or-ip

options are the same as in winrdesktop.ini plus:

-d domain : specify the domain of the user login
-s shell : define a shell to use on TSC
-c working directory : define a working directory for the session
-n host name : specify the host name to use for the client (visible on TSC)

Restrictions of current code

See googlecode issues for a list of known restrictions.

Downloads

Windows Mobile Executable and INI sample file at googlecode
Source code: see googlecode

Bookmark It

• screen_width and height for WriteRDP()
• read FitToScreen from reg in readReg()
• check for already running process of startOnExit in startTSC(). Although I think check for running a process multiple times should be done in the target process.

Update 16. may 2011: converted code for VS2008(windows mobile 6 sdk), see Downloads at bottom

UPDATE 23 june 2010: new registry option to switch between MouseClick and Keyboard simulation:

REGEDIT4
[HKEY_LOCAL_MACHINE\Software\RDP_autologin]
"FitToScreen"="1"
"FullScreen"="1"
"Status"="connecting..."
"Save Password"="1"
"Domain"=""
"Password"="Intermec+2004"
"Username"="rdesktop"
"Computer"="192.168.0.130"
"DesktopWidth"=640
"DesktopHeight"=480
"startOnExit"="\rdp_keepBusy.exe"
"execargs"="noRDPstart"
"UseMouseClick"="0"    //added with version 3 to switch between mouse and keyboard simulation

Some days ago I published my RDP_Autologin code: RDP_Autologin

As there were some screen metrics hardcoded and more and more devices come with a VGA screen the hardcoded QVGA values will not match. So I extended the first version and implemented some additional logic and settings.

First, the emulated screen tap has been adjusted to depend on the device screen width and height. For that I included the HIRES_AWARE resource to get the real screen size.

...
	DWORD dX = (0xFFFF / iScreenWidth) * (80); // changed from 13 to width=240, 1/3=80
	DWORD dY = (0xFFFF / iScreenHeight) * (iScreenHeight - 13);
...
BOOL getScreenSize(){
	int iScreenX = GetSystemMetrics(SM_CXSCREEN);
	int iScreenY = GetSystemMetrics(SM_CYSCREEN);
	DEBUGMSG(1, (L"\ngetScreenSize: x=%i, y=%i\n", iScreenX, iScreenY));
	if(iScreenX>0)
		iScreenWidth=iScreenX;
	if(iScreenY>0)
		iScreenHeight=iScreenY;
	if(iScreenX+iScreenY > 0){
		_itow(iScreenWidth, sScreenWidth, 10);
		_itow(iScreenHeight, sScreenHeight, 10);
		return TRUE;
	}
	else
		return FALSE;
}
...

The rdp file defaults for desktop width and height will also be calculated but you can set the default to use via the registry.

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\RDP_autologin]
"startOnExit"="\Windows\rdp_keepbusy.exe" "DesktopHeight"=dword:000001E0 "DesktopWidth"=dword:00000280
"Computer"="192.168.0.2"
"FitToScreen"="0"
"FullScreen"="0"
"Username"="rdesktop"
"Password"="xxxx"
"Domain"=""
"Save Password"="1"
"Status"="connecting..."

As you can see, I added a line where you can specify an application that will be started at the end of the autoconnect process: startOnExit.

Downloads:

evc4 source code: DOWNLOAD:rdp autologin 2 evc4 source code - (Hits: 379, size: 113.37 KB)

Armv4i executable: DOWNLOAD:rdp autologin 2 Armv4i executable - (Hits: 404, size: 6.47 KB)

NEW: Version 3 adds new option to let the app use MouseClick or Keyboard Simulation

Update 18. nov 2011: DOWNLOAD:Updated rdp_auologin (screen_width/height) - (Hits: 47, size: 159.78 kB)

Exe File (ArmV4i) DOWNLOAD:RDP Autologin Version 3 - New version with Mouse or Keyboard simulation switch in registry: UseMouseClick=DWORD 0/1 (Hits: 339, size: 6.56 kB)

eVC4 source code DOWNLOAD:RDP AutoLogin version 3 source code - eVC4 source code for my RDP_AutoLogin version 3 (Hits: 200, size: 131.73 kB)

NEW: VS2008 code and exe DOWNLOAD:RDPautologin Visual Studio 2008 code (and Release\\exe) - (Hits: 136, size: 144.01 kB)

Update 4.march 2011: Please also see http://blogs.msdn.com/b/raffael/archive/2009/09/11/remote-desktop-mobile-rdp-client-disconnects-after-10-minutes-of-inactivity.aspx about idle timeout

Bookmark It

As you may know, Remote Desktop Mobile (RDM) does not support auto-login. But sometimes you may want a user does not change settings and is directly connected to a Terminal Server. Ruggedized devices are often used in warehouses and the IT structure uses a terminal server to gather data and manage goods. Although I think Windows Mobile is not the right OS for such barcode scanner devices, you may have no choose and have to use a handheld computer with Windows Mobile instead one that uses Windows CE. The RDM or Terminal Service Client provided with Windows CE devices is much more flexible and can be configured by the OEM to enable you to auto-login into a Terminla Server (TS).

OK, the challenge was to automate the startup and login of RDM on a Windows Mobile 6.1 device. I started using embedded Visual C++ 4.0 although this is outdated by VS2005 and VS2008.

The idea was to launch the exe, fill in the values and click the Connect bar.

Finding the connect dialog window

Normally, on desktop windows, windows and there childs are located in there own tree (see desktop PC spy++ screenshot). On WM61 I found, that the RDM window (class=”TSSHELLWND”) and the Connect dialog (class=”Dialog”) are located side by side below the desktop window (see cespy screenshot). This makes it hard to find the right dialog, especially as the Connect Dialog does not have a unique window title (window text). The windows can be identified as belonging together by there processID.

RDM Connect Dialog

Filling the fields

Knowing the right window I was able to set the text entries by knowing there controlIDs (dialogs use ctrlIDs for easier access of the data, see scanTscDialog() in tscDialog.cpp). So the tool I did can fill in all connection details using SetWindowText().

Execute the Connect

The fields are filled with the connection details and now I needed a way to simulate a click onto the connect button (which is a menu in reality) to let the dialog execute a connect. I tried several approaches, the best is to use keyb_event although it works also by sending the TSC window the WM_USER message that is posted by the menu click. I found this WM_USER message within messages of cespy as I tapped on [Connect].

 //Solution three, best solution, ensure you use the scancode value too! AFAIK the scancode for F1 is always 0x70
keybd_event(VK_F1, 0x70, 0, 0);
 Sleep(30);
 keybd_event(VK_F1, 0x70, KEYEVENTF_KEYUP, 0);

I was unable to send TSSHELLWND nor the Dialog a click onto the menu option [Connect]. The menu seems to be not owned by either of these two visible windows. The menu bar looks like owned by the desktop window.

Sending the SoftKey1 (F1) was also unsuccessfull for window handles of TSSHELLWND and the Connect Dialog.

The pitfalls

Everything seems to work OK, but sometimes the tool was unable to fill the fields and execute the connect. I did search several hours and then I found, that the registry and a file is involved in the connect.

The tool always failed to autoconnect after the first clean boot. So I did a snapshot with the famous free SSNAP by “S-K tools” and found the changes that caused a manualy connect to be successfull.

Registry changes

First, the registry will get be changed, if you manually connect. As I did not like to have my tool to emulate a user typing into the fields using keybd_event, I added code, that does the same changes to the registry (see writeMRU() function in code). There are some more changes in registry, but fortunately I did not have to implement these too (see comments in “tscDialog.cpp”).

RDP file default.rdp

When you fill the connect dialog and then press [Connect] RDM will save your values in a file \Windows\default.rdp. You may know, that rdp files are commonly used on desktop windows to save/load Remote Desktop Session connection data. Yes, WM6.1 does use a similar technique.

The tool had to provide a default.rdp with the data of the connection settings. So I wrote a function to create and write this file from scratch on every start (see writeRDP() in tsc_dialog.cpp and rdp_file.h). As options, like “FullScreen” or “Fit to Screen” are also controlled by the rdp file, I was able to control these settings by code.

Conclusion

So far the tool works. Dont download if you dont like spaghetti. The code is written as grown.

Usage

Write the correct values for the connection to the registry

[HKEY_LOCAL_MACHINE\Software\RDP_autologin]
"FitToScreen"="1"
"FullScreen"="1"
"Status"="connecting..."
"Save Password"="1"
"Domain"=""
"Password"="xxxxxxxxxx"
"Username"="rdesktop"
"Computer"="192.168.0.130"

Then simply start the tool. First it will terminate a running instance of RDM. Then it starts a new instance and starts to fill the fields and do the connect.

Warranty

No warranty, code is provided as is. Hopefully it is usefull for the one or other.

Changes

Some values are hard coded, ie the control IDs used. These IDs may be different on other devices or within other RDM releases. So far the code works on my testing device. If you need to change the control IDs you may use the scanTscDialog() function to get the actual codes listed in the debug window.

Have fun!

Bookmark It

Unfortunately Remote Desktop Mobile (RDM) Client, if part of your Windows Mobile 6.1 device, will disconnect after 10 minutes of user idle time. This value seems to be hardcoded into the application. Various searches in internet lead to this assumption. So regardless of your server or client settings, RDM will disconnect after 10 minutes of user idle.

The following code is from this blog. For those of you not being able to compile the code I have attached an ArmV4i executable you can use directly on your device.

Here is the code:

// RDMkeepBusy.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include
#include 

int _tmain(int argc, _TCHAR* argv[])
{
    int const FIVEMINUTES = 1000*60*5; //1000 ms
    HWND hWndRDM = NULL;

	//First check if TSC is already running???

    //Firstly launch RDP Client
    SHELLEXECUTEINFO sei = {0};
    sei.cbSize = sizeof(sei);
    sei.nShow = SW_SHOWNORMAL;
    sei.lpFile = TEXT("\\Windows\\wpctsc.exe");
    sei.lpParameters = TEXT(" ");
    if (!ShellExecuteEx(&sei))
    {
        MessageBox(NULL, TEXT("Couldn't launch RDP Client"), TEXT("Remote Desktop Launcher"), MB_OK | MB_TOPMOST | MB_SETFOREGROUND);
        goto Exit;
    }
	else
		Sleep(500);

    //Now every X minutes check if it's still running and if so "refresh" its window
    //if it's no longer running, exit
    do
    {
        //check if RDP Client is running, otherwise exit
		DEBUGMSG(1, (L"FindWindow 'TSSHELLWND'...\n"));
        hWndRDM = FindWindow(_T("TSSHELLWND"), NULL);
        if (NULL != hWndRDM)
        {
            ////Get foreground window -- this is not needed if RDM is launched Full-Screen as it was in this case
            //hWndForeground = GetForegroundWindow();
            //Sleep(500);

            //Give focus to the RDP Client window (even if the logon screen, in case user logged out in the meantime)
			DEBUGMSG(1, (L"SetForGroundWindow\n"));
            SetForegroundWindow(hWndRDM);

            //The timer is reset when the rdp window receives mouse or keyboard input
            //with no MOUSEEVENTF_ABSOLUTE the move is relative

			DEBUGMSG(1, (L"MOUSEEVENTF_MOVE 1\n"));
            mouse_event(MOUSEEVENTF_MOVE, 100, 0, 0, 0);
            Sleep(250);
			DEBUGMSG(1, (L"MOUSEEVENTF_MOVE 2\n"));
            mouse_event(MOUSEEVENTF_MOVE, -100, 0, 0, 0);

            ////Give focus back to previous foreground window
            //SetForegroundWindow(hWndForeground);

            //Sleep
			DEBUGMSG(1, (L"Sleep ...\n"));
            Sleep(FIVEMINUTES);
        }
        else
        {
			DEBUGMSG(1, (L"FindWindow failed for 'TSSHELLWND'\n"));
            //RDP Client is not running - let's exit
            goto Exit;
        }
    }
    while (TRUE); //The check (NULL != hWndRDM) is already done inside the loop

Exit:
	DEBUGMSG(1, (L"Exit!\n"));
    if (NULL != hWndRDM)
        CloseHandle(hWndRDM);

    return 0;
}

The downloads:

DOWNLOAD:RDMkeepBusy VS2005 Source - (Hits: 451, size: 7.64 KB) DOWNLOAD:RDMkeepBusy ArmV4i Exe - (Hits: 756, size: 1.84 KB)

Bookmark It