C / C++ / MFC

Problem of Property of Configuration

28-Mar-12 5:46

Is this a C/C++ question?

Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman

doanhanam27-Mar-12 16:30

27-Mar-12 16:30

I use FILE to write binary in to a file
And It it alright .

But when I use in MFC , the result is totally different . þ in crt becomes € . I know this is just the missing or wrong in the property of configuration .
Any one experienced this minor can give an advice to me .

Thanks you .

hi world

Richard MacCutchan27-Mar-12 22:20

27-Mar-12 22:20

You are confusing character fonts and binary values. Please explain what you are writing to the file and why the values that you read back are not correct.

Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman

doanhanam27-Mar-12 23:27

27-Mar-12 23:27

I means the File in C++ in crt mode is to write binary and this is different when I do not change any thing at all the code using FILE and fwrite() and use it in MFC mode . With the same content to write . And at the result , there are different .

I think that MFC must have some thing in property of configuration so that the content writen is unchanged when I use in MFC . I guess so and I do not know more . May be some one experienced this before .

Thanks you a lot for your advice .
I appreciate it a lot ..

hi world

Richard MacCutchan28-Mar-12 0:30

28-Mar-12 0:30

You have still not explained how the file content is different. If you write a binary file via straight Win32 calls or via MFC then it will be the same (assuming you write exactly the same data).

Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman

doanhanam31-Mar-12 21:31

31-Mar-12 21:31

I am sure and check carefully
I write the audio file and in crt mode verything is totally alright . But in MFC , with exact the same code . No thing change at all in the code . Everything is the same . And original code use FILE with fwrite is pure C . But file at the result are different with the character like that . So I know that must change some thing in the property of configuration only . But now I try to use File writer in MFC given .
Thank you
have nice weekend .

hi world

Richard MacCutchan31-Mar-12 21:45

31-Mar-12 21:45

You have not shown any of your code so it is impossible to guess what you are doing wrong. Why do you think this has something to do with "property of configuration" (whatever that means)?

Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman

Jochen Arndt28-Mar-12 1:03

Jochen Arndt

28-Mar-12 1:03

Because you are complaining about different characters, I assume that you are writing some kind of text strings. You should show the code to write and read and provide some information about the data (text string type and example).

When writing such strings as binary data to a file, the code points of each char are written according to the the type of the string (char or wchar). With chars, the code points are defined by the locale used by the application (code pages with Windows). When writing such text data and reading them in again with the same application and printing them out, the displayed result will be same. But when using different applications, the result may be unexpected when different char types, encodings or locales (code pages) are used. To verify the data that has been written, you may use a hex file editor.

The characters from your post are the small letter thorn and the Euro currency sign. These are represented by different bytes with different encodings:

                    þ       €
Unicode code point: U+00FE  U+20AC
UTF-16LE:           00 FE   20 AC
UTF-8:              C3 BE   E2 82 AC
Windows-1252:       FE      80
ISO-8859-15         FE      A4

doanhanam31-Mar-12 21:27

I can't figure out how to extract my match from regex

31-Mar-12 21:27

Thanks you so much ,
I think that because the background of MFC do not support FILE exactly . I still wonder that why FILE* is C, but meets kind of problem .
More over I know that MFC is just C++ only . So I will use the file writer in mfc .
Thanks you a lot .
I appreciate it a lot .
Good weekend .

hi world

jkirkerx27-Mar-12 8:50

jkirkerx

27-Mar-12 8:50

I have used regex in c++ win32 to confirm email addresses, and to validate, but this is the first time I have used it to extract certain data.

I can't figure out how to access the pointer mBuf in the match to first, and copy the value to another buffer for further processing. I can see the data using debug and watch. mBuf[0](140)

I want to copy the first match to a TCHAR Buffer, but I'm clueless as to how. I see many examples using cout<<mbuf[0], i="" tried="" a="" swprintf_s(="" buffer,="" l"%s",="" mbuf[0]="" )but="" don't="" get="" actual="" text,="" just="" strange="" values.="" no="" clue="" how="" to="" proceed.

<pre="">
std::wsmatch mBuf;
std::wregex wxDef( L"^P.*EP" );
std::regex_search( wstrPB, mBuf, wxDef );

if ( mBuf[0].matched == TRUE ) {
dwProjectBuffer = mBuf.length();
pzProjectBuffer = new TCHAR[ dwProjectBuffer + 1 ];
DWORD dwErrorCode = GetLastError();

}

I think I figured it out

jkirkerx27-Mar-12 9:56

jkirkerx

27-Mar-12 9:56

It works, so I'll stick with it for now.

std::wstring wPB = mBuf.str();

Tooltip issue with dialog app

David Crow27-Mar-12 7:21

27-Mar-12 7:21

In a dialog app created with VS2008, I have code to handle tooltip messages that is almost identical to what is in winfrm.cpp. The tooltip itself does pop up, but if I mouse over it while it is still being displayed, I get an assertion on line 896 of wincore.cpp. If I let the tooltip go away, moving the mouse simply brings it up again without issue.

