(try using unique_ptr for automatic cleanup without handwriting copy constructors/operators and destructors)

class App {
public: //people reading headers usually care more about the public section, so I usually put it on top
  App(); //ctors are for initialization - exceptions are for error handling
  ~App();
  //There should probably be other methods here, or else something is very wrong.
private:
  ProjectWizardWindow wizWnd; //avoid using pointers when you don't need to
  MainWindow mainWnd; //ctor args for these objects can be passed in the initializer list of App::App()
};

App::App() : wizWnd(640, 480) {
  //ctor body
}

App::App(int wizwinx, int wizwiny) : wizWnd(wizwinx, wizwiny) {}

App::App() : wizWnd(arg, arg), mainWnd(arg, arg, arg) {
  //stuff (or - more often - nothing, since you can often do everything in the list ^)
}

I'll offer my own meandering, unfocused critique / best-practices-grab-bag -- but before I do that, I'll make a caveat that if you're doing this for a class and your instructor expects a certain way of doing things, then its best to simply do things in the format she or he expects. What they want may not always be important or good practice, but your time is ultimately better spent by learning rather than fighting 'the man' -- so without further ado...

As others have pointed out, you seem to be doggedly following some notion of Hungarian notation that was popularized in the Windows Programming books of the 90s. There's no good reason to do this. In fact, the form of Hungarian notation that was popularized where the lower-case prefixes denoted type information was wrong from the start: proper Hungarian notation didn't encode type information, but was meant to encode how the data was to be interpreted. For example, you wouldn't have 'fAngle' to mean that this variable was an angle stored in a float, but you might have something like 'radAngle' to denote that this variable stored an angle in radians, rather than degrees. I would argue that neither is a particularly good name, though; 'radians' alone would suffice, and something more descriptive like 'radianChangeToTarget' would be even better.

It's also worth noting that Hungarian notation really was a C-ism. C++ has the concept of classes, and that allows you to encode both variable type and variable usage formally. Hungarian notation was a way to informally encode this kind of information into the variable name, in the hope of helping the programmer not make mistakes. In C++, the better tools that classes provide are there so that the compiler can prevent the programmer from making silly type mistakes -- you can imagine that the compiler is much better at this than we meatbags are.

Continuing on the naming conventions, it is good to have and to follow one. But the particular one is a matter of individual preference (or group preference, when working together). In Java and C# the general conventions are laid out in language style guides, and are mostly followed by the community at large, so its best to stick to those. In C++ (and C) many more 'canonical' styles evolved such that there is no credible candidate for which is "the one true style". In the C and C++ world, many companies and projects have their own styleguides that borrow liberally from generally-agreed-upon practices, but adhere also to a particular mix of the less-agreed-upon-practices, so you see lots of style guidance 'families' that overlap 80-90%. My observation is that there are two predominant families -- you have the classic family that encompasses things like K&R-style C, Stroustrup, and the C++ standard library (e.g. identifiers_with_underscores), and then you also have a younger family who's style is inspired by Java and C# (e.g. CClassName, variablesInCamelCase). My own maxim is "do as the standard library does" (although you should not use things like leading underscores that it prohibits for good reason) -- I find that not only is this style familiar to everyone, but also that the standard library has already encountered every strange corner case and provides examples of how to handle all of them, so I don't have to expend brain-cells coming up with my own way. For yourself, pick one and be consistent -- I see you mixing styles here in a way I'd characterize as inconsistent (e.g. your use of casing).

Drop the leading underscores -- use of single leading underscore is prohibited by the standard for external identifiers, some 'clever' individual started using it for their member functions and member variables since those things are not (unqualified) externals, but its still confusing while reading code, and I imagine can still cause overload resolution conflicts within a member function body (or if not conflicting for the compiler, certainly confusing for you, humble programmer). The standard also prohibits all identifiers that use a double leading underscore, or a single leading underscore followed by a capital letter, for all uses internal and external. All of this is so that the library and header files can define functions, variables, and macros for internal purposes without risk of conflict with names in user programs.

Do use std::unique_ptr when you have a variable that singularly-owns a resource. It makes your code shorter and more readable when you don't have a bunch of extra resource-freeing code in your destructors (and in many cases, unique_ptr makes it so you don't have to write a custom destructor at all), and is also much safer in the face of an exception, where your custom resource-handling code might be skipped and resources leaked.

But when you can, prefer to avoid pointers whenever you can. Prefer values first, references second, and an appropriate pointer type third. When you must resort to a pointer, use std::shared_ptr for objects who are (or potentially are) co-owned by more than one entity, use std::unique_ptr for objects who are only owned by one entity at a time (ownership can be transferred to another entity, but never co-owned), and use a raw pointer for referencing an object that you are taking no ownership of (in other words, use raw pointers when someone else aready owns the object, and you know that the owner will keep it around for longer than you need it here. Also, don't use unique_ptr or shared_ptr types as parameters just to pass what's pointed to, only use them as parameters when you mean to (potentially) change or add to its owner(s).

'initialize' member functions are a code-smell, and usually a sign that your design is not properly adhering to RAII, and/or that you have some weird inversion of relationships that's causing you to not have all the information you need to initialize an object at once -- sometimes the latter case also indicates that the object lives in the wrong scope, or that you might have a kind of cyclical relationship between it and another object. Sometimes having an initialize method that's not the constructor is justifiable, but I'd say that about half the time I see it used its employed as a kludge and indicates the kind of problems I've written about here.

To end on a positive note, I'll say that one thing I see you doing *right* is that you haven't utilized any unnecessary inheritance. It's not uncommon to see a green programmer doing something like having their "Application" class derive from their "MainWindow" class (or vice versa).

OP, aside from the code formatting issues, what you're looking for is an event listener system. You could create your own (ala alnites suggestion) or you could use a "signals and slots" library such as Boost.Signals .

The idea behind these is to decouple your event handler from the event source.