[ Team LiB ]

Chapter 7. Connection Manager
Operator! Give me the number for 911!

—Homer Simpson, The Simpsons

The last chapter described how to establish and interact with a connection to a remote server using the Remote Access Service (RAS). Although using the RAS APIs provides you with low-level functions to establish a connection with a server and get status information about it, a variety of aspects about that connection can change, depending on what type of network resource you are accessing. This is especially true on mobile devices such as Pocket PC, for which connectivity and authorization requirements can constantly shift depending on your current environment and what you are requesting.

Consider what happens when you try to access an HTTP resource that is located on the Internet. Whether you are dialed into your Internet service or on a wireless LAN at the local coffee shop, the device merely needs to establish a connection to the Internet to download the request. What happens, however, if you make the same request while you are at work and are connected to the corporate network, which is most likely under a firewall? Without having the user authentication information that is passed to the proxy server, the request will fail. Managing all of the various connection types that a user might have would be a nightmare for every individual application developer.

This is where the Pocket PC Connection Manager comes in—it is the best way to manage remote connections (see Figure 7.1).

Figure 7.1. Pocket PC Connection Manager

It is probably easiest to think of the Connection Manger as a centralized location that is used for the configuration of all possible network connections that the device can make. What this accomplishes is a simplified user experience—the user needs to configure what a “Work” connection is only once in order for all networking applications to use it. In addition, the Connection Manager can make some calculations about the cost, latency, and bandwidth required for the request, in an attempt to determine the best type of connection to make in order to get the network resource that you’ve requested.

If you are planning to develop any applications that require network communications, you will most likely want to have them use the Connection Manager to establish and schedule network connections. By doing so, all of the specific details—including dialing parameters, proxy information, VPN authentication, and so on—are handled for you, provided that the user has already configured his or her device. All you need to do is send a request to the Connection Manager to either establish or close a connection.

To use the Connection Manager API functions within your application, you need to include the headers connmgr.h and connmgr_proxy.h, and link with the cellcore.lib library.

[ Team LiB ]
[ Team LiB ]

Understanding the Connection Manager
You can configure two types of connection settings using the Connection Manager: Internet and Work. Both maintain connection parameters for the type of resource you are trying to access.

The Internet connection setting is used for a straightforward dial-up or network connection to the Internet when attempting to access an Internet-style dot-address (such as XX.XX.XX.XX or name.domain.com).

The Work connection setting offers a variety of connection options, including support for proxy servers, virtual private networks (VPNs), and ActiveSync synchronization. This option also supports the capability to address a WINS network address on a private LAN.

So, what does this mean for you as an application developer? Basically, depending on the type of resource you are requesting, the Connection Manager will choose which connection to use in order to get you access to the network resource. If you are attempting to get something with a fully qualified Internet URL, the Connection Manager will use the Internet setting; otherwise, it will choose Work. Figure 7.2 shows the Work setting configuration dialog box.

Figure 7.2. Pocket PC VPN settings

It is generally recommended that a user set all three of the Connection Manager’s configuration drop-down options (Internet, Work, and Network card) for the Work connection setting. By doing this, the device can easily connect to the Internet, use a VPN connection, synchronize with ActiveSync, and use local resources without having to reconfigure Connection Manager whenever the environment changes.

Preparing the Connection Manager
Before you can use the Connection Manager to manage your network communications, you must first make sure that it is available to be used. This is done by simply calling the ConnMgrApiReadyEvent() API, which is defined as follows:

HANDLE WINAPI ConnMgrApiReadyEvent();

The function takes no parameters, but returns a handle to an event that will become signaled when the Connection Manager is ready. Remember that you need to call the CloseHandle() function for the event that is returned.

Confirming that the Connection Manager is available is relatively straightforward:

// Make sure Connection Manager is ready
BOOL bAvailable = FALSE;
hConnMgr = ConnMgrApiReadyEvent();

return FALSE;

// Wait for 1 second to see if Connection Manager has
// signaled the event
DWORD dwResult = WaitForSingleObject(hConnMgr, 1000);

if(dwResult == WAIT_OBJECT_0)
bAvailable = TRUE;

// Close the event handle

// Did it connect ok?
return FALSE;

// Do something now that Connection Manager is ready

URLs and Network Identifiers
The next thing you need to do before you can make a network request is to determine the globally unique identifier (GUID) for the type of object you are requesting, based on its Uniform Resource Locator (URL). The GUID you are returned has been deemed the best network connection to use for the destination that you passed to the function, based on the connection cost, latency, and so on. You then use the identifier when you eventually establish your connection.

