|
Correction : In my previous post, please consider m_CmbEditBox as of type
CEditEx and not of type CEdit.
My exact requirement is like this :
On right-clicking the list box item the control reaches
CListBoxEx::OnContextMenu. Please see the comment :
void CListBoxEx::OnContextMenu(CWnd* pWnd, CPoint point)
{
GetParent()->TestFn();
}
What am I doing wrong for list box bcoz the same mechanism for the child
edit box of the CSubClassedComboBox works fine ie.
void CEditEx::OnContextMenu(CWnd* pWnd, CPoint point)
{
GetParent()->TestFn();
}
Is there anything to do with the temporary creation of the list box which
is not the case with edit box ? If so, how could I acquire the desired result ?
Thanks
|
|
|
|
|
One method is to send a USER message to the parent window and you should write a ahndler for that message in the parent window instead of TestFn(). And offourse it is generic.
|
|
|
|
|
...at least it appears to be a problem with stack corruption.
Here's the problem. I'm attempted to use std::string in some existing code for an enhancement I'm doing and was getting in all sorts of trouble (mainly centring around the fact that my this pointer gets trampled on). At first I thought there was something in ATL which stopped it from playing nicely with STL, but a nice person on this forum assured me that this is not the case. After a bit of shadow chasing, I think I've narrowed down the cause of the problem: the stack gets corrupted if I attempt to use a std::string (since the use of a std::string from the ATL code would presumably require a casting-type operation) in a call level deeper than two functions. That last bit was probably unintelligible (since I made that phrase up) so I'll attempt to illustrate my point with some code:
STDMETHODIMP SomeClass::SomeFunction ()
{
std::string tmp = "This is a std::string";
AnotherFunction();
}
void SomeClass::AnotherFunction ()
{
std::string tmp = "This is a std::string";
}
So if I were to drop a break point at the two std::string declarations, we have no problems when it runs through the first one (in SomeFunction) but as soon as it passes the second (in AnotherFunction), the this pointer gets corrupted ... almost as if the stack pointer got lost whilst trying to deal with the std::string.
I should add that I'm doing this on VC6.0.
Anyone ever seen this before? Anyway to get around it? It sucks having to replicate my code rather than being able to write it in a function and simply call that function everywhere I need to...
cheers!
|
|
|
|
|
Are you debugging in Debug mode or Release mode? If you are debugging in Release mode, have you set the optmization option to "Disable" ? With out this option, the watch window may display incorrect value for variables.
|
|
|
|
|
Never has any trouble using std:strings. Can you give more details? There's nothing in the code you posted that would cause stack corruption.
Steve
|
|
|
|
|
Thanks for your responses.
This is not a display problem, the this pointer *really* gets corrupted (the program crashes after awhile...).
Not sure how many more details I can offer apart from the fact that I am attempting to do this in the implementation of a public interface of a COM component; and that the original code is in ATL but the stuff I've added makes use of std::string. Obviously it could be something in the project settings which is setting this off; I'm not a 100% on compile flags etc. but I wouldn't have thought so..
|
|
|
|
|
Are you sure the problem is actually related to std::string? It sounds to me as if the client of the COM object is calling an interface method through a bad or NULL this pointer. What is the value of the this pointer when it's corrupted?
Steve
|
|
|
|
|
I'm not a 100% that it is related to std::string of course but the evidence that I've seen so far (through the debugger) appears to point to that. So these are a set of sample values of the this pointer before and after corruption:
Before the std::string declaration: 0x01779408 (debugger tells me that it's pointing to a valid object, it has valid members etc)
In the constructor of the string: 0x0012f174
After the string has been constructed: 0x0012f18c (i.e. not null but not our original this pointer either)
I should have mentioned earlier (it has just entered my mind) that the project that I am working on makes use of STLPort and so the std::string is the STLPort std::string. Possibly could be a bug in STLPort...just not sure why it's occuring now for this particular project and not for the many, MANY other times when I've used std::string without even having to think about it...
|
|
|
|
|
Make sure you're not violating the One Definition Rule[^]. I suspect this as you said you're using STLPort. My guess is that you may not be using it contently across translations units (ie. using the default STL in some file or lib and using STLPort in another file or lib).
Steve
|
|
|
|
|
Possibly. At least I have a starting point with which to start looking into this now. Thanks!
|
|
|
|
|
jozsurf wrote: Obviously it could be something in the project settings which is setting this off
Yes, In my case this was true, but not sure about yours!
I will explain mine...
First bit of a background. I am porting a project in VC6 to VC8.
So I had two projects Project1 and Project2. So my first project is a lib project. Project2 statically links to Project1. So whenever I used std::map in my Project1 class Project2 crashed. "this" was getting corrupted, I just couldn't understand what was wrong.
So my sixth sense came into play and I checked the project settings, and there it was, Project1 didn't have "_SECURE_SCL=0" defined and Project2 had this set, so obviously as we know that _SECURE_SCL does add some piece of code.
So immediately I made my project settings of all projects consistent and all crashes disappeared. 
Don't know if this is the case with you. But I am sure there is something in your project settings that's causing this problem. Most probably _SECURE_SCL related stuff.
Nibu babu thomas
Microsoft MVP for VC++
Code must be written to be read, not by the compiler, but by another human being.
Programming Blog: http://nibuthomas.wordpress.com
|
|
|
|
|
This is a nasty problem that can be hard to diagnose. Technically it's a violation of the One Definition Rule[^].
Steve
|
|
|
|
|
Yeah it does sound like it has something to do with the project settings eh? I mentioned (in a separate response in this same thread) that STLPort is being used in this project; it could well be that the settings used for building the STLPort library is different (as in the case you described). Now I just need to track down the project settings for the version of STLPort we are using...worth a look anyhow.
cheers!
|
|
|
|
|
code:
CString myfunc()
{
return CString(_T("a string"));
}
CString myfunc2()
{
return CString(_T("a string2"));
}
int _tmain(void)
{
CString tempStr(_T("hello"));
tempStr.Empty();
tempStr= myfunc();
tempStr.Empty();
tempStr = myfunc2();
}
|
|
|
|
|
|
Thanks. Before I alway do in this manner, now I clear my mind!
|
|
|
|
|
you could have step into the MFC source code and clear you mind.
|
|
|
|
|
when ever you assign new value to CString object, it will refresh it internal data member with new values!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/xml>
|
|
|
|
|
ThatsAlok when ever you assign new value to CString object, it will refresh it internal data member with new values!
Does "assign new value" also count for a CString::Format () call?
So:
CString csNotEmpty = "hee hee";
csNotEmpty.Format ("another value");
Can I be sure that csNotEmpty ends up with the value "another value", or do I need to make the
(disabled) Empty () call in between?
Thanks in advance\0
(__..-=.: nul26 :.=-..__)
|
|
|
|
|
nul26 wrote: CString csNotEmpty = "hee hee";// csNotEmpty.Empty ();csNotEmpty.Format ("another value");
this will work!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Hello everyone,
I never looked deep into the _p and dlldata file before, because they are automatically generated by MIDL compiler.
Today I opened them for study (I create them with ATL wizard), I can find and open them, but I do not understand what are the differences between _p file and dlldata file -- what are different function they are focused on?
For example, suppose I have an ATL coclass named TestATL1, then _p file I mean TestATL1_p.c and dlldata file I mean dlldata.c,
thanks in advance,
George
|
|
|
|
|
now i want to set the other color(backgroud and foreground color) for one item in the listctrl box?how can i do?
thanks
|
|
|
|
|
|
|
Hello everyone,
When making outgoing calls to other apartment in STA, the owner thread of
STA is not blocked and continue to do message pump, it is the RPC thread
(which is responsible for sending marshalled result to destination apartment)
is blocked? Is my understanding correct?
thanks in advance,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
