Carl said:
I assume you're talking about Windows Forms designer generated classes?
Yes, I assume that's what the original poster meant.
Personally, I wouldn't expect that to ever change - but who knows
The
problem is, the designers are not maintained by the C++ team, so getting the
designer to support a separation of declaration/definition requires getting
another group to do work that's of no benefit to their own product.
I realize that, but C++/CLI is claimed to be the primary .NET language.
Changing the designer would obviously benfit Visual Studio as a whole.
Although I'm not sure what percentage of the developers design GUI in
C++/CLI.
Fortunately it's not too hard to move the event handler implementations
to the .cpp file, but it's a major inconvenience. I don't think it would
be too hard to implement that feature (to generate an entry to the
header file as well as the .cpp, as Borland C++Builder does it), and it
would save a lot of time to the developers. I really insist that event
handlers are implemented in the .cpp file.
Moving the InitializeComponent to the .cpp file is a little bit less
important. Yes, it's annoying that moving an edit box around triggers a
recompile to other units, but frankly, most changes to the form do.
Typically when the GUI changes it involves adding new controls, thus new
declarations. Let's face it, most designer changes would trigger a
recompile to other modules anyway.
It would still be appreciated if moving a component, or changing its
color, wouldn't trigger any changes to any header file. It still has
much less impact than the event handlers.
At least this issue with monolithic header files enforces developers to
consider the separation of the GUI from the business logic, which I
personally support even in smaller projects, except maybe in quick and
dirty prototypes. The rest of the application logic should not depend on
the implementation of a particular component. Let's say a year into the
development you change from list box to list view, or from a Microsoft
component to a 3rd party with a different interface. It's definitely not
nice if such a change requires the editing of 100 function calls and
property references all across the project. So it's probably safe to say
that if the designer's inability of maintaining a separate .cpp file
causes enormous dependency issues, the project itself has architectural
issues. I tend to wrap forms into form managers, and the majority of the
code interacts with the form manager, without even including the forms'
header file.
Tom
