Share via


lineInitializeEx

A version of this page is also available for

Windows Embedded CE 6.0 R3

4/8/2010

This function initializes the application's use of TAPI for subsequent use of the line abstraction. It registers the application's specified notification mechanism and returns the number of line devices available to the application. A line device is any device that provides an implementation for the line-prefixed functions in the Telephony API.

Syntax

LONG WINAPI lineInitializeEx(
  LPHLINEAPP lphLineApp,
  HINSTANCE hInstance,
  LINECALLBACK lpfnCallback,
  LPCWSTR lpszFriendlyAppName,
  LPDWORD lpdwNumDevs,
  LPDWORD lpdwAPIVersion,
  LPLINEINITIALIZEEXPARAMS lpLineInitializeExParams
);

Parameters

  • lphLineApp
    Pointer to a location that is filled with the application's usage handle for TAPI.
  • hInstance
    Instance handle of the client application or DLL. The application or DLL can pass NULL for this parameter, in which case TAPI uses the module handle of the root executable of the process (for purposes of identifying call handoff targets and media mode priorities).
  • lpfnCallback
    Address of a callback function that is invoked to determine status and events on the line device, addresses, or calls, when the application is using the hidden window method of event notification (for more information see lineCallbackFunc). This parameter is ignored and should be set to NULL when the application chooses to use the event handle event notification mechanism.
  • lpszFriendlyAppName
    Pointer to a null-terminated text string that contains only displayable characters. If this parameter is not NULL, it contains an application-supplied name for the application. This name is provided in the LINECALLINFO structure to indicate, in a user-friendly way, which application originated, or originally accepted or answered the call. This information can be useful for call-logging purposes. If lpszFriendlyAppName is NULL, the application's module file name is used instead (as returned by the Windows API GetModuleFileName).
  • lpdwNumDevs
    Pointer to a DWORD-sized location. Upon successful completion of this request, this location is filled with the number of line devices available to the application.
  • lpdwAPIVersion
    Pointer to a DWORD-sized location. The application must initialize this DWORD, before calling this function, to the highest API version it is designed to support (for example, the same value it would pass into the dwAPIHighVersion parameter of the lineNegotiateAPIVersion function). Artificially high values must not be used; the value must be accurately set. TAPI translates any newer messages or structures into values or formats supported by the application's version. Upon successful completion of this request, this location is filled with the highest API version supported by TAPI, thereby allowing the application to detect and adapt to having been installed on a system with a different version of TAPI.
  • lpLineInitializeExParams
    Pointer to a structure of type LINEINITIALIZEEXPARAMS containing additional parameters used to establish the association between the application and TAPI (specifically, the application's selected event notification mechanism and associated parameters).

Return Value

Zero indicates success. A negative error number indicates that an error occurred. The following table shows the return values for this function.

Value Description

LINEERR_INVALAPPNAME

Invalid application name

LINEERR_OPERATIONFAILED

The operation failed

LINEERR_INIFILECORRUPT

The INI file is corrupted

LINEERR_INVALPOINTER

Invalid pointer

LINEERR_REINIT

The application attempted to initialize TAPI twice.

LINEERR_NOMEM

No memory available

LINEERR_INVALPARAM

Invalid parameter

Remarks

Applications must select one of two mechanisms by which TAPI notifies the application of telephony events: Hidden Window or Event Handle.

The Hidden Window mechanism is selected by specifying LINEINITIALIZEEXOPTION_USEHIDDENWINDOW in the dwOptions member in the LINEINITIALIZEEXPARAMS structure. In this mechanism (which is the only mechanism available to TAPI 1.x applications), TAPI creates a window in the context of the application during the lineInitializeEx or lineInitialize (for TAPI 1.3 and 1.4 applications) function, and subclasses the window so that all messages posted to it are handled by a WNDPROC in TAPI itself. When TAPI has a message to deliver to the application, TAPI posts a message to the hidden window. When the message is received (which can happen only when the application calls the Windows GetMessage function), Windows switches the process context to that of the application and invokes the WNDPROC in TAPI. TAPI then delivers the message to the application by calling the lineCallbackFunc, a pointer to which the application provided as a parameter in its call to lineInitializeEx (or lineInitialize). This mechanism requires the application to have a message queue (which is not desirable for service processes) and to service that queue regularly to avoid delaying processing of telephony events. The hidden window is destroyed by TAPI during the lineShutdown function.

The Event Handle mechanism is selected by specifying LINEINITIALIZEEXOPTION_USEEVENT in the dwOptions member in the LINEINITIALIZEEXPARAMS structure. In this mechanism, TAPI creates an event object on behalf of the application, and returns a handle to the object in the hEvent member in LINEINITIALIZEEXPARAMS. The application must not manipulate this event in any manner (for example, must not call the SetEvent, ResetEvent, and CloseHandle functions) or undefined behavior results; the application can only wait on this event using functions such as WaitForSingleObject or MsgWaitForMultipleObjects. TAPI signals this event whenever a telephony event notification is pending for the application; the application must call the lineGetMessage function to fetch the contents of the message. The event is reset by TAPI when no events are pending. The event handle is closed and the event object destroyed by TAPI during the lineShutdown function. The application is not required to wait on the event handle that is created; the application could choose instead to call lineGetMessage and have it block waiting for a message to be queued.

If the LINEERR_INVALPARAM error value is returned, the specified hInstance parameter is invalid.

The application can refer to individual line devices by using line device identifiers that range from zero to dwNumDevs minus one. An application should not assume that these line devices are capable of any particular TAPI function without first querying their device capabilities using the lineGetDevCaps function.

Requirements

Header tapi.h
Library coredll.lib
Windows Embedded CE Windows CE 3.0 and later
Windows Mobile Windows Mobile Version 5.0 and later

See Also

Reference

lineCallbackFunc
lineCallbackFunc
lineGetDevCaps
lineGetMessage
lineInitialize
lineNegotiateAPIVersion
lineShutdown
LINECALLINFO
LINEINITIALIZEEXPARAMS
LINEMESSAGE

Other Resources

CloseHandle
GetMessage
GetModuleFileName
MsgWaitForMultipleObjects
ResetEvent
SetEvent
WaitForSingleObject