C / C++ / MFC Discussion Boards

Re: TAPI send data

Richard MacCutchan12-Dec-09 4:25

Richard MacCutchan

12-Dec-09 4:25

cmos wrote:
I dont need serial communication.

So how else do you think you can communicate with devices connected to a serial port? The fact that your data will go through a modem should not make any difference, you just have to put the dialling sequences at the begnning to establish connection with your remote device. This is simlar to an old fashioned TTY terminal setup. If you Google this you can probably find a ready made program to help you.

Re: TAPI send data

cmos12-Dec-09 4:36

cmos

12-Dec-09 4:36

<blockquote class="FQ"><div class="FQA">Richard MacCutchan wrote:</div>So how else do you think you can communicate with devices connected to a serial port?</blockquote>
Actually I thought for this reason there is the TAPI.

But I considered about your statement. I guess you mean that I open the modem com-port and then send the AT commands
establishing the modem connection ? Then I can send data with
the Write command and receive with the Read command. Hope this is the right idea (?).

regards,
cmos

Re: TAPI send data

Richard MacCutchan12-Dec-09 4:53

Richard MacCutchan

12-Dec-09 4:53

That's correct; the modem part is required to establish the end to end connection, and after that you talk to the device directly as if the modem is not present. A bit like making a telephone call.

Re: TAPI send data

cmos12-Dec-09 5:07

cmos

12-Dec-09 5:07

Ok, thanks a lot.
A last question anyway. Is that possible with TAPI as well ? Making a call and sending data ?

regards,
cmos

Re: TAPI send data

Richard MacCutchan12-Dec-09 6:04

Richard MacCutchan

12-Dec-09 6:04

cmos wrote:
Is that possible with TAPI as well ? Making a call and sending data ?

Sorry but I don't know, I've never used TAPI, I can only suggest you look at the information on MSDN, or Google it.

Re: TAPI send data

cmos12-Dec-09 14:19

cmos

12-Dec-09 14:19

Hello,
I downloaded a terminal program and tried out some AT commands.
There it works. For example when I send ATZ i get the modems
baudrate. Or when I send AT&F i get an OK as reply.

But when I start my program, open the com port and send
AT&F I get as reply AT&F. When I send ATZ I get as reply
ATZ. So, then I tried another tool from the internet
and opened the comport with it. There's the same problem.
When I send an AT command I get no answer but I get back the
AT command that i've send just one second ago.

Did I miss some import part ?

I just call Serial.Write(_T("ATZ"), sizeof(_T("ATZ")));

Any ideas ?

regards,
cmos

Re: TAPI send data

Richard MacCutchan12-Dec-09 22:52

Richard MacCutchan

12-Dec-09 22:52

cmos wrote:
I just call Serial.Write(_T("ATZ"), sizeof(_T("ATZ")));

I think these characters need to be in ASCII. Serial lines do not handle Unicode.

Re: TAPI send data

cmos13-Dec-09 1:18

cmos

13-Dec-09 1:18

Hello,

now everything works. The reason for not seeing the rest of the response was that there
is a 0 (zero) in the answer string from the modem. So the string "ends" at this position.

thanks,
cmos

Re: TAPI send data

Richard MacCutchan13-Dec-09 1:33

Richard MacCutchan

13-Dec-09 1:33

cmos wrote:
thanks

Happy to help; good luck with your project.

Re: TAPI send data

armecos22-Feb-10 17:01

armecos

22-Feb-10 17:01

Don't worry about it.
try this debug tool.

http://www.armecos.com/en/comtrace.html[^]

Writing in a file using CArchive class

Le@rner11-Dec-09 22:47

Le@rner

11-Dec-09 22:47

Hi all,

I am trying to write into file using CArchive class. I have written a simple code just to open a file using and write into it using CArchive class.

CFile file;
CFileException e;
file.Open(L"C:\\file.txt",CFile::modeReadWrite,&e);
CArchive ar (&file, CArchive::store);

