New to MC++

[Shawn B.]

Greetings,

I'm trying to create a Managed C++ library that extends the console features
beyond System::Console capabilities. I chose MC++ over C++/CLI because I
need it to work on the 1.1 framework. I haven't programmed C++ in years and
I'm very very new to Managed C++. Thus, I'm having issues getting even the
simplest thing to work, and not for the fact, that finding good information
about using API calls and such from within a managed class isn't as easy to
find as I thought it would be.

In particular, my true lack of understanding is this: I have a __gc class.
I'm using win32 api. So I need to pass a native struct into a native method
call. Do I need to do anything special at this point, such as mark it __gc*
or something?

The following code won't compile. Was wondering if anyone could explain how
to make it compile. I marked the offending line of code with a comment.
Search for "Compile error"

* common.h
* console.h
* console.cpp
* stdafx.h


common.h
--------
#pragma once
#if !defined (common_h)
#define common_h

// .NET Access Modifiers
//
#define PUBLIC public public
#define PROTECTED public protected
#define PRIVATE private private
#define INTERNAL private public


#endif // !defined (common_h)
--------


console.h
--------
#pragma once

using namespace System;


namespace Test
{
public __gc class Console
{
PUBLIC:
PROTECTED:
PRIVATE:
const static byte EMPTY = 32;
const static int CAPTION_LENGTH = 1024;

static HANDLE hConsoleOutput; // handle to output buffer
static HANDLE hConsoleInput; // handle to input buffer
static int OriginalConsolePen;
static int CurrentConsolePen;

static CONSOLE_SCREEN_BUFFER_INFO ConsoleInfo;
static COORD ConsoleOutputLocation;



public:
static void Clear();


};
}
----------


console.cpp
----------
// This is the main DLL file.

#include "stdafx.h"

#include "console.h"


namespace Test
{
void Console::Clear()
{
DWORD chars = 0;

CONSOLE_SCREEN_BUFFER_INFO info;
COORD home;

home.X = 0;
home.Y = 0;

CONSOLE_SCREEN_BUFFER_INFO consoleInfo;

hConsoleInput = GetStdHandle(STD_OUTPUT_HANDLE);
GetConsoleScreenBufferInfo(hConsoleOutput, &consoleInfo); // <-- Compile
error happens here

if (GetConsoleScreenBufferInfo(hConsoleInput, &info) == 0) {
System::Console::Write(S"\x0c");
return;
}

FillConsoleOutputCharacter(
hConsoleOutput,
EMPTY,
info.dwSize.X * info.dwSize.Y,
home,
&chars
);

FillConsoleOutputAttribute(
hConsoleOutput,
CurrentConsolePen,
info.dwSize.X * info.dwSize.Y,
home,
&chars
);

SetConsoleCursorPosition(
hConsoleOutput,
home
);
}
}
--------


stdafx.h
---------
#pragma once

#include <wtypes.h>
#include <wincon.h>

#include "common.h"

 

[Olaf Baeyens]

I'm trying to create a Managed C++ library that extends the console
features

beyond System::Console capabilities. I chose MC++ over C++/CLI because I
need it to work on the 1.1 framework.

Why restrict yourself to v1.1? Why not use v2.0?

 

[Olaf Baeyens]

Hmmm a question, what do you mean you choose MC++?
You are referring to VC++ 2003? That one uses the .NET framework v1.1

But VS 2005 is going to compile with the .NET framework 2.0, so forcing it
to use only v1.1 is going to give you head-aches.

 

[Shawn B.]

Hmmm a question, what do you mean you choose MC++?

You are referring to VC++ 2003? That one uses the .NET framework v1.1

But VS 2005 is going to compile with the .NET framework 2.0, so forcing it
to use only v1.1 is going to give you head-aches.

It must work with the 1.1 framework because our company isn't moving to 2.0
anytime soon. When we do, it'll still compile with Visual C++ 2005, but we
can then rewrite it against C++/CLI as we see fit (usually we're about 18
months behind when it comes to rewriting anything for a specific new
technology even though we'll adopt the technology much sooner (6 months) all
we do is migrate the code and not do much changes otherwise for existing
code). But, if I write it in C++/CLI first, it won't be source-code
compatible with a compiler that will target the 1.1 framework.

I hope I didn't give the impression I was using 2005, I'm using VS.NET 2003
for now. I'm well aware of the different IDE's targeting different
runtimes. But using the 2005 IDE right now isn't an option for this
project.



Thanks,
Shawn