By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,466 Members | 1,309 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,466 IT Pros & Developers. It's quick & easy.

Why should I write code in header file in VC++.Net winforms?

P: n/a
Hi,

In VC++.Net 2005 visual studio, if I create a new winform drag and drop
a button, then double click it to write click event code, then it auto
generates the template code for the event in Form1.h file rather than
Form1.cpp file. This behaviour is against standard C++ coding
standards, where my header file is supposed to just have declarations.
I read in other topics that this is due to C# association of single
file concept with the winform.

Can someone (from MS or MS experts) explain why is this done? and how
can I avoid it to generate template code in header file and write my
code in .cpp file?

Thanks and Regards,
Shil

Feb 4 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Shil wrote:
Hi,

In VC++.Net 2005 visual studio, if I create a new winform drag and
drop a button, then double click it to write click event code, then
it auto generates the template code for the event in Form1.h file
rather than Form1.cpp file. This behaviour is against standard C++
coding standards, where my header file is supposed to just have
declarations. I read in other topics that this is due to C#
association of single file concept with the winform.

Can someone (from MS or MS experts) explain why is this done? and how
can I avoid it to generate template code in header file and write my
code in .cpp file?


That's the way the designers work. You can adapt to that style or not use
the designer - there's little other choice. The designers were designed for
C# and VB and don't support the header/implementation file idiom commonly
used for C and C++ programming.

-cd
Feb 4 '06 #2

P: n/a
This might exist, but I'm looking for that cross between a console project
and a winform project. That is, I want to be able to create a C++.NET
application that starts by not showing EITHER a console or a form. I want to
be able to build my own form from 'scratch' (derived from Form), but not
have to start with a blank project. Something that sets up a 'hello world'
but doesn't actually put 'hello world' anywhere since no default output
screen is defined.

This use to exist in 2003 by virtue of the fact that if you started a
console project you could later on (or early on) disable the console.
Apparently nowadays if you start a console project you must have a console,
and if you start a winform project you must use the visually-oriented
(drag-and-drop controls) Form.

Mind you, I think the drag-and-drop paradigm is great, I just wish I didn't
have to use it if I don't want a console as part of the deal. I like to
create my own custom Forms, and dislike it when the language writes
automatic code for me (and places it in a "do not touch" area of the
source). I'm sure this is possible, and my igorance is raising it's ugly
head again...

[==P==]

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:%2****************@TK2MSFTNGP11.phx.gbl...
Shil wrote:
Hi,

In VC++.Net 2005 visual studio, if I create a new winform drag and
drop a button, then double click it to write click event code, then
it auto generates the template code for the event in Form1.h file
rather than Form1.cpp file. This behaviour is against standard C++
coding standards, where my header file is supposed to just have
declarations. I read in other topics that this is due to C#
association of single file concept with the winform.

Can someone (from MS or MS experts) explain why is this done? and how
can I avoid it to generate template code in header file and write my
code in .cpp file?


That's the way the designers work. You can adapt to that style or not use
the designer - there's little other choice. The designers were designed
for C# and VB and don't support the header/implementation file idiom
commonly used for C and C++ programming.

-cd

Feb 6 '06 #3

P: n/a
Mind you, I think the drag-and-drop paradigm is great, I just wish I
didn't
have to use it if I don't want a console as part of the deal. I like to
create my own custom Forms, and dislike it when the language writes
automatic code for me (and places it in a "do not touch" area of the
source). I'm sure this is possible, and my igorance is raising it's ugly
head again...


If you create a Form project and examine its code,
you'll see that there is nothing there that you cannot type in yourself.
Code generated by MFC wizards can be a bit obscure, but .NET forms code is
plain to read.
If you want to code that stuff by hand there is nothing to prevent you form
doing so.
You can then use your own form as the startup form.

If you don't want to start from the form that is generated for you if you
create a new forms project,
just throw it away and provide your own form.

--

Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"
Feb 6 '06 #4