char c = 'A';
int i = -400;
float f = 1.25f;
double d = 3.14159265;
ar << c;
ar << i;
ar << f << d;

but when i open the file the content inside it is

Apþÿÿ ?ñÔÈSû! @

Please anybody can tell me what exactly i am doing wrong

Thanks in advance

To accomplish great things, we must not only act, but also dream;
not only plan, but also believe.

Re: Writing in a file using CArchive class

Nuri Ismail11-Dec-09 23:51

Nuri Ismail

11-Dec-09 23:51

Le@rner wrote:
but when i open the file the content inside it is

Apþÿÿ ?ñÔÈSû! @

This is absolutely normal because CArchive will write your data in binary mode. Smile | :)

If you want to write a text file you can use the CStdioFile[^] class like this:

CStdioFile file;
CFileException e;
if(!file.Open(_T("C:\\file.txt"), CFile::modeCreate | CFile::modeWrite | CFile::typeText, &e))
{
	TRACE(_T("File could not be opened %d\n"), e.m_cause);
}
else
{
        char c = 'A';
	int i = -400;
	float f = 1.25f;
	double d = 3.14159265;
	
        CString str;
	str.Format(_T("%c %d %f %f"), c, i, f, d);
	
        file.WriteString(str);
	file.Close();
}

Using the STL file streams could also be an option. In this case the code could be something like:

#include <fstream>

// Deal with both Unicode and Non-Unicode builds
#ifdef _UNICODE
	#define _tofstream std::wofstream
#else
	#define _tofstream std::ofstream
#endif

........

char c = 'A';
int i = -400;
float f = 1.25f;
double d = 3.14159265;
	
_tofstream fout;
fout.open(_T("C:\\file.txt"));
fout << c << _T(" ")<< i << _T(" ") << f << _T(" ")<< d;
fout.close();

I hope this helps! Smile | :)

Regards

Nuri Ismail

Re: Writing in a file using CArchive class

pacotest17-Dec-09 18:42

pacotest

17-Dec-09 18:42

that's right
it's binary mode
so itis Apþÿÿ ?ñÔÈSû! @

Named Mutex not visible from DLL

Bram van Kampen11-Dec-09 15:03

Bram van Kampen

11-Dec-09 15:03

Hi,

I use the following code to create a Named Mutex, to ensure that only One Instance of an App is running on a Machine.

<br />
     CString AppName=GetAppNameRoot();<br />
     CString MutexName=AppName+"_60D44FC0_07ED_11D8_A55E_444553540000_";<br />
<br />
     HANDLE exclusion = CreateMutex(NULL, FALSE, MutexName);<br />
     DWORD err = ::GetLastError();<br />
     // Check exclusion and err, Get Out Gracefully if CreateMutex Failed<br />
     <br />

All worked fine as advertised. Then I placed the module containing the Above Code in a DLL, and CreateMutex never Fails, allowing Multiple copies to Run.

I Don't understand why, or, even How to Debug this.

Regards, Smile | :)

Bram van Kampen

Re: Named Mutex not visible from DLL

«_Superman_»11-Dec-09 18:37

«_Superman_»

11-Dec-09 18:37

You're clearly doing something wrong.
It works perfectly even if the named mutex is inside a DLL.

«_Superman_»
I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++)

Re: Named Mutex not visible from DLL

Rajesh R Subramanian11-Dec-09 22:29

Rajesh R Subramanian

11-Dec-09 22:29

Bram van Kampen wrote:
Then I placed the module containing the Above Code in a DLL, and CreateMutex never Fails

Well, the call won't fail (the return value won't be NULL). It rather returns a handle to the existing mutex object. However, if you make an immediate call to GetLastError() (which you should do), you'd see that the error code has been set to ERROR_ALREADY_EXISTS.

I've always thought this is kinda weird, but that's how it is.

“Follow your bliss.” – Joseph Campbell

