.NET newby: IDE query

  • Thread starter Thread starter Arnold the Aardvark
  • Start date Start date
A

Arnold the Aardvark

I'm completely new to .NET, but not C++, and have
bought VC++ .NET to learn with. I've created a
minimal GUI application to get started.

My first question is a simple one about the IDE. Why
is all the code generated in the header? Is this an
option I can turn off?

It seems to me that this code organisation is not
mandated by anything I have learned so far about
..NET. Perhaps it seems a small thing to C# and Java
developers, but I prefer to separate the interface
from the implementation. Call me old-fashioned...

Thanks.


Arnold the Aardvark
 
Arnold said:
I'm completely new to .NET, but not C++, and have
bought VC++ .NET to learn with. I've created a
minimal GUI application to get started.

My first question is a simple one about the IDE. Why
is all the code generated in the header? Is this an
option I can turn off?

It seems to me that this code organisation is not
mandated by anything I have learned so far about
.NET. Perhaps it seems a small thing to C# and Java
developers, but I prefer to separate the interface
from the implementation. Call me old-fashioned...
Click to expand...

You are not the first to notice that the C++ wizards generate all code in
the header file. They are just mimicking C#, for which code goes in a
single file and all implementations are inline. I believe you can manually
separate code into headers and source files, as you like, without confusing
the IDE.
 
Edward said:
You are not the first to notice that the C++ wizards generate all code in
the header file. They are just mimicking C#, for which code goes in a
single file and all implementations are inline. I believe you can manually
separate code into headers and source files, as you like, without
confusing the IDE.
Click to expand...

What a kludge! To M$: Were any actual C++ developers involved in creating
this tool?!

As for confusing the IDE I renamed two components (a ListView and
a Toolbar), and the pointer declarations went missing from the
generated code, so it wouldn't compile. Is this a known bug?

Thanks.


Arnold the Aardvark
 
Arnold said:
What a kludge! To M$: Were any actual C++ developers involved in
creating this tool?!
Click to expand...

AFIAK, no. The WinForms wizard was built by the C#/VB.NET team(s) and
adapted to C++. That was the best they could do with the available time and
resources. I believe this aspect will change in Whidbey (VS 2004), since C#
will support "partial classes".
As for confusing the IDE I renamed two components (a ListView and
a Toolbar), and the pointer declarations went missing from the
generated code, so it wouldn't compile. Is this a known bug?
Click to expand...

Probably.

If you want to rename a WinForms object, be sure to do it from the
Properties window, not by editing the source code directly. That way the
designer will keep track of everything properly.

-cd
 
Carl said:
AFIAK, no. The WinForms wizard was built by the C#/VB.NET team(s) and
adapted to C++.
Click to expand...

That's what I figured, and then I thought that surely not even M$ would
be this dumb/arrogant/whatever. Heaven help us all...

Partial classes sound weird. Who owns the class? Can anyone add new methods
to a class in a library written by someone else? I suspect they will create
more problems than they solve.
If you want to rename a WinForms object, be sure to do it from the
Properties window, not by editing the source code directly. That way the
designer will keep track of everything properly.
Click to expand...

That's what I did. Ho hum. And how about renaming the form itself? The
generated source contained a dire warning about this, whereas in C++
Builder or Delphi one simply types in the new name, as with the other
components, so it is obviously not beyond the wit of Man.

Thanks.


Arnold the Aardvark
 
Hi Arnold,
Partial classes sound weird. Who owns the class? Can anyone add new methods
to a class in a library written by someone else?
Click to expand...

Nope. Partial classes is entirely a compiler implemented feature, requiring
no support from the runtime, as I understand it. This means the compiler
must be able to see all parts of a partial class at compilation, which means
it only works on pieces of a class in the same assembly/module... you can't
"extend" a class existing on a compiled assembly already this way.
I suspect they will create
more problems than they solve.
Click to expand...

Not necessarily. I believe their biggest use is going to be as a way to
extend classes generated by code-generating tools such as xsd.exe, the
designer, asp.net, wsdl.exe, and so on...
 
Not necessarily. I believe their biggest use is going to be as a way to
extend classes generated by code-generating tools such as xsd.exe, the
designer, asp.net, wsdl.exe, and so on...
Click to expand...

You may be right, but it seems to me that the tools should be designed to
fit the language specification, rather than the reverse. I guess I'm what
you might call a bit old-fashioned.


Arnold the Aardvark
 
Arnold said:
You may be right, but it seems to me that the tools should be
designed to fit the language specification, rather than the reverse.
I guess I'm what you might call a bit old-fashioned.
Click to expand...

That's true. It's also useful to be able to have the machine-generated part
of a class 100% isolated from the human-maintained part of the class.
Typically the machine-generated part will not be in source control (some
meta-data item, like an XML file will be instead) while the human-created
part would be in source control.

-cd
 
Back
Top