|
Think I've got the answer - dereference the vector... (char*) &Z
|
|
|
|
|
John Oliver wrote:
Think I've got the answer - dereference the vector... (char*) &Z
That will be wrong.
You have to dereference the first element like &Z[0].
..this is a VB Programmers' world and we all are just visitors - Someone in a MSJ article
|
|
|
|
|
If v is the name of the vector, then &v[0] points to the underlying buffer.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
what's the difference between a vector and a one-dimensional array in C++? as far as i know, nothing.
so, this is an equivalence class:
&V[0]
&(*(V+0))
&(*(V))
V
therefore, you can use V if you want.
|
|
|
|
|
The difference is that an array is a wrapper around the data, therefore, the correct answer remains &v[0];. A vector of int's is a block of ints, the first one being at &v[0];. v has nothing to do with int's or memory, it is an instance of the vector class.
In fact, if you want a pointer to an element, you must dereference an iterator, then ask for the address, exactly as you have put it: &(*(V)). VC6 wrongly will accept the iterator as a pointer, VC7 corrects this.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
|
|
|
|
|
I am writing an application using TAPI 2.0 on Win NT4 (the other end will be Win98) to answer calls. So far I haven't made much progress 
TAPI is initialised okay and a line opened successfully. I then call lineSetStatusMessages as follows:
DWORD dwLineStates = LINEDEVSTATE_CLOSE |
LINEDEVSTATE_CONNECTED | LINEDEVSTATE_DISCONNECTED |
LINEDEVSTATE_RINGING;
lRes = lineSetStatusMessages(m_hLine, dwLineStates, 0);
In my TAPI event handling thread I have the following code to handle the events of interest:
LINEMESSAGE lineMess;
long lRes = lineGetMessage(g_hLineApp, &lineMess, 0);
if(lRes < 0)
{
TRACE1(_T("lineGetMessage failed returning 0x%X\n"), lRes);
}
else
{
TRACE1(_T("Call Handle: 0x%X\t"), lineMess.hDevice);
TRACE3(_T("dwMessageID: %d\tdwParam1: 0x%X\tdwParam2: 0x%X\n"),
lineMess.dwMessageID, lineMess.dwParam1, lineMess.dwParam2);
switch(lineMess.dwMessageID)
{
case LINE_CALLSTATE :
switch(lineMess.dwParam1)
{
case LINECALLSTATE_OFFERING :
{
lRes = lineAnswer(g_hCall, NULL, 0);
TRACE1(_T("lineAnswer returned 0x%X\n"), lRes);
}
break;
case LINECALLSTATE_DISCONNECTED :
{
lRes = lineDrop(g_hCall, NULL, 0);
TRACE1(_T("lineDrop returned 0x%X\n"), lRes);
}
break;
}
break;
}
}
This produces the following trace output:
Call Handle: 0x982AE8 dwMessageID: 23 dwParam1: 0x0 dwParam2: 0x982BC0
Call Handle: 0x982BC0 dwMessageID: 2 dwParam1: 0x2 dwParam2: 0x0
lineAnswer returned 0x1
Call Handle: 0x982AE8 dwMessageID: 8 dwParam1: 0x2 dwParam2: 0x1
Call Handle: 0x0 dwMessageID: 12 dwParam1: 0x1 dwParam2: 0x0
Call Handle: 0x982BC0 dwMessageID: 2 dwParam1: 0x4 dwParam2: 0x0
Call Handle: 0x982BC0 dwMessageID: 2 dwParam1: 0x4000 dwParam2: 0x800
lineDrop returned 0x2
lineDeallocateCall returned 0x0
Call Handle: 0x982BC0 dwMessageID: 2 dwParam1: 0x1 dwParam2: 0x0
Call Handle: 0x0 dwMessageID: 12 dwParam1: 0x2 dwParam2: 0x0
Call Handle: 0x982AE8 dwMessageID: 3 dwParam1: 0x0 dwParam2: 0x0
which can be interpreted as:
dwMessageID: LINE_APPNEWCALL
dwMessageID: LINE_CALLSTATE dwParam1: LINECALLSTATE_OFFERING
lineAnswer returned 0x1
dwMessageID: LINE_LINEDEVSTATE dwParam1: LINEDEVSTATE_RINGING
dwMessageID: LINE_REPLY dwParam1: 0x1 (Request ID)
dwMessageID: LINE_CALLSTATE dwParam1: LINECALLSTATE_ACCEPTED
dwMessageID: LINE_CALLSTATE dwParam1: LINECALLSTATE_DISCONNECTED dwParam2: LINEDISCONNECTED_UNAVAIL
lineDrop returned 0x2
lineDeallocateCall returned 0x0
dwMessageID: LINE_CALLSTATE dwParam1: LINECALLSTATE_IDLE
dwMessageID: LINE_REPLY dwParam1: 0x2 (Request ID)
dwMessageID: LINE_CLOSE
As you can see. When a call is received it is answered successfully, but then the LINE_CALLSTATE changes to LINECALLSTATE_DISCONNECTED straight away. The reason code is UNAVAIL, which means it doesn't know and never will
The call is being initiated on a Win98 PC using Hyperterminal. The really frustrating part is that the initiating modem thinks it is connected. Issuing the command AT+CPAS gives a return code of 4, which means Call in Progress!
Even more frustratingly, if a carry out a call from Hyperterminal to Hyperterminal across the 2 PCs it works without problem 
Any ideas where I'm going wrong? Why does it think the line has been disconnected when it hasn't?
Derek Lakin.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
Are you able to establish a Dial-up connection with that modem? If not, this might shed some light on where your problem lies.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
They are actually GSM modems connected to the serial port and using the Standard Windows 9600 modem driver (if that makes a difference).
I haven't tried making a dialup connection, but they talk ok using Hyperterminal. I can even transfer a file from one to the other using Hyperterminal.
Derek Lakin.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
I always thought that when you recieved a LINECALLSTATE_OFFERING message, you needed to do the lineAccept and not lineAnswer.
What parameters are you sending to lineOpen ?
Is it using the standard UNIMODEM TSP?
Can I recommend the following samples at http://www.julmar.com/samples.htm
TCMON and PHONE are good for debugging TAPI issues.
Michael 
"Eureka" is Greek for "This bath is too hot"
|
|
|
|
|
Michael P Butler wrote:
I always thought that when you recieved a LINECALLSTATE_OFFERING message, you needed to do the lineAccept and not lineAnswer.
Don't no. I'll try it, though.
Michael P Butler wrote:
What parameters are you sending to lineOpen ?
My lineOpen call is as follows:
lineOpen(g_hLineApp, m_dwDeviceID, &m_hLine,
dwAPIVersion, 0, 1, LINECALLPRIVILEGE_OWNER,
LINEMEDIAMODE_DATAMODEM, NULL);
Michael P Butler wrote:
Is it using the standard UNIMODEM TSP?
Huh??!! I have no idea Is that TAPISRV.EXE (or is it TAPISRV32.EXE? I can't remember now)
Michael P Butler wrote:
Can I recommend the following samples at http://www.julmar.com/samples.htm
Yes you can. Thanks very much 
Derek Lakin.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
Michael P Butler wrote:
I always thought that when you recieved a LINECALLSTATE_OFFERING message, you needed to do the lineAccept and not lineAnswer.
I've tried that now. It accepts the call (as the name suggests), but it does not complete the connection. It continues to ring (LINE_LINEDEVSTATE messages are continually received with Param1 = LINEDEVSTATE_RINGING).
Derek Lakin.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
You need to call lineAnswer when you receive the LINEDEVSTATE_RINGING. This should answer the call and give you a LINECALLSTATE_CONNECTED. (At least in theory - TAPI and modems is a trial and error kind of thing)
Michael
"Eureka" is Greek for "This bath is too hot"
|
|
|
|
|
Presumably I need to pick up the call handle when I get the LINECALLSTATE_OFFERING to use when I get the LINEDEVSTATE_RINGING (becuase hDevice for LINE_DEVSTATE is the device handle not the call handle.
The problem has not so much been answering the call, but that having answered it (using lineAnswer) I get LINECALLSTATE_DISCONNECTED straight away.
Thanks anyway, I'll give it a go.
Derek Lakin.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
I tried that, but it didn't work
I handled the _OFFERING event to get the call handle and then called lineAnswer in response to the _RINGING event, but it still got the _DISCONNECTED event straight away.
I have tried the PHONE app you suggested on the two PCs and it does actually behave the same way! I'm beginning to suspect it's something to do with the modem configuration, but I've been through the manual with a fine toothcomb and can't find anythign useful 
Derek Lakin.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
It's been a few years since I did any TAPI work with modems, I mainly use phone systems now.
Seeing as the PHONE app didn't work, then it is possibly the modem setup, or maybe the TAPI configuration. On the julmar web site there is a sample called EnumTAPI. What does it report for your modem? It should be under unimodem.tsp.
Is the NT4 system up-to-date with service packs? There used to be lots of issues with NT4 and TAPI.
Try changing your lineOpen command to this.
<br />
lineOpen(g_hLineApp, m_dwDeviceID, &m_hLine, dwAPIVersion, 0, 1, LINECALLPRIVILEGE_OWNER|LINECALLPRIVILEGE_MONITOR, LINEMEDIAMODE_DATAMODEM, NULL);<br />
You could also try calling lineGetDevCaps first and get the dwMediaModes value and use that in place of LINEMEDIAMODE_DATAMODEM.
Are you getting any LINE_REPLY messages, are they reporting any errors.
Another source of help maybe, http://www.sellsbrothers.com/writing/telprog/. There are some good links here.
Michael
"Eureka" is Greek for "This bath is too hot"
|
|
|
|
|
Michael P Butler wrote:
What does it report for your modem? It should be under unimodem.tsp.
Negotiated Version: 2.0
Provider Info: Windows Telephony Service Provider for Universal Modem Driver
Switch Info: Switch information unavailable
PermanentLineID = 0x25A06
Bearer Modes: (0x41) Voice Passthrough
Max Data Rate: 9600
Media Modes: (0x14) InteractiveVoice DataModem
Supports: "tapi/line", "comm", "comm/datamodem", "comm/datamodem/portname", "ndis"
Line Features (0x8) MakeCall
Available Line Features (0x8) MakeCall
Address Type: Private
Address Capability Flags (0x20)
Destination addresses may be dialed on this address.
Max number of active calls: 1
Max number of held calls: 0
Max number of conferenced calls: 0
Address Features: (0x2) MakeCall
Call Features: (0x2000c5) Accept Answer Dial Drop SetCallParams
Number of stations using address: 0
Number of active calls: 0
Number of held calls: 0
Available Address Features: (0x2) MakeCall
Service Providers:
0x2 unimdm.tsp
0x1 kmddsp.tsp
I don't know what it all means, but hopefully you do
Michael P Butler wrote:
Is the NT4 system up-to-date with service packs?
Yes. SP6A
Michael P Butler wrote:
Try changing your lineOpen command to this.
lineOpen(g_hLineApp, m_dwDeviceID, &m_hLine, dwAPIVersion, 0, 1, LINECALLPRIVILEGE_OWNER|LINECALLPRIVILEGE_MONITOR, LINEMEDIAMODE_DATAMODEM, NULL);
Tried, but no change
Michael P Butler wrote:
You could also try calling lineGetDevCaps first and get the dwMediaModes value and use that in place of LINEMEDIAMODE_DATAMODEM.
dwMediaModes from lineGetDevCaps returns LINEMEDIAMODE_DATAMODEM | LINEMEDIAMODE_INTERACTIVEVOICE. Using this in the call to lineOpen returns 0x2F, LINEERR_INVALMEDIAMODE. Using just _DATAMODEM is ok though.
Michael P Butler wrote:
Are you getting any LINE_REPLY messages, are they reporting any errors.
Two LINE_REPLY messages are received (see earlier trace log), neither indicate any errors.
Michael P Butler wrote:
Another source of help maybe, http://www.sellsbrothers.com/writing/telprog/. There are some good links here.
I've downloaded the source, I'll have to look and see if it is any help.
Derek Lakin.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
Hi,
I'm a bit new to visual c++ and i'm trying to figure out the right style to create and use new .h and .cpp files in vc++.
Say I want to implement a new module of the project in a seperate file. And say I created the new.h and new.cpp files. Now the question is, how should I set the #include lines in the entire project in order to make it work? In new.cpp, I want to use the libraries included in stdafx.h. And in the other parts of the application that stadfx.h is included, I want to use the code that resides in new.cpp.
I tried many different ways of including one another but I couldn't find an appropriate one. It either tels me that in my new.cpp file, "unexpected end of file while looking for precompiled header directive" error is present, or it reports multiple definitions. 
I think you got what I'm trying to do, so pls help me how to set the include graph thorughout my application.
Thanx in advance.
|
|
|
|
|
#include "stdafx.h" must be the first #include of all, always. Apart from this, include the new header in those .cpps that require it. If your new module is used by many other parts throughout the libvrary, you can edit stdafx.h and add the #include there.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Ok I see now. new.h includes nothing, new.cpp includes new.h and stdafx.h, and stdafx.h includes new.h. new.cpp is automatically built with other cpps.
Thanx again.
|
|
|
|
|
|
the stdafx.h has this line:
// TODO: reference additional headers your program requires here
I want to use new.h in most of the cpp files, so I guess what I did is apropriate.
|
|
|
|
|
gazihan wrote:
I want to use new.h in most of the cpp files, so I guess what I did is apropriate.
Okay! If you are including new.h inside stdafx.h, then do not include new.h in any of your cpp files, since by including stdafx.h you implicitly include new.h as well.
Regards
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
gazihan wrote:
"unexpected end of file while looking for precompiled header directive"
this error can usually be avoided by changing in Project/Settings/C C++ tab
Select a .cpp in the tree left
Category : Precompiled Header
Set it to Dont'use ...
But do not do that for stdafx.cpp of course
~RaGE();
|
|
|
|
|
In Windows XP, shadow could be dropped for the mouse cursor, menu, the
window(if the shadow style set), and even the text of the icon titles on desktop.
Anybody can you give me some tips on how those shadows are generated, how do you think Microsoft achieve this from your feeling? Does this effect need support by hardware? Are they using gaussian blur algorithm or something else like direct painting.
Any tips and discussions are welcome.
jason s
|
|
|
|
|
I think they use their (quite inefficient I might add) kernel-mode implementation for alpha blending. Possibly optimized for just use 50% intensity of the drop-shadow, but I'm quite (almost 100%) certain they don't use hardware support. Why? They still haven't spec'd it for the device drivers (AFAIK).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