Re: Named Mutex not visible from DLL

krmed12-Dec-09 4:16

krmed

12-Dec-09 4:16

Calling GetLastError when the call did not fail is not recommended - the error code that you get will probably be from the last failed action.

You should only call GetLastError if the CreateMutex call failed - then it will give you a reliable error code.

Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193

Re: Named Mutex not visible from DLL

Rajesh R Subramanian12-Dec-09 4:52

Rajesh R Subramanian

12-Dec-09 4:52

krmed wrote:
Calling GetLastError when the call did not fail is not recommended - the error code that you get will probably be from the last failed action.
You should only call GetLastError if the CreateMutex call failed - then it will give you a reliable error code.

That statement is wrong and misleading. Please read the documentation[^]:

Return Value

If the function succeeds, the return value is a handle to the newly created mutex object.

If the function fails, the return value is NULL. To get extended error information, call GetLastError.

If the mutex is a named mutex and the object existed before this function call, the return value is a handle to the existing object, GetLastError returns ERROR_ALREADY_EXISTS, bInitialOwner is ignored, and the calling thread is not granted ownership. However, if the caller has limited access rights, the function will fail with ERROR_ACCESS_DENIED and the caller should use the OpenMutex function.

I also mentioned in my original post that the call to GetLastError() must be made immediately (before anything else).

“Follow your bliss.” – Joseph Campbell

Re: Named Mutex not visible from DLL

krmed12-Dec-09 5:14

krmed

12-Dec-09 5:14

Yes of course - I do read the documentation, however I overlooked that detail. Many users call GetLastError after calling other methods that don't set it unless there's an error.

Sorry about that.

Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193

Re: Named Mutex not visible from DLL

Rajesh R Subramanian12-Dec-09 6:15

Rajesh R Subramanian

12-Dec-09 6:15

krmed wrote:
Many users call GetLastError after calling other methods that don't set it unless there's an error.

Yes, but there are those crafty API calls that will do stuff like this.

krmed wrote:
Sorry about that.

No problem. Smile | :)

“Follow your bliss.” – Joseph Campbell

Re: Named Mutex not visible from DLL

Bram van Kampen12-Dec-09 15:46

Bram van Kampen

12-Dec-09 15:46

Been There, (actualy, Is part of the function the details of which I spared the Details, and covered by a comment)
GetLastError() returns 0!

Regards Smile | :)

Bram van Kampen

Re: Named Mutex not visible from DLL

Bram van Kampen12-Dec-09 16:54

Bram van Kampen

12-Dec-09 16:54

Rajesh R Subramanian wrote:
Well, the call won't fail (the return value won't be NULL). It rather returns a handle to the existing mutex object. However, if you make an immediate call to GetLastError() (which you should do), you'd see that the error code has been set to ERROR_ALREADY_EXISTS.

Well, for you who needs an explanation, By 'Not Fail' I mean Did as Documented.

Why do you respond twice to this post!

Mad | :mad:

Bram van Kampen

Re: Named Mutex not visible from DLL

Rajesh R Subramanian12-Dec-09 18:54

Rajesh R Subramanian

12-Dec-09 18:54

Bram van Kampen wrote:
Why do you respond twice to this post!

Who responded twice to any post? I see everyone has responded only once (except you have responded twice to my answer)!

I'd like to know if that's your vote on my post?

“Follow your bliss.” – Joseph Campbell

Re: Named Mutex not visible from DLL

Bram van Kampen14-Dec-09 12:25

Bram van Kampen

14-Dec-09 12:25

Hi,
Appologies,
My Fault!
Blush | :O

Bram van Kampen

Re: Named Mutex not visible from DLL

Richard MacCutchan12-Dec-09 1:46

Richard MacCutchan

12-Dec-09 1:46

Bram van Kampen wrote:
CString AppName=GetAppNameRoot();

Are you sure this function always returns the same value, as you are using it as part of the mutex name?

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.