C++ – Using SubclassDlgItem to change control types

cmfcuser interface

I have a C++ MFC app with a dialog where I want to change the type of the control dynamically based on the selection in a combo box. The dialog resource starts off with a plain old edit control which I then call SubclassDlgItem on to change to a custom control type.

So far so good. Now, when the user changes the selection in a different Combobox on the screen, I want to change this control to a different custom type. So, I destroy the existing control by calling delete on the pointer to the custom class for that control. I then call ::CreateEx to re-create my edit control and call SubclassDlgItem again to create the new custom control.

My problem is that this flickers quite a bit, and I think I'm getting the edit control created with ::CreateEx on top of my custom control. Any ideas on how to get rid of the flicker, especially if the user is quickly changing the contents of the controlling combo box?

Best Answer

You can create a set of all possible controls in the same area of the parent window and show only the relevant one and hide all the others. When the user causes the control change you hide the active control and show the new relevant. This should look smoother.

Related Solutions

C++ – What are POD types in C++

POD stands for Plain Old Data - that is, a class (whether defined with the keyword struct or the keyword class) without constructors, destructors and virtual members functions. Wikipedia's article on POD goes into a bit more detail and defines it as:

A Plain Old Data Structure in C++ is an aggregate class that contains only PODS as members, has no user-defined destructor, no user-defined copy assignment operator, and no nonstatic members of pointer-to-member type.

Greater detail can be found in this answer for C++98/03. C++11 changed the rules surrounding POD, relaxing them greatly, thus necessitating a follow-up answer here.

C++ – Why is “using namespace std;” considered bad practice

This is not related to performance at all. But consider this: you are using two libraries called Foo and Bar:

using namespace foo;
using namespace bar;

Everything works fine, and you can call Blah() from Foo and Quux() from Bar without problems. But one day you upgrade to a new version of Foo 2.0, which now offers a function called Quux(). Now you've got a conflict: Both Foo 2.0 and Bar import Quux() into your global namespace. This is going to take some effort to fix, especially if the function parameters happen to match.

If you had used foo::Blah() and bar::Quux(), then the introduction of foo::Quux() would have been a non-event.

Best Answer

Related Solutions

C++ – What are POD types in C++

C++ – Why is “using namespace std;” considered bad practice

Related Topic