C / C++ / MFC

Re: Resizing a WPF Window that is a child to a CView

7-Oct-11 4:47

Yes, I understood that. I have already downloaded and run your code and already saw the behavior of the "child wpf" when you resize the WPF embedded window.

You are correct that the code I posted will "maximize" the WPF window.

Like I said I think the answer is that you have to do something in WPF to make it work. Hence my posting with a link to the resizing WPF code.

If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun

nadine123458-Oct-11 9:09

nadine12345

8-Oct-11 9:09

Thank you again Ahmed Smile | :)

I read the article you sent me, and it seems they are trying to intercept the window messages so they can handle the Resizing event and not just the SizeChanged (to catch the message before the size is changed). I was able to do as the sample described, I just cannot find a workaround to fix my problem. I hope anyone can give me a hint.

Thank you for your time Smile | :)

Re: Resizing a WPF Window that is a child to a CView

TheGreatAndPowerfulOz18-Oct-11 7:33

How do you const your references?

18-Oct-11 7:33

here some info that might help you
WPF and Win32 Interoperation[^].

It has a section titled "Hosting WPF Content in a Microsoft Win32 Window". MFC is just a "light" wrapper around Win32.

And here's someone's blog about MFC and WPF Interop[^]

I found these by googling for wpf interop[^]

User 5838525-Oct-11 18:35

User 583852

5-Oct-11 18:35

For years I've written

const Blah& b = GetMyBlah();

I was taught to read these right to left - ie a reference to a Blah which is const.

A colleague has pointed out that this is in fact incorrect as the const key word is left associative but most compilers allow it (gcc, intel, clang and VC in my case). So it should be written

Blah const& b = GetMyBlah();

When read right to left it's a reference to a const Blah - same thing.

He pointed me to the parashift c++ faq http://www.parashift.com/c++-faq-lite/[^] which was changed recently to put the const between the type and the reference.

Obviously pointers are different as both the pointer and the object pointed to (or both) can be const while a reference is always const.

modified 10-Oct-11 5:18am.

Stefan_Lang6-Oct-11 0:53

6-Oct-11 0:53

You're correct, both variants mean exactly the same thing. Whether you write const before or after the type is meaningless and just a matter of style - the latter variant may be a little clearer with respect to the rule of reading types right to left though.

If you wanted to express that your reference is const, then you could place const to the right of the reference operator, like this:

C++

Blah const& b const = GetMyBlah(); // const reference to a const Blah

However, as Herb Sutter points out (see point 13), this extra const is meaningless since references are always const. Therefore the extra const is usually omitted.

TheGreatAndPowerfulOz6-Oct-11 5:55

6-Oct-11 5:55

Good answer Stefan.

So I was trying out some stuff and I was surprised that the VC++ 2010 compiler gave me an error on the second of these saying that void GetBlah2(const Blah*) already has a body.

void GetBlah2(Blah const * blah) { } // #1 method taking pointer to const Blah
void GetBlah2(Blah const * const blah) { } // #2 method taking const pointer to const Blah

Yet I am able to declare these variables with the expected meaning:

const Blah* blah1 = new Blah(); // pointer to const Blah
Blah const * const blah2 = new Blah(); // const pointer to const Blah

Is this a bug in the compiler or is such a method (#2 above) disallowed by the C++ standard?

Stefan_Lang6-Oct-11 6:09

6-Oct-11 6:09

In the first function you passed a pointer, not a reference, and you passed that pointer by value. Passing a parameter of type X by value is the same as passing the same parameter as type const X - at least from the point of view of the caller - therefore the declaration of your second function is syntactically the same as the first (again, from the point of view of the caller). The compiler cannot disambiguate any calls to this function into one of the two versions, therefore it does not allow you to overload like that. Follow the link to GOTW I've posted above, IIRC that this was also covered there. In short, if you pass a parameter by value, you cannot overload it only by adding const to that type.

If you meant to pass your pointer by reference, do it this way (using underscore to highlight the change):

C++

void GetBlah2(Blah const *& blah) { } // #1 method taking pointer to const Blah
void GetBlah2(Blah const * const blah) { } // #2 method taking const pointer to const Blah

This should work.

TheGreatAndPowerfulOz6-Oct-11 6:37

6-Oct-11 6:37

I see. Your reply makes sense. It's like trying to declare a const reference (Blah & const). It's redundant.

Stefan_Lang6-Oct-11 6:48

6-Oct-11 6:48

Not quite. In case of a reference there really is no difference as there is no such thing as a non-const reference. In your example however there would be a difference, but it would only be visible within the code of your function: there, if you defined the parameter const, you could not modify it (locally), whereas if you didn't define it const you could. Of course, since you pass it by value the caller wouldn't notice the difference, basically you gain an additional local variable by not declaring it const.

C++

const Blah* GetBlah1(const Blah*& const b) {
   b = 0; // error: you cannot modify a const reference!
   return b;
}
const Blah* GetBlah2(const Blah*& b) {
   b = 0; // error: you cannot modify a reference, as it's always const!
   return b;
}
const Blah* GetBlah3(const Blah* const b) {
   b = 0; // error: you cannot modify a const pointer
   return b;
}
const Blah* GetBlah4(const Blah* b) {
   b = 0; // ok
   return b;
}
int main() {
   Blah* a = new Blah;
   Blah* b = GetBlah4(a); // this does not modify a
   assert(b==0);
   assert(a!=0);
   delete a;
   return 0;
}

TheGreatAndPowerfulOz6-Oct-11 7:07

6-Oct-11 7:07

I copied your code into VC++ 2010 and the first two errors do not occur.

Stefan_Lang wrote:

const Blah* GetBlah1(const Blah*& const b) {
   b = 0; // not an error: you're assigning a new pointer value to b which will survive once returning from the method
   return b;
}
const Blah* GetBlah2(const Blah*& b) {
   b = 0; // not an error: again you're merely assigning a new pointer to b which will survive once returning from the method
   return b;
}

Also, this line gets an error because you can't assign a const value to a non-const value:

Stefan_Lang wrote:

Blah* b = GetBlah4(a); // this does not modify a

Anyway, thanks for your help. I understand I think.

Stefan_Lang6-Oct-11 22:07

6-Oct-11 22:07

Ah, my bad, you are right in all three cases: in the first functions the assignments don't change the reference, only the value they reference. So these examples were not valid for the purpose I wanted to demonstrate. Also, when I tried to compile GetBlah1() I got the warning warning C4227: anachronism used : qualifiers on reference are ignored. This leads me to believe that it is not actually possible to pass a parameter by const reference, and the rightmost const in the signature is ignored, therefore b is not const and may be modified. I wasn't aware of that restriction before.

The function call to GetBlah4() doesn't work because it tries to assign the (const) return value to a non-const variable. Add a const at the start of the line and it should work.