Writing in a file using CArchive class - C / C++ / MFC Discussion Boards

cmos12-Dec-09 5:07

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?

Re: Named Mutex not visible from DLL

Bram van Kampen12-Dec-09 16:08

Bram van Kampen

12-Dec-09 16:08

Yes, It does!
It Calls GetModuleHandle(NULL)
ASSERTS (at this Stage that the ModuleHandle is 0x00400000)
Cals GetModuleFileName()
The Result is Stripped to remove up to the 'last '\', and the first '.' thereafter. This function is Also in the same DLL, I got it to print it's name to a DBG Text File,The printed name is always 'MyApp'.
When I trace into the DLL, the Name is Correct, and a New Mutex is created, regardless of the old one. When I move the file back to the App, it works a advertised.

Thanks Smile | :)

Bram van Kampen

Re: Named Mutex not visible from DLL

Richard MacCutchan12-Dec-09 22:55

Richard MacCutchan

12-Dec-09 22:55

I noticed yesterday some remarks in the MSDN document about creating the MUTEX in local or global space. You may want to check that you are doing it according to those rules.

Re: Named Mutex not visible from DLL

Migounette13-Dec-09 2:36

Migounette

13-Dec-09 2:36

Take care if you place it in a DLL you have to distinguish action done in the DLL:

BOOL WINAPI DllMain(
HINSTANCE hinstDLL, // handle to DLL module
DWORD fdwReason, // reason for calling function
LPVOID lpReserved // reserved
)
{
BOOL fInit = FALSE;
WORD wVersionRequested;
WSADATA wsaData;

// Register the log
switch( fdwReason )
{
case DLL_PROCESS_ATTACH:
...
case DLL_THREAD_ATTACH:
...
case DLL_THREAD_DETACH:
...
case DLL_PROCESS_DETACH:
...
};

What is the goal of your mutex ?
Prevent multiple loads of the DLL or block for security reasons ?

Tell me more...

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