As this happens so consistently (i.e., easy to reproduce), I was surprised when I could find no mention of it on the Web. Someone did ask a similar question here.

I can do this same thing with VS6 and it works fine (i.e., no assertion).

- DC

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous

modified 28-Mar-12 15:11pm.

Code-o-mat27-Mar-12 8:51

27-Mar-12 8:51

Show us some relevant code AND show us the assertion that fails, please.

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<

David Crow27-Mar-12 9:21

27-Mar-12 9:21

Code-o-mat wrote:
Show us some relevant code...

BOOL CMyDialog::OnToolTipText(UINT, NMHDR* pNMHDR, LRESULT* pResult)
{
    ENSURE_ARG(pNMHDR != NULL);
    ENSURE_ARG(pResult != NULL);
    ASSERT(pNMHDR->code == TTN_NEEDTEXTA || pNMHDR->code == TTN_NEEDTEXTW);

    // need to handle both ANSI and UNICODE versions of the message
    TOOLTIPTEXTA* pTTTA = (TOOLTIPTEXTA*)pNMHDR;
    TOOLTIPTEXTW* pTTTW = (TOOLTIPTEXTW*)pNMHDR;
    TCHAR szFullText[256];
    UINT_PTR nID = pNMHDR->idFrom;
    BOOL bReturn FALSE;

    if (pNMHDR->code == TTN_NEEDTEXTA && (pTTTA->uFlags & TTF_IDISHWND) ||
        pNMHDR->code == TTN_NEEDTEXTW && (pTTTW->uFlags & TTF_IDISHWND))
    {
        // idFrom is actually the HWND of the tool
        nID = ::GetDlgCtrlID((HWND)nID);
    }

    if (nID != 0) // will be zero on a separator
    {
        // don't handle the message if no string resource found
        if (AfxLoadString((UINT)nID, szFullText) != 0)
        {
#ifndef _UNICODE
            if (pNMHDR->code == TTN_NEEDTEXTA)
                strncpy_s(pTTTA->szText, _countof(pTTTA->szText), strFullText, _TRUNCATE);
            else
                _mbstowcsz(pTTTW->szText, strFullText, _countof(pTTTW->szText));
#else
            if (pNMHDR->code == TTN_NEEDTEXTA)
                _wcstombsz(pTTTA->szText, strFullText, _countof(pTTTA->szText));
            else
                wcsncpy_s(pTTTW->szText, _countof(pTTTW->szText), strFullText, _TRUNCATE);
#endif

            bReturn = TRUE;
	}
    }

    *pResult = 0;

    // bring the tooltip window above other popup windows
    ::SetWindowPos(pNMHDR->hwndFrom, HWND_TOP, 0, 0, 0, 0, SWP_NOACTIVATE | SWP_NOSIZE | SWP_NOMOVE | SWP_NOOWNERZORDER);

    return bReturn;
}

Code-o-mat wrote:
...show us the assertion that fails, please.

line 896 of wincore.cpp:

ASSERT(::IsWindow(m_hWnd));

modified 28-Mar-12 15:01pm.

Code-o-mat27-Mar-12 9:34

27-Mar-12 9:34

DavidCrow wrote:
line 896 of wincore.cpp:

ASSERT(::IsWindow(m_hWnd));

Well, this still doesn't tell much because i have 2 versions of wincore.cpp, the one that comes with VS2003 and the one that comes with VS2010 and neither of them has an ASSERT of any kind on line 896. Could it be that here:

DavidCrow wrote:
::SetWindowPos(pNMHDR->hwndFrom, HWND_TOP, 0, 0, 0, 0, SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE|SWP_NOOWNERZORDER);

the handle you specify isn't correct?

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<

David Crow27-Mar-12 9:47

27-Mar-12 9:47

Code-o-mat wrote:

line 896 of wincore.cpp:

ASSERT(::IsWindow(m_hWnd));
Well, this still doesn't tell much because i have 2 versions of wincore.cpp, the one that comes with VS2003 and the one that comes with VS2010 and neither of them has an ASSERT of any kind on line 896.

