Error C2664:
'GetIDFromPhone' : cannot convert parameter 2 from 'const
struct HLINE__ *' to 'const struct HPHONE__ *'
People who had downloaded the source code that accompanies
Chris's book Windows Telephony Programming from this website
prior to May 28, 2002 had experienced problems trying to
re-build the tMonitor application discussed in chapter 5 of
Chris's book.
The error reported was as follows:
\telprog\Chapter05\tMonitor\IncomingCallDlg.cpp(165) :
error C2664: 'GetIDFromPhone' : cannot convert parameter 2
from 'const struct HLINE__ *' to 'const struct HPHONE__ *'
To correctly fix this error you should change the function
call ctDevice.GetIDFromPhone() to ctDevice.GetIDFromLine()
using the same arguments. The code will then correctly rebuild
and run. This bug has been fixed in the new download, which
was updated on May 28, 2002.
Additional Information
Originally I did not catch this bug due to the build
environment I was working in. When I first took over the job
of hosting Chris's source code, I upgraded my system so that I
was compiling with the latest release of Microsoft's Core SDK
(Build 5.1.3590.2, Last Updated Nov. 2001) which contains
updates to TAPI. In order to correctly compile the source code
with these latest updates, I included under Directories Tab of
the Visual Studio->Tools->Options menu item, the include
and library paths for the newly installed Microsoft SDK files
before any other include or library paths. This environment
change allowed me to re-compile all of the sources without
error.
When I remove these two path statements from my Visual
Studio Directories environment, I too was able to see this
error. After examining this error more closely I realized that
this is due to an incorrect function call in the source file
IncommingCallDlg.cpp. Once again the compiler is correct in
the error it reports. The call to ctDevice.GetIDFromPhone()
needs a HPHONE for its second argument, but the code is trying
to pass a HLINE value. (i.e. ctCall->GetLine() == CtLine *,
and CtLine->GetHandle == HLINE).
The reason why I was able to rebuild the sources when
including the updated TAPI release files was due to a #define
statement in the new tapi.h header file of the Core SDK. In
this header there is a definition that reads:
#define DECLARE_OPAQUE32(name) typedef DWORD name
This statement through typedef statements, defines all
handles (HLINE, HPHONE, etc...) to be of the same type, i.e.
DWORD, which is why I did not originally catch the error. In
older versions of tapi.h this definition is defined as:
#define DECLARE_OPAQUE32(name) struct name##__ { int
unused; }; \ typedef const struct name##__ FAR* name
The reason for these types of errors is that the tMonitor
application needs to link with libraries built from the tfx
workspace, (i.e. \telprog\tfx). Before you will be able to build
the tMonitor application, you first need to rebuild the tfx
libraries.
If the tfx libraries are built in one build environment, i.e.
with latest TAPI updates from the Microsoft Core SDK, and the
tMonitor application is built in a different build environment,
i.e. using an earlier release of TAPI include and library files,
or vice-versa, you will see these types of errors. Both the TFX
and tMonitor sources must be compiled and linked with the same
TAPI environment files.
Although the greeting file that instructs the caller to leave
a voice message should always play properly for you, reports of
this greeting not being played or sounding garbled have been
seen by some users.
This type of error was fixed by updating the modem and/or
soundcard drivers. This type of problem has been seen mainly on
systems running Windows 2000 and Windows XP.
It has been reported that under Windows 2000 which uses the
Unimodem 5 TSP, that the tMonitor application does not working
correctly when in Take a Message mode.
Normally when calling into the tMonitor application, the user
can either click the button for "Take A Message", or
alternatively allow the application to receive 4 ring events. In
either case the phone line is answered, and playback of
greeting/wave_test.wav begins. After voice playback has
completed the application begins recording the callers message.
Under Windows 98, after recording a message, the caller can
press any DTMF key or hangup to stop the recording process. A
wave file is saved in the .\Messages directory relative
to where the executable is run. This directory is created if it
does not already exist.
Although you would think that the application should work the
same way under Windows 2000, there is a problem. While in the
process of recording, the DISCONNECT and MONITOR events are not
being seen by the application until after the default duration
of 120 seconds expires. These events are blocked for some reason
until after recording has timed out. I believe that the problem
is most likely due to differences in Unimodem 5 which comes
packaged with Windows 2000, and Unimodem V which is found on
Windows 98 machines. In my own testing with other examples I
have written I have found that there are slight differences
between Unimodem V and Unimodem 5. They are not the same
program.
