C / C++ / MFC

Re: How could I get the parent of an embedded control generically ?

17-Aug-08 19:08

SherTeks wrote:
So, I am looking for a solution that is generic, to find the parent.

If I understood your question properly...

Define a message for your parent class, for e.g. WM_TEST_FN. So all the parent needs to do is define a handler for this message. So if the handler is there then the function will be called.

So then you can use SendMessage to send this message.

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

Naveen17-Aug-08 19:13

Re: How could I get the parent of an embedded control generically ?

17-Aug-08 19:13

ok. You won this time Frown | :(

nave

[OpenedFileFinder]

Nibu babu thomas17-Aug-08 19:16

Re: How could I get the parent of an embedded control generically ?

17-Aug-08 19:16

Naveen wrote:
ok. You won this time [Frown]

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

SherTeks17-Aug-08 19:28

SherTeks

17-Aug-08 19:28

Thanks for your reply.

May be I need to make my question a bit more clearer.

Just assume that my dialog application has 2 controls : 1) a Combo Box and 2) another container control similar to
combo box (but not exactly combo box).

The common trait between the two controls is that they both embed the list box object derived from CListBoxEx.

Now, I could right-click on any one list box at a particular point of time during run-time.

The right-click would bring the control to the OnContextMenu of CListBoxEx::OnContextMenu. In this place, I should be
able to identify the parent ie. either control 1) or 2) using GetParent(). But the only condition is that I shouldn't
cast the pointer returned by GetParent() to any of the parent control pointers ie. GetParent()->TestFn() must call
the TestFn() member function of the appropriate control of which the list box was right-clicked.

Thanks

Re: How could I get the parent of an embedded control generically ?

Nibu babu thomas17-Aug-08 19:59

Re: How could I get the parent of an embedded control generically ?

17-Aug-08 19:59

SherTeks wrote:
But the only condition is that I shouldn't
cast the pointer returned by GetParent() to any of the parent control pointers ie. GetParent()->TestFn() must call
the TestFn() member function of the appropriate control of which the list box was right-clicked.

Well you don't need any casting right if you are using messages. Take a look...

GetParent()->SendMessage( WM_TEST_FN, SomewParam, SomelParam );

Now all the parent class needs to do is add a message map entry to handle this event.

BEGIN_MESSAGE_MAP(...)
ON_MESSAGE( WM_TEST_FN, TestFn)
END_MESSAGE_MAP()

TestFn signature should look like this...

LRESULT TestFn( WPARAM wParam, LPARAM lParam );

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

SherTeks17-Aug-08 21:59

SherTeks

17-Aug-08 21:59

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) 
{
/* The GetParent() here returns CTempWnd * (obtained while debugging).
     I am expecting the return pointer to be of type CSubClassedComboBox
     bcoz the subclassed combo box of type CSubClassedComboBox is the
     list box's parent */
	GetParent()-&gt;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) 
{
/* The GetParent() here returns CSubClassedComboBox * (obtained while debugging) which is correct and is the expected result. */
	GetParent()-&gt;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

Re: How could I get the parent of an embedded control generically ?

Naveen17-Aug-08 19:11

Weird stack corruption problem

17-Aug-08 19:11

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.

nave

[OpenedFileFinder]

jozsurf17-Aug-08 18:11

17-Aug-08 18:11

...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!

Naveen17-Aug-08 18:22

17-Aug-08 18:22

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.

nave

[OpenedFileFinder]

Stephen Hewitt17-Aug-08 18:24

17-Aug-08 18:24

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

jozsurf17-Aug-08 18:33

17-Aug-08 18:33

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..

Stephen Hewitt17-Aug-08 18:36

17-Aug-08 18:36

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

jozsurf17-Aug-08 19:45

17-Aug-08 19:45

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...

Stephen Hewitt17-Aug-08 19:57

17-Aug-08 19:57

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

jozsurf17-Aug-08 20:23

17-Aug-08 20:23

Possibly. At least I have a starting point with which to start looking into this now. Thanks!

Nibu babu thomas17-Aug-08 18:52

17-Aug-08 18:52

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. Smile | :)

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

Stephen Hewitt17-Aug-08 19:49

17-Aug-08 19:49

This is a nasty problem that can be hard to diagnose. Technically it's a violation of the One Definition Rule[^].

Steve

jozsurf17-Aug-08 19:55

Do I need call CString::Empty?

17-Aug-08 19:55

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!

fantasy121517-Aug-08 17:27

fantasy1215

17-Aug-08 17:27

code:

CString myfunc()
{
    return CString(_T("a string"));
}
CString myfunc2()
{
    return CString(_T("a string2"));
}

int _tmain(void)
{
    CString tempStr(_T("hello"));
    
    tempStr.Empty();   //Do I need to call this? Or can I ormit this step?
    tempStr= myfunc();

    tempStr.Empty();
    tempStr = myfunc2();
}

Naveen17-Aug-08 17:46

17-Aug-08 17:46

No need..

nave

[OpenedFileFinder]

fantasy121517-Aug-08 17:54

fantasy1215

17-Aug-08 17:54

Thanks. Before I alway do in this manner, now I clear my mind!

Naveen17-Aug-08 18:01

17-Aug-08 18:01

you could have step into the MFC source code and clear you mind.

nave

[OpenedFileFinder]

ThatsAlok19-Aug-08 20:34

ThatsAlok

19-Aug-08 20:34

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>

nul2629-Sep-10 22:34

nul26

29-Sep-10 22:34

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.Empty ();
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 :.=-..__)