What about near line 896 (I'm using VS2008)? It's in the CWnd::AssertValid() method.

Code-o-mat wrote:
Could it be that here:

DavidCrow wrote:
::SetWindowPos(pNMHDR->hwndFrom, HWND_TOP, 0, 0, 0, 0, SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE|SWP_NOOWNERZORDER);
the handle you specify isn't correct?

No, because I initially did not have that statement. It was the last differing statement (from winfrm.cpp) that I added, but made no difference.

Code-o-mat27-Mar-12 10:48

27-Mar-12 10:48

Still not enough information to say what is wrong. What's in the call stack?

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<

David Crow27-Mar-12 10:58

27-Mar-12 10:58

Code-o-mat wrote:
What's in the call stack?

From the time I click a button to bring up the dialog until the assertion fires:

mfc90ud.dll!CWnd::AssertValid() Line 896 + 0x24 bytes C++
mfc90ud.dll!AfxAssertValidObject(const CObject * pOb=0x00837b60, const char * lpszFileName=0x60cb4838, int nLine=2433) Line 107 C++
mfc90ud.dll!CWnd::GetTopLevelParent() Line 2435 C++
mfc90ud.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x0073dce8) Line 241 + 0x8 bytes C++
mfc90ud.dll!CWinThread::PreTranslateMessage(tagMSG * pMsg=0x0073dce8) Line 777 + 0x9 bytes C++
mfc90ud.dll!AfxPreTranslateMessage(tagMSG * pMsg=0x0073dce8) Line 252 + 0x11 bytes C++
mfc90ud.dll!AfxInternalPumpMessage() Line 178 + 0x18 bytes C++
mfc90ud.dll!CWinThread::PumpMessage() Line 900 C++
mfc90ud.dll!AfxPumpMessage() Line 190 + 0xd bytes C++
mfc90ud.dll!CWnd::RunModalLoop(unsigned long dwFlags=4) Line 4386 + 0x5 bytes C++
mfc90ud.dll!CPropertySheet::DoModal() Line 954 + 0xc bytes C++
StafTrakrAdmin.exe!CStafTrakrAdminDialog::OnBnClickedDefault() Line 158 C++

Code-o-mat27-Mar-12 11:28

27-Mar-12 11:28

I'm afraid i still can't say what is wrong, sorry, unless you are willing to share the project (or some extract of it), maybe it would help if i could look around it a bit, see variables and such.

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<

David Crow27-Mar-12 17:06

27-Mar-12 17:06

Code-o-mat wrote:
...maybe it would help if i could look around it a bit, see variables and such.

It's extremely easy to duplicate.

Randor 27-Mar-12 13:58

Randor

27-Mar-12 13:58

David,

It looks like this is happening within the MFC framework. Double click on this line:

DavidCrow wrote:
mfc90ud.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x0073dce8) Line 241 + 0x8 bytes C++

The memory address 0x0073dce8 is a MSG struct[^]. Please try to find the value of MSG.message so we know what window message is being processed by the MFC framework. Your debugger should be able to show you this. It would be nice to know what window message we are dealing with.

The debug string you posted implies that the assertion occured at:

C++

ASSERT(::IsWindow(m_hWnd));

Which means the m_hWnd member of the CWnd/CTempWnd object that is returned by GetTopLevelParent() is apparently not a valid window.

Best Wishes,
-David Delaune

David Crow27-Mar-12 17:10

27-Mar-12 17:10

Randor wrote:
Please try to find the value of MSG.message so we know what window message is being processed by the MFC framework. Your debugger should be able to show you this. It would be nice to know what window message we are dealing with.

The message is 512 (WM_MOUSEFIRST).

Randor wrote:
The debug string you posted implies that the assertion occured at:
C++
ASSERT(::IsWindow(m_hWnd));
Which means the m_hWnd member of the CWnd/CTempWnd object that is returned by GetTopLevelParent() is apparently not a valid window.

It's as though a second tooltip window is being requested (i.e., a tooltip for a tooltip?) before the first one is completely destroyed.

Randor 27-Mar-12 22:19

Randor

27-Mar-12 22:19

Hey David,

DavidCrow wrote:
The message is 512 (WM_MOUSEFIRST).

Well the WM_MOUSEFIRST definition is not a window message it was defined to make it easier to find the range of mouse message with WM_MOUSEFIRST/WM_MOUSELAST. However WM_MOUSEFIRST is equal to WM_MOUSEMOVE. It is actually the WM_MOUSEMOVE message being processed.

DavidCrow wrote:
It's as though a second tooltip window is being requested (i.e., a tooltip for a
tooltip?) before the first one is completely destroyed.

My guess:
I would guess that it might have something to do with the way your creating or passing the CWnd that owns the tooltip. The MFC framework probably expects the handle to the owner CWnd to be in the permanent handle map. I suspect that what is happening... is that a CTempWnd object owns the tooltip... and the MFC framework is deleting the temporary CTempWnd object. When you move your mouse over the tooltip the memory address at m_hWnd may be invalid because the CTempWnd was deleted. This is the only thing I can think of that would cause what you decribe.

Are you using the GetDlgItem function anywhere? Because when GetDlgItem cannot find a permanent object in the MFC CHandleMap it will return a pointer to a temporary CTempWnd object. You should never pass the HWND returned from GetDlgItem to other functions...

Could you tell me more about the window that owns the tooltip?

Also... please call CWnd::FromHandlePermanent()[^] to check if the tooltips owner CWnd is in the MFC permanent handle map. If it returns NULL then this is most likely your problem and we can fix it.

Best Wishes,
-David Delaune

David Crow28-Mar-12 2:30