|
the right key (extended key) is pressed if bit 24 of lParam is set. so use the bitwise AND operator (&) to check that bit.
if (lParam & 0x01000000)
{
}
|
|
|
|
|
Thank you. Your tip works. But one question remains:
When I read "bit 24 of lParam", how do I get the binary code like "01000000" ? 
|
|
|
|
|
0x01000000 is not a binary code, it is a hexadecimal number (note the '0x'). Each digit in a hexadecimal number represents four bits.
Hexadecimal Digital Binary
0 0 0000
1 1 0001
2 2 0010
3 3 0011
4 4 0100
5 5 0101
6 6 0110
7 7 0111
8 8 1000
9 9 1001
A 10 1010
B 11 1011
C 12 1100
D 13 1101
E 14 1110
F 15 1111
So when we say bit 24 is set we get this
bit 33 2 2 1 1
number 1098 7654 3210 9876 5432 1098 7654 3210
| | | | | | |
binary 0000 0001 0000 0000 0000 0000 0000 0000
hex 0 1 0 0 0 0 0 0
Also look up bitwise operators in MSDN
|
|
|
|
|
I don't have any concern on this stuff,
but I want to say that you are very kind to do this!
Honestly I didn't ever tried to explain in detail in helping others
although I've got tons of information from others like you.
Sincerely I honor your work.
Regards,
Ryan
|
|
|
|
|
|
Ok, I've got an ATL appwizard with MFC support. Implemented a ActiveX server object (I'm trying to write an ASP extension to interface to some code i've already got working elsewhere).
To test the theories of ATL and COM, I'm trying to make a simple propert that returns the IP address of the client (from Request.ServerVariables("REMOTE_ADDR") ).
Here's the function I'm trying to use:
STDMETHODIMP CMyClass::get_GetIP(BSTR *pVal)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState())
IRequestDictionary *piRequestDic;
m_piRequest->get_ServerVariables(&piRequestDic);
VARIANT v_Param, v_Value;
_variant_t vt_Param;
vt_Param.Attach(v_Param);
vt_Param.Clear();
vt_Param.ChangeType(VT_BSTR,NULL);
vt_Param.SetString("REMOTE_ADDR");
piRequestDic->get_Item(v_Param,&v_Value);
VariantChangeType(&v_Value,&v_Value,0,VT_BSTR);
*pVal=v_Value.bstrVal;
return S_OK;
}
When I call a simple asp page that creates this object and attempts to read this GetIP property, IIS hangs. I have to use Winnt reskit's KILL.EXE to close it.
I have no idea whats wrong- i've followed my logic through several times and i'm oblivious to the prob.
help appreaciated thanks
jon h
|
|
|
|
|
Hello all. I have the following lines in my .h file (I've included the 'map' header file, and declared 'using namespace std':
typedef LRESULT (CALLBACK *MsgHandlerProc)(HWND,WPARAM,LPARAM);
typedef map<uint, msghandlerproc=""> MessageMap;
typedef MessageMap::iterator MessageMapIterator;
In my implementation file, I have the following:
MSG_HANDLER_ERROR CMsgHandler::AddHandler(UINT uMsg, MsgHandlerProc lpProc)
{
MessageMapIterator it;
it=MsgMap.find(uMsg);
if (it==MsgMap.end())
return MSG_ALREADY_DEFINED;
try
{
MsgMap.insert(pair<uint, msghandlerproc="">(uMsg, lpProc));
return MSG_SUCCESS;
} catch (...) {
return MSG_ERROR;
}
}
Though I get no errors when compiling, I get 70 something warnings, all having to do with _Tree. What does this mean? What am I doing wrong? Thanks in advance for any help.
Jamie Nordmeyer
Portland, Oregon, USA
|
|
|
|
|
what are the warnings?
if they're 4768, you can get rid of them with a simple:
#pragma warning(disable:4786)
put this before your STL includes (and after, too sometimes)
-c
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
Interesting. Every one of the warnings were C4768. Adding the #pragma before the 'map' inclusion resolved the warnings. Is this one of the supposed many problems with Microsofts implementation of STL?
Jamie Nordmeyer
Portland, Oregon, USA
|
|
|
|
|
i'm not sure if it's an MS problem or not (really, i don't know). but it's caused when identifier names grow too large due to template expansion (which STL collections apparently do a lot of).
i just always toss that pragma in whenever i use STL, just to keep things quiet.
there used to be a lot of info on this on Deja.com, but i don't see it anymore.
-c
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
Thanks for the help, Chris!
Jamie Nordmeyer
Portland, Oregon, USA
|
|
|
|
|
MS's c++ compiler is still based on a very old version of the C++ compiler that predates both the STL and templates. MS has modified it to allow templates and do a lot, but some of the basic issues surround debug info are still based on the old MS "code view" debugger (which was actually licensed from NuMega).
One of those limitations is that the debug symbol name cannot be larger than 255 characters. Unfortunately, when STL templates expand, they often generate names that are larger than 255 characters. This causes the compiler to issue a warning that it is truncating the debug info to stay within the 255 character limit.
This doesn't effect C++ code built in release mode, and it doesn't effect the actual code in debug either, just the debug information, which can cause problems for the debugger (but usually not).
It's an informational warning, and can be safely turned off.
This isn't a "problem with STL", but it is annoying.
|
|
|
|
|
And just to make it a little more annoying, it's not always possible to turn it off!
http://support.microsoft.com/support/kb/articles/Q167/3/55.ASP
We have had several situations with complex header includes where no amount of "#pragma" will stop the warnings - but we have always been able to solve this by reorganising headers (changing the order of includes and sprinkling a generous helping of #pragmas, basically).
|
|
|
|
|
And just to make it a little more annoying, it's not always possible to turn it off!
http://support.microsoft.com/support/kb/articles/Q167/3/55.ASP
We have had several situations with complex header includes where no amount of "#pragma" will stop the warnings - but we have always been able to solve this by reorganising headers (changing the order of includes and sprinkling a generous helping of #pragmas, basically).
|
|
|
|
|
hi all
twice in one day huh? i must be becoming one of those idiots i talk about 
wierd one (for me anyways) ... have a dialog with a treectrl in it ... tree gets built ok and all ... at the start of the tree build proc i do a m_tree.deletallitems() to clear it out ... if i call my tree build more than once i get an memory error on exit of the dialog:
HEAP[prog.exe]: Invalid Address specified to RtlFreeHeap( 130000, 15caa8 )
looking at the memory i see the captions i inserted into the tree and i *know* my code isnt leaking memory (at least any memory i alloc i free) ... the only solution i have found is to delete the treectrl completely and re-create one every time i redraw it ... sounds nuts huh?
the app is unicode and i'm wondering if there might be a bug in the mfc libs? or am i completely turning into an idiot and should retire from coding altogether?
thoughts & help appreciated
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
hmmm...
Duh.. so much for 20 years of coding! Huh?
|
|
|
|
|
and i'm wondering if there might be a bug in the mfc libs?
Yes sure! And now you got to figure our how to let the MS know about it!
But how?
hmmm...
Duh.. so much for 20 years of coding! Huh?
|
|
|
|
|
gee thanks
your constructive answer has shed a lot of light on the problem for me ... i can sleep safer at night knowing your there for me
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
While i'm not arguing that there aren't bugs in the MFC libraries, chances are something like this would have been found a long time ago.
It sounds like it may be a heap or stack corruption, which could result from overrunning a buffer.
|
|
|
|
|
I recently saw a form of this heap corruption in an app I am working on. I was able to trace the deallocation to an object created by a third party DLL. Linking statically to the third party lib solved the problem, and since that seemed to be a neat thing to do in other ways, I left it at that. Hmmm.. would have to check my notes on that one...
Do you notice any dif in release/debug and static/dynamic links (to the MFC)? Are you allocating any strings that might be assigned too many chars? (That's one that might pass in debug, and/or have unicode implications) Or using more than one allocation routine?
Damn... you do come up with the toughies... oh well - you did say "thoughts appreciated"
|
|
|
|
|
ahem
it turns out that vc had goofed up all my resource values in the resource.h file and i had 3 buttons on the same dialog with the same value ... the WM_CLOSE event was mapping to another function in my code and executing there
when i checked the resource.h file i had like 20 IDC_WHATEVERS as the same value ... some on the same dialog ... i am anal about those things and often check them and clear out ones i dont use anymore
some kind of alien visitation i call it
thanks for the input
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
I'm trying to use a RichEdit 2 control in an MFC app, deriving from CRichEditView and modifying the class string to "RichEdit20A".
All's going well apart from Printing and Previewing. The culprit seems to be the EM_FORMATRANGE message, which is meant to format some text in a rect and return the index of the last character formatted plus one (i.e. in terms of pages, the index of the character for the next page). MFC uses this value to compare with GetTextLength() to determine whether to end the document.
However, it seems to be treating CRLF pairs as a single character, so if my document is:
A
B
C
i.e. "A<cr><lf>B<cr><lf>C<cr><lf>", then the EM_FORMATRANGE message will return 7 as the index of the next character, whereas GetTextLength() returns 9 as the total number of characters, and hence my document never stops printing.
Any thoughts / suggestions would be welcome
Darren
|
|
|
|
|
i often use this code in dialogs to color the static controls
HBRUSH CDlgWhatever::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
if (nCtlColor == CTLCOLOR_STATIC && pWnd->GetDlgCtrlID() == IDC_MYSTATIC){
pDC->SetBkColor(RGB(...));
hbr = CreateSolidBrush(RGB(...));
}
return hbr;
}
and i just realised that i have a memory leak from the brush creation ... like hello wake up there ... but looking at the code i can't figure out where to delete the brush created as it must be returned out of the function intact or it won't exist when it gets to be used
now i may be misunderstanding this part of mfc but sheesh ... can someone put a dunce cap on me and explain please?
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Why not store an HBRUSH as a member of CDlgWhatever? Create the brush in the dialog constructor and delete in the dialog destructor (or use a CBrush instead).
Darren
|
|
|
|
|
funny how you never look at old code huh?
heh ... sheesh
lbrush is a LOGBRUSH is a dlg local var
m_brush is a dlg local cbrush
HBRUSH CDlgIdiot::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
if (nCtlColor == CTLCOLOR_STATIC && pWnd->GetDlgCtrlID() == IDC_WHATEVER){
pDC->SetBkColor(RGB(...));
lbrush.lbStyle = BS_SOLID;
lbrush.lbColor = RGB(...);
m_brush.CreateBrushIndirect(&lbrush);
hbr = (HBRUSH)m_brush.GetSafeHandle();
}
return hbr;
}
i think this is the right way
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
