|
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
|
|
|
|
|
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
|
|
|
|
|
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();
}
|
|
|
|
|
It works, so I'll stick with it for now.
std::wstring wPB = mBuf.str();
|
|
|
|
|
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.
|
|
|
|
|
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.<
|
|
|
|
|
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);
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))
{
nID = ::GetDlgCtrlID((HWND)nID);
}
if (nID != 0)
{
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;
::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));
"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:01pm.
|
|
|
|
|
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.<
|
|
|
|
|
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.
"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
|
|
|
|
|
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.<
|
|
|
|
|
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++
"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
|
|
|
|
|
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.<
|
|
|
|
|
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.
"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
|
|
|
|
|
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:
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
|
|
|
|
|
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:
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.
"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
|
|
|
|
|
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
|
|
|
|
|
The only thing I did was copy the code in CFrameWnd::OnToolTipText() to my dialog, and then call EnableToolTips(TRUE) from within OnInitDialog().
"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
|
|
|
|
|
|
Jochen Arndt wrote: I'm using the method described in the MSDN article Handling TTN_NEEDTEXT Notification for Tool Tips[^] and never had problems.
With VS2008?
Jochen Arndt wrote: However, this requires that every control has its tool tip text in a string resource with the same ID as the control.
Yes, that part was assumed.
"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
|
|
|
|
|
With VS 2003. I supplied the link for 2005. But you may selcet other versions on top of the page. Providing the text by a buffer or by ID should make no difference. But all the MSDN examples did not call SetWindowPos().
|
|
|
|
|
Jochen Arndt wrote: With VS 2003. I supplied the link for 2005. But you may selcet other versions on top of the page.
I realize that. The point I was trying to make is that MFC may have changed from one version to the next. This same code I've been using worked fine in VS6.
Jochen Arndt wrote: But all the MSDN examples did not call SetWindowPos().
See my reply here.
"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
|
|
|
|
|
Sorry, the thread is quite long.
But there is another difference between your code and the MSDN examples:
You are always returning TRUE indicating that the message has been handled. The examples (and my code) only return TRUE when the TTF_IDISHWND flag is set and the control's ID can be determined from the HWND.
|
|
|
|
|
DavidCrow wrote: The only thing I did was copy the code in
CFrameWnd::OnToolTipText() to my dialog, and then call
EnableToolTips(TRUE) from within OnInitDialog().
The tooltip related code you pasted is perfectly fine. You never answered any of my questions about the window hierarchy so I have to make further guesses. I am guessing that the tooltip being shown is for a dynamically created window. There is probably no member variable associated with the window. Read my previous statements regarding CTempWnd objects.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: You never answered any of my questions about the window hierarchy so I have to make further guesses.
I guess I don't understand. Other than calling EnableToolTips(), adding to the message map, and providing a notification handler, I don't do anything regarding creating temp windows, adding to maps, or calling GetDlgItem().
Randor wrote: There is probably no member variable associated with the window.
Actually there is. That's what I use to set/get values from the controls.
"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
|
|
|
|
|
Hi David,
Could you answer each of these questions?
1.) Are you saying that the assertion occurs when the mouse moves over ALL tooltips belonging to child windows of the dialog? Or does the assertion occur for only one of them.
2.) If it is just 1 window that causes tooltip asserts... Does the assertion occur on a window that is dynamically created such as the CListCtrl you were working on last week[^]?
I apologize for all the questions... but if you would have been very detailed in your initial description we could have avoided the guessing. Considering that you have been a member here for nearly a decade I would expect your questions to be a long narrative. Maybe even with diagrams, debugger stack frames and sprinkled with source snippets. 
Thanks,
-David Delaune
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