P: n/a
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
This might exist, but I'm looking for that cross between a console project
and a winform project. That is, I want to be able to create a C++.NET
application that starts by not showing EITHER a console or a form. I want
to be able to build my own form from 'scratch' (derived from Form), but
not have to start with a blank project. Something that sets up a 'hello
world' but doesn't actually put 'hello world' anywhere since no default
output screen is defined.
<fwiw>
Well, there is always a tradeoff between flexibility and ease of use. The
wizards limit flexibility to some extent to make the _most_ frequent tasks
easy. It's rarely easy to get a wizard to anything but what it knows best.
</fwiw>
This use to exist in 2003 by virtue of the fact that if you started a
console project you could later on (or early on) disable the console.


Hmm, really? In my experience console projects always have consoles. The
only "exception" I know of is the case of a console process created via
CreateProcess() with the CREATE_NO_WINDOW or DETACHED_PROCESS flags. In
other cases the o/s, the command shell and the runtime conspire to create a
console.

Though I'm not sure it will, I hope the rest of this post will help you. :-)

I started with a sample I put together for you some time ago that created a
..Net WinForms application without the wizard. The goal then was to
demonstrate a little drawing under .Net.

I've modified it so that it takes a single parameter. If it finds the string
"window" on the command line it creates a form. If it does not it will use
its parent's console or create a new one if its parent doesn't have one.

The sample is actually a Win32 application, compiled with the /CLR switch
linked as a windowed application ( /Subsystem:Windows ).

This is its header file:

//---------------------------------------------------------
#include <string>

#using <System.dll>
#using <mscorlib.dll>
#using <System.Drawing.dll>
#using <System.Windows.Forms.dll>

using namespace System;
using namespace System::Drawing;
using namespace System::Windows::Forms;
using namespace System::ComponentModel;
using namespace System::Runtime::InteropServices;

[ DllImport("KERNEL32.dll", EntryPoint="AllocConsole",
CallingConvention=CallingConvention::StdCall) ]
extern "C" unsigned short int AllocConsole(void);

[ DllImport("KERNEL32.dll", EntryPoint="AttachConsole",
CallingConvention=CallingConvention::StdCall) ]
extern "C" unsigned short int AttachConsole(int);

public __gc class HelloWorld : public Form
{
public:

HelloWorld();
static void Main();
static void Main2();

protected:

void OnPaint(PaintEventArgs __gc *);
void OnResize(EventArgs __gc *);
};
//---------------------------------------------------------
This is its source file:

//---------------------------------------------------------
#include "po.h"

void HelloWorld::Main()
{
Application::Run( new HelloWorld() );
}

void HelloWorld::Main2()
{
if ( AttachConsole(-1) == 0 )
AllocConsole();

Console::WriteLine("Hello, world!");
}

HelloWorld::HelloWorld()
{
Text = "Hello, world!";
BackColor = Color::White;
}

void HelloWorld::OnPaint(PaintEventArgs *pea)
{
Graphics __gc *grfx = pea->Graphics;
Rectangle rc;

grfx->DrawString("Hello, World!", Font, Brushes::Black, 0, 0);

rc = get_ClientRectangle();
rc.Width -= 1;
rc.Height -= 1;

grfx->DrawLine(Pens::Red, 0, 0, rc.Width, rc.Height);

grfx->DrawEllipse(Pens::Blue, rc);
}

void HelloWorld::OnResize(EventArgs *ea)
{
Invalidate();
}

// Hack avoids including <windows.h>

int __stdcall WinMain(int, int, char *pszCmd, int)
{
std::string cmdLine(pszCmd);

if ( cmdLine.find("window") != std::string::npos )
{
HelloWorld::Main();
return 0;
}

else if ( cmdLine.find("console") != std::string::npos )
{
HelloWorld::Main2();
return 0;
}

else
return -1;
}
//---------------------------------------------------------

Feb 6 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.