To determine the best network connection to use, you need to call the ConnMgrMapURL() function, which is defined as follows:

DWORD *pdwIndex);

The first parameter, pwszURL, is the location of the object you are requesting, and should be in standard Internet format (for example, http://www.furrygoat.com/index.html). You can also use the URL functions described in Chapter 2, such as InternetCreateUrl(), to correctly build a resource locator.

The next parameter, pguid, is a pointer that receives the GUID of the destination network. Finally, you have pdwIndex, which is an optional parameter that serves as a pointer to a DWORD index variable. The index is used if there were more than one network mapping for the destination resource. The first time you call the function, you should set the value of the index to 0. If there are additional mappings, then ConnMgrMapURL() will increment the index value, which should be passed into each additional call into ConnMgrMapURL().

The following example determines the best network connection to use for a particular URL:

// Map a local and remote URL
TCHAR tchLocalUrl[256] = TEXT(“”);
TCHAR tchRemoteUrl[256] = TEXT(“”);
HRESULT hResult = S_OK;

wsprintf(tchLocalUrl, TEXT(“http://fifi/report.txt”));
wsprintf(tchRemoteUrl, TEXT(“http://fifi.someserver.

// Map a local URL {a1182988-0d73-439e-87ad-2a5b369f808b}
GUID guidNetworkObject;
DWORD dwIndex = 0;

if(ConnMgrMapURL(tchLocalUrl, &guidNetworkObject, &dwIndex)
== E_FAIL) {
OutputDebugString(TEXT(“Could not map a local request to
a network identifier”));
return FALSE;

// Map a remote URL {436ef144-b4fb-4863-a041-8f905a62c572}
dwIndex = 0;
if(ConnMgrMapURL(tchRemoteUrl, &guidNetworkObject, &dwIndex)
== E_FAIL) {
OutputDebugString(TEXT(“Could not map a remote request to
a network identifier”));
return FALSE;

Enumerating Network Identifiers
If you want to get more information about a particular network identifier, or just enumerate the available identifiers that are on the device, you can use the ConnMgrEnumDestinations() function, which is defined as follows:

HRESULT WINAPI ConnMgrEnumDestinations(int nIndex,

The first parameter is the index value of the identifier for which you want to get more information. If you want to enumerate all of the available identifiers, this should be set to 0 the first time the function is called, and incremented for each additional time you call the function. The other parameter, pDestInfo, is a pointer to a CONNMGR_DESTINATION_INFO structure, which contains the network information for the index specified.

The function will return an S_OK value if it is successful; otherwise, you will be returned an E_FAIL value.

The CONNMGR_DESTINATION_INFO structure looks like the following:

GUID guid;


The structure contains only two pieces of information: the GUID that is associated with the network connection, and a null-terminated string containing the description of the network.

To enumerate all of the available network identifiers, you could do the following:

// Enumerate the available network identifiers
DWORD dwEnumIndex = 0;
BOOL fLoop = TRUE;
TCHAR tchNetNameInfo[256] = TEXT(“”);

// Walk through the list of Networks
memset(&networkDestInfo, 0,

if(ConnMgrEnumDestinations(dwEnumIndex, &networkDestInfo)
== E_FAIL) {
fLoop = FALSE;

// If we got a network ID’s information, show the
// description
wsprintf(tchNetNameInfo, TEXT(“Network Name:%s”),
MessageBox(NULL, tchNetNameInfo, TEXT(“Available
} while(fLoop);

[ Team LiB ]
[ Team LiB ]

Establishing and Maintaining Connections
Now that you have the proper network identifier to use for the network location from which you are requesting a resource, you can go ahead and tell Connection Manager to make the connection.

The Connection Manager API currently supports two different functions for establishing a connection to the network:

Synchronous Mode: To create a connection request that will not return until the connection either is established or returns an error, you can use the ConnMgrEstablishConnectionSync() function.

Asynchronous Mode: To create a connection request that returns immediately, you can use the ConnMgrEstablishConnection() function. You need to poll the request handle that you are returned in order to find out the current status of the connection.

Regardless of which method you use to establish your network connection, you need to properly fill out a CONNMGR_CONNECTIONINFO structure, which contains the parameters that describe the request. The structure is defined as follows:

DWORD cbSize;
DWORD dwParams;
DWORD dwFlags;
DWORD dwPriority;
BOOL bExclusive;
BOOL bDisabled;
GUID guidDestNet;
HWND hWnd;
UINT uMsg;
LPARAM lParam;
ULONG ulMaxCost;
ULONG ulMinRcvBw;
ULONG ulMaxConnLatency;

The cbSize member should be set to the size of the CONNMGR_CONNECTIONINFO structure.

The dwParams member contains a list of optional member fields that are set in the structure, and can be a combination of the values shown in Table 7.1.

The dwFlags member defines the list of flags that specify any special properties for establishing the network connection. If no flags are set, the Connection Manager will use a direct IP connection. The dwFlags member should be set to one of the values shown in Table 7.2.


guidDestNet field is valid

ulMaxCost field is valid

ulMinRcvBw field is valid

ulMaxConnLatency field is valid

Table 7.2. Connection Manager Proxy Flags Value

HTTP Proxy supported

WAP gateway proxy supported

SOCKS4 proxy supported

SOCKS5 proxy supported

The dwPriority member specifies the priority level of the connection you are requesting. Remember that the Connection Manager needs to delegate various simultaneous network requests among multiple applications. It gives precedence to those that specify a higher priority value. Table 7.3 describes the priority levels that can be used.

The bExclusive member specifies whether the connection can be shared among multiple applications. If you set this value to FALSE, then other programs will be notified when the connection is available. If you set it to TRUE, then you place the connection in a state in which it cannot be shared. Other applications that request to establish a similar connection will fight for the same resource, with the outcome depending on each connection request’s priority.

The bDisabled member prevents the connection request from actually establishing a remote connection if set to TRUE. This can be used to test the availability of a network connection.

The guidDestNet member should contain the GUID for the network identifier that will be used to connect to the network. This is the same identifier returned using the ConnMgrMapURL() or ConnMgrEnumDestinations() functions. A remote connection cannot be established without this identifier.

Table 7.3. Connection Manager Priority Levels Value

Voice connection.

A user has made this request, and is awaiting the creation of the connection.

Use this priority for user-interactive applications.

The application has become idle. You should switch to this priority when the application is not active.

A user-initiated request has been idle for a length of time. Switching between this and CONNMGR_PRIORITY_USERINTERACTIVE enables the Connection Manager to optimize shared connections.

High-priority background.

Idle background task.

A network request has been made from an external application.

A connection is established only if a higher-priority client is already using the connection.

Internal caching is being used; no external connection is needed.

To have the Connection Manager send any changes in the connection status to a window handle, you can use the next three members to set that up. The hWnd member is the window handle that you want to receive messages, uMsg should contain the WM_USER message ID that you want to have sent with the status change, and lParam is a DWORD value that will be placed in the lParam parameter of your message. You can set all three of these members to zero if you don’t want the Connection Manager to post any messages to your window.

The ulMaxCost member should specify the maximum cost of the connection.

The ulMinRcvBw member specifies the minimum amount of bandwidth that you need in order to accept the connection.

Finally, the ulMaxConnLatency member should specify the maximum acceptable connection latency, in milliseconds, before a connection fails. An acceptable value for the maximum latency would be around 4 seconds, or 4,000 milliseconds.

Establishing Connections
To create a synchronous connection, you can call the following function:

HRESULT WINAPI ConnMgrEstablishConnectionSync(
DWORD dwTimeout, DWORD *pdwStatus);

The pConnInfo parameter should point to a CONNMGR_CONNECTIONINFO structure that contains the instructions for establishing the connection. This is followed by phConnection, a pointer to the connection handle that you are returned from the function. The dwTimeout parameter should be used to set a timeout value, in milliseconds, which the function will return if a connection cannot be established. Finally, the pdwStatus parameter will point to the final status of the connection.

Don’t forget that you need to call the ConnMgrReleaseConnection() function once you are finished using the connection in order to properly free the connection handle.

The following code establishes a synchronous connection:

// Establish a synchronous connection
HANDLE hConnection = NULL;
DWORD dwStatus = 0;
DWORD dwTimeout = 5000;

// Get the network information where we want to establish a
// connection
TCHAR tchRemoteUrl[256] = TEXT(“”);
GUID guidNetworkObject;
DWORD dwIndex = 0;

if(ConnMgrMapURL(tchRemoteUrl, &guidNetworkObject, &dwIndex)
== E_FAIL) {
OutputDebugString(TEXT(“Could not map the request to a
network identifier”));
return FALSE;

// Now that we’ve got the network address, set up the
// connection structure

memset(&ccInfo, 0, sizeof(CONNMGR_CONNECTIONINFO));
ccInfo.cbSize = sizeof(CONNMGR_CONNECTIONINFO);
ccInfo.guidDestNet = guidNetworkObject;

// Make the connection request (timeout in 5 seconds)
if(ConnMgrEstablishConnectionSync(&ccInfo, &hConnection,
dwTimeout, &dwStatus) == E_FAIL) {
return FALSE;

// Connection has been made, continue on…

Creating an asynchronous connection is a bit more involved. To make the connection request, you can use the ConnMgrEstablishConnection() function, which is defined as follows:

HRESULT WINAPI ConnMgrEstablishConnection(

The first parameter, pConnInfo, is a pointer to a CONNMGR_CONNECTIONINFO structure that describes the connection. When the function returns, phConnection will point to a connection handle for the request.

When you are finished using the connection, you must properly free the handle by calling the ConnMgrReleaseConnection() function, as described in the section “Disconnecting from an Active Connection,” later in this chapter.

The following code polls the request handle for status changes:

// Establish an asynchronous connection
HANDLE hConnection = NULL;
DWORD dwStatus = 0;

// Get the network information where we want to establish a
// connection
TCHAR tchRemoteUrl[256] = TEXT(“”);
wsprintf(tchRemoteUrl, TEXT(“http://www.furrygoat.com/index.html”));
GUID guidNetworkObject;
DWORD dwIndex = 0;

if(ConnMgrMapURL(tchRemoteUrl, &guidNetworkObject, &dwIndex)
== E_FAIL) {
OutputDebugString(TEXT(“Could not map the request to a
network identifier”));
return FALSE;

// Now that we’ve got the network address, set up the
// connection structure

memset(&ccInfo, 0, sizeof(CONNMGR_CONNECTIONINFO));
ccInfo.cbSize = sizeof(CONNMGR_CONNECTIONINFO);
ccInfo.guidDestNet = guidNetworkObject;

// Make the connection request
if(ConnMgrEstablishConnection(&ccInfo, &hConnection) ==
return FALSE;

// Poll to see if the connection has been established
BOOL fLoop = TRUE;
BOOL fConnected = FALSE;

while(fLoop) {
dwStatus = 0;
&dwStatus))) {
// Do some error processing here
fLoop = FALSE;

// Got the status, do something with it:
fLoop = FALSE;
fConnected = TRUE;

OutputDebugString(TEXT(“Establishing a

OutputDebugString(TEXT(“Disconnected from the
fLoop = FALSE;

// Release the handle gracefully
if(!fConnected && hConnection) {
if(ConnMgrReleaseConnection(hConnection, FALSE) == S_OK)
hConnection = NULL;
return FALSE;

// Connection has been made, continue on…

Getting the Connection Status
To get the status of a Connection Manager connection, you can use the ConnMgrConnectionStatus() function:

HRESULT WINAPI ConnMgrConnectionStatus(HANDLE hConnection,
DWORD *pdwStatus);

The function needs only the handle to a current connection, and will return the status code for it in the pointer specified by the pdwStatus parameter.

Table 7.4 shows the possible status values that the Connection Manager can return.

Table 7.4. Connection Manager Status Values Value




Connection has failed and cannot be reestablished.

User-aborted connection.

Connection is ready to connect but disabled.

No path could be found to the destination.

Waiting for a path to the destination.

Voice call is in progress.

Attempting to connect.

Resource is in use by another connection.

No path to the destination could be found.

Connection is being brought down.

Aborting connection attempt.

Connection Priorities
One of the Connection Manager’s most useful features is its ability to juggle multiple requests, i.e., from more than one application at the same time. When making a connection request for your application, you are required to set its priority level (the dwPriority member of the CONNMGR_CONNECTIONINFO structure). This enables the Connection Manager to effectively schedule the order in which each request is processed—connection requests that have a higher priority are handled before those with a lower one.

Once a connection has been established, you can manually change its priority at any time by calling the ConnMgrSetConnectionPriority() function:

HRESULT WINAPI ConnMgrSetConnectionPriority(HANDLE
hConnection, DWORD dwPriority);

The first parameter is the request handle you were returned from either the ConnMgrEstablishConnection() or ConnMgrEstablishConnectionSync() function. This is followed by the new priority level you want to set for the request. The list of possible values is the same as the list for the dwPriority member of the CONNMGR_CONNECTIONINFO structure.

A well-behaved application will change its connection priority based on what the user is currently doing on the device. For example, if an application is downloading a Web page, you would want to set the connection to a high-priority level such as CONNMGR_PRIORITY_USERINTERACTIVE. This provides users with a better experience, because they expect an immediate response and high-priority requests are favored by the Connection Manager. However, if a user switches to a different application or is idle for an extended period of time, you will want to switch the level to CONNMGR_PRIORITY_USER_IDLE. A lower priority level enables other processes to more effectively share the connection.

The following code sample shows how to manually change the priority for a connection:

OutputDebugString(TEXT(“Could not change connection
return FALSE;

Disconnecting from an Active Connection
To close a connection request, you can simply call the following function:

HRESULT WINAPI ConnMgrReleaseConnection(HANDLE hConnection,
BOOL bCache);

The hConnection parameter should be set to the current connection you want to release. If this is the last request handle that the Connection Manager has for the network type with which you are connected, it will drop the connection; otherwise, it will be left open for any other active requests. The bCache parameter should be set to TRUE if you want the Connection Manager to remember the connection in its cache; otherwise, you should set this to FALSE.

[ Team LiB ]
[ Team LiB ]

Connection Service Providers and Proxies
The Connection Manager uses what is known as a Connection Service Provider (CSP) to talk over a particular network. Each individual provider is a COM object that encapsulates the specifics for an individual network’s communications. For example, there are currently CSPs for networking, proxy servers, VPNs, and GRPS connections—each providing specific instructions about how to talk over a network. When you request a network connection, the Connection Manager will determine which CSP to use based on the cost, latency, and bandwidth for the resource you are trying to access.

To exchange information with a CSP object, you can use the ConnMgrProviderMessage() API function:

HRESULT WINAPI ConnMgrProviderMessage(HANDLE hConnection,
const GUID *pguidProvider, DWORD *pdwIndex, DWORD dwMsg1,
DWORD dwMsg2, PBYTE pParams, ULONG cbParamSize);

The hConnection parameter is optional but can be set to a particular request handle if one is active. The next parameter, pguidProvider, should point to the GUID of the CSP to which you want to send a message. If multiple network providers are being used by a single connection, then you can set the pdwIndex pointer to the index of the specific provider to which the message should be sent. Both dwMsg1 and dwMsg2 are optional and have different meanings depending on the provider and message being sent. The pParams parameter should point to a data structure specific to the provider you are talking with, and is followed by cbParamSize, which should point to the size of the structure.

By this point, you are probably asking yourself why communicating with the provider interfaces is useful. One of the most common uses for sending a connection service provider a message is to obtain the proxy server configuration options for a particular communications request.

You can get proxy configuration information by passing a PROXY_CONFIG structure to the network provider defined by IID_ConnPrv_IProxyExtension. After the ConnMgrProviderMessage() function is called, the structure will be filled in with the requested information for the proxy type. The PROXY_CONFIG structure is defined as follows:

typedef struct _PROXY_CONFIG {
DWORD dwType;
DWORD dwEnable;

The dwType member specifies the type of proxy server to use. It can be set to the following: CONNMGR_FLAG_PROXY_HTTP (for standard HTTP proxies), CONNMGR_FLAG_PROXY_WAP (for a WAP gateway), CONNMGR_FLAG_PROXY_SOCKS4 (for a SOCKS 4.0 server), or CONNMGR_FLAG_PROXY_SOCKS5 (for a SOCKS 5.0 server). This member should be set before calling the function.

The dwEnable member specifies whether the CSP should have the capability to connect to the specified proxy server. The CSP automatically sets this to 1, which enables the proxy server. If you set it to 0, then although the proxy configuration will exist, the CSP will not connect to the server.

The szProxyServer member specifies the server and port of the proxy. The correct syntax for setting this should be a null-terminated string that contains the server name, a colon, and the port number (for example, server:port).

The szUsername and szPassword members specify the authorization to be used when communicating with a SOCKS4 or SOCKS5 proxy server.

The szProxyOverride and szExtraInfo members are not currently used.

The following example shows how you could obtain the proxy information for a standard HTTP request:

// Get information on the proxy for an HTTP connection
// request
PROXY_CONFIG proxyConfig;
DWORD dwSize = sizeof(PROXY_CONFIG);
HRESULT hr = 0;
GUID IID_ConnPrv_IProxyExtension = {0xaf96b0bd, 0xa481,
0x482c, {0xa0, 0x94, 0xa8, 0x44, 0x87, 0x67, 0xa0, 0xc0}};

memset(&proxyConfig, 0, sizeof(PROXY_CONFIG));
proxyConfig.dwType = CONNMGR_FLAG_PROXY_HTTP;

hr = ConnMgrProviderMessage(NULL, &IID_ConnPrv_IProxyExtension,
NULL, 0, 0,
(PBYTE)&proxyConfig, dwSize);

if(FAILED(hr)) {
OutputDebugString(TEXT(“Could not get the proxy
return FALSE;

[ Team LiB ]
[ Team LiB ]

Scheduled Connections
The Connection Manager also enables you to configure an event (at a specific time) that will cause the device to wake up (if not already on), establish a connection to a network, and run an application. This can be particularly useful if you want a network operation to do something when the user is not around his or her device. Note that a scheduled event will remain registered until it has run or is deleted. In addition, an event remains scheduled across device reboots.

To set up a scheduled connection, you can use the ConnMgrRegisterScheduledConnection() function, which is defined as follows:

HRESULT WINAPI ConnMgrRegisterScheduledConnection(

The only parameter that is needed is a pointer to a SCHEDULEDCONNECTIONINFO structure:

GUID guidDest;
UINT64 uiStartTime;
UINT64 uiEndTime;
UINT64 uiPeriod;
TCHAR szToken[32];
BOOL bPiggyback;

The guidDest member specifies the network identifier with which you want to create a connection. The next two members are used to set the start and end times for the connection. These should be set in the same format as the FILETIME structure, which specifies the amount of 100-nanosecond intervals since January 1, 1601.

The uiPeriod member is the amount of time (in 100-nanosecond units) between each connection attempt. If you set this to 0, the device will not wake up to make your connection.

The szAppName and szCmdLine members should point to the name of the application to run when the connection is made, and the command line that you want passed to the application, respectively.

The szToken member is a unique identifier that you can use to later delete the connection request.

Finally, the bPiggypack flag determines how the device should wake up for the event. If bPiggyback is set to TRUE, then the application specified by the szAppName parameter will execute as soon as the network connection to guidDest has been established. If it is set to FALSE, then the device will wake up only when another application or scheduled event connects to the same network.

The following code shows how you could schedule an application to run, 15 seconds from now. The scheduler will continue to attempt a connection every five minutes for the next hour:

// Get the network information where we want to establish a
// connection
GUID guidNetworkObject;
DWORD dwIndex = 0;
TCHAR tchRemoteUrl[256] = TEXT(“”);
wsprintf(tchRemoteUrl, TEXT(“http://www.furrygoat.com/index.html”));

if(ConnMgrMapURL(tchRemoteUrl, &guidNetworkObject, &dwIndex)
== E_FAIL) {
OutputDebugString(TEXT(“Could not map the request to a
network identifier”));
return FALSE;

// Get the time to launch
FILETIME ftCurrent;

SystemTimeToFileTime(&sysTime, &ftCurrent);

ulCurrentTime.LowPart = ftCurrent.dwLowDateTime;
ulCurrentTime.HighPart = ftCurrent.dwHighDateTime;

// Set up the schedule times
// In 15 seconds, let’s try every 5 minutes for an hour
DWORD dwSecStart = 15;
DWORD dwSecDuration = 3600;
DWORD dwSecPeriod = 300;

// Schedule a connection

memset(&sci, 0, sizeof(SCHEDULEDCONNECTIONINFO));
sci.uiStartTime =
sci.uiEndTime = ulCurrentTime.QuadPart+(UINT64)(10*1000*1000)*
sci.uiPeriod = (UINT64)(10*1000*1000)*(dwSecPeriod);
sci.guidDest = guidNetworkObject;
sci.bPiggyback = TRUE;

wsprintf(sci.szAppName, TEXT(“\\Windows\\someapp.exe”));
wsprintf(sci.szCmdLine, TEXT(“\\Windows\\someapp.exe”));
wsprintf(sci.szToken, TEXT(“schdToken”));

HRESULT hr = ConnMgrRegisterScheduledConnection(&sci);

if(FAILED(hr)) {
OutputDebugString(TEXT(“Could not schedule the connection
return FALSE;

To delete a scheduled connection, you can call the following function:

HRESULT WINAPI ConnMgrUnregisterScheduledConnection(LPCTSTR

The only parameter that you need to send is the unique token that identifies the scheduled connection, as shown in the following example:

(“schdToken”)))) {
OutputDebugString(TEXT(“Scheduled event has been

[ Team LiB ]


0 Responses to “Animasi”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Tanggalan Hijriah


November 2009


Beranda Top

Yahoo Mesangger


kimyong seo

%d bloggers like this: