a weird behavior
-
I've got the following file header structure with every field ending by '\0':
struct CF_HEADER
{
TCHAR strIdentifier[7]; // "XXXXXX"
TCHAR bHasPath[2];
TCHAR bOrder[2];
TCHAR nTime[4];
TCHAR nEffect[2];
TCHAR nNum[3];
TCHAR nPos[3];
};Then I initialized a UNICODE .txt file with this header. And in the file the following can be seen by Notepad:
XXXXXX 0 0 000 0 00 00
Of course there're times when these data should be updated. One of these functions to update the bOrder field is like this:
CF_HEADER m_cfhdInfo;
CFile file;
... // some other functions and reading the header into m_cfhdInfo
void SetOrder(BOOL bOrder)
{
_itot_s(bOrder, &m_cfhdInfo.bOrder[0], sizeof(TCHAR), 10);updateHeader();}
void updateHeader()
{
file.Seek(2, CFile::begin); // never overwrites 0xFEFF
file.Write(&m_cfhdInfo, sizeof(CF_HEADER));
}When I called SetOrder(TRUE), things proved weird. The following data can be seen in the file by Notepad:
XXXXXX 01 000 0 00 00
However, I had expected the results like this:
XXXXXX 0 1 000 0 00 00
Anyone could help? Thanks in advance.
-
I've got the following file header structure with every field ending by '\0':
struct CF_HEADER
{
TCHAR strIdentifier[7]; // "XXXXXX"
TCHAR bHasPath[2];
TCHAR bOrder[2];
TCHAR nTime[4];
TCHAR nEffect[2];
TCHAR nNum[3];
TCHAR nPos[3];
};Then I initialized a UNICODE .txt file with this header. And in the file the following can be seen by Notepad:
XXXXXX 0 0 000 0 00 00
Of course there're times when these data should be updated. One of these functions to update the bOrder field is like this:
CF_HEADER m_cfhdInfo;
CFile file;
... // some other functions and reading the header into m_cfhdInfo
void SetOrder(BOOL bOrder)
{
_itot_s(bOrder, &m_cfhdInfo.bOrder[0], sizeof(TCHAR), 10);updateHeader();}
void updateHeader()
{
file.Seek(2, CFile::begin); // never overwrites 0xFEFF
file.Write(&m_cfhdInfo, sizeof(CF_HEADER));
}When I called SetOrder(TRUE), things proved weird. The following data can be seen in the file by Notepad:
XXXXXX 01 000 0 00 00
However, I had expected the results like this:
XXXXXX 0 1 000 0 00 00
Anyone could help? Thanks in advance.
Krauze wrote:
_itot_s(bOrder, &m_cfhdInfo.bOrder[0], sizeof(TCHAR), 10);
Should be
_itot_s(bOrder, &m_cfhdInfo.bOrder[0], sizeof(m_cfhdInfo.bOrder)/sizeof(m_cfhdInfo.bOrder[0]), 10);
Anyway both give the same result, I suppose. Why are you using 'generic text mapping' while producing a UNICODE file? :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Krauze wrote:
_itot_s(bOrder, &m_cfhdInfo.bOrder[0], sizeof(TCHAR), 10);
Should be
_itot_s(bOrder, &m_cfhdInfo.bOrder[0], sizeof(m_cfhdInfo.bOrder)/sizeof(m_cfhdInfo.bOrder[0]), 10);
Anyway both give the same result, I suppose. Why are you using 'generic text mapping' while producing a UNICODE file? :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Yes, they turned out to be the same. BTW, I reckon I need use wchar_t instead of TCHAR......as you said... anyways, thank you all the same
Could you please post the code that fills the struct at first (the one that produced the right ouptut)? :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
I've got the following file header structure with every field ending by '\0':
struct CF_HEADER
{
TCHAR strIdentifier[7]; // "XXXXXX"
TCHAR bHasPath[2];
TCHAR bOrder[2];
TCHAR nTime[4];
TCHAR nEffect[2];
TCHAR nNum[3];
TCHAR nPos[3];
};Then I initialized a UNICODE .txt file with this header. And in the file the following can be seen by Notepad:
XXXXXX 0 0 000 0 00 00
Of course there're times when these data should be updated. One of these functions to update the bOrder field is like this:
CF_HEADER m_cfhdInfo;
CFile file;
... // some other functions and reading the header into m_cfhdInfo
void SetOrder(BOOL bOrder)
{
_itot_s(bOrder, &m_cfhdInfo.bOrder[0], sizeof(TCHAR), 10);updateHeader();}
void updateHeader()
{
file.Seek(2, CFile::begin); // never overwrites 0xFEFF
file.Write(&m_cfhdInfo, sizeof(CF_HEADER));
}When I called SetOrder(TRUE), things proved weird. The following data can be seen in the file by Notepad:
XXXXXX 01 000 0 00 00
However, I had expected the results like this:
XXXXXX 0 1 000 0 00 00
Anyone could help? Thanks in advance.
Are you sure
TRUEis defined as 1? I know in MFC it is, but I've seen implementations that use the definition#define FALSE 0
#define TRUE (!FALSE)I don't see how this could be the cause of your problem, but it might add to it. Also, have you checked the type
BOOLis in fact defined asintand not overwritten by some old header? Wouldn't be the first time I've seen conflicting macro definitions... You could of course overcome such issues by explicitely defining an int variable that holds the intended value:void SetOrder(BOOL bOrder) {
int iOrder(bOrder?1:0);
_itot_s(iOrder, ...P.S.: I just checked the definition of the not operator '!', and it appears my above example
#define TRUE (!FALSE)
would in fact result in the definition
#define TRUE true
(provided you have a modern C++ compiler that supports the type bool). In a context that requires an int,
truewould be converted to 1 as required by the standard, so the concern I brought up can in fact not be a problem at all, and my workaround is uncalled for.modified on Friday, April 1, 2011 10:41 AM
