VC++6 & .NET

[Mave]

Hello.... i have got this question about .NET and VC6

we all know the VC6 uses MFC. i installed VS.NET 2003 and i opened VC++.NET and found one of the projects types as MFC application

so if i wanted to learn VC++6 before .net and then do MFC with .NET, will there be any differance between both

i mean whats new in VC.NET MFC app and VC6 MFC app apart from the namespaces?

[+John Teacake MVC]

Might be .NET has managed code, Not sure though, Dont quote me on that one.

[John Veteran]

Visual Studio .NET can create several types of C++ projects, including managed, MFC, and Win32. Win32 is the C++ code you'll use with most of the C++ self-teaching books out there. MFC, you know what that is if you're talking about it. Finally, .NET code is managed C++ that runs on the .NET framework, like C# and VB.NET (Y)

[Mave]

so in VC++.NEt IDE there is nothing differant in an MFC application and one made with VC++6... is that what you mean game guy?

[smurfiness]

so in VC++.NEt IDE there is nothing differant in an MFC application and one made with VC++6... is that what you mean game guy?

Yeah, there's really not a whole lot of difference. Some things got shuffled around, and there are fixes and updates, but there is no substantial difference.

[nowimnothing]

so in VC++.NEt IDE there is nothing differant in an MFC application and one made with VC++6... is that what you mean game guy?

There are some data type differences, but its mostly some minor things (nothing that a few minutes of searching couldn't figure out if yo get an error when moving a project from VS6->VS.NET.

I also believe, though i'm not positive on this, that there's a push by the Microsoft dev. people to combine the MFC and ATL stuff into one collection of objects instead of two. I think this can be seen if you go and look at the included libraries and include files and compare them between what comes with VS6 and VS.NET.

I remember running into a few issues on a VERY large MFC app we moved from VS6 to VS.NET that were related to this combination of MFC/ATL and there was some info in the documentation about it - though i don't remember where exactly at this point.

[smurfiness]

IIRC, all they're doing is adding some of the MFC easy-use classes (like CString) over to ATL to make it a bit friendlier. That shouldn't affect MFC.

There are some breaking changes in VC++ 7.1 though, that may or may not affect MFC programs. One of the more notables is the absence of the C++ stream classes (ofstream, ifstream, etc). Most of that stuff has to be done through the API now (or by finding the old .h and .cpp files, which won't necessarily work).

[nowimnothing]

hrm. i could swear there was more to it than that.

oh well, wouldn't surprise me if i was wrong :)

if i run across anything again that relates to what i was talking about, i'll post it.

[azcodemonkey]

Changes from VC++ 6 to VC++.NET for MFC

Reference topics for MFC contain hundreds of new code examples.

Static Casting and MFC Message Maps  Beginning with Visual C++ .NET, MFC provides stricter type checking for return and parameter types of message handler functions. This new behavior notifies the developer of potential problems by flagging potentially unsafe message handlers with an error message. MFC now uses static casts for ON_MESSAGE, ON_REGISTERED_MESSAGE, ON_THREAD_MESSAGE, and ON_REGISTERED_THREAD_MESSAGE.

For example, in the past a developer could use a member function that returned void instead of LRESULT for ON_MESSAGE or ON_REGISTERED_MESSAGE and compile without any errors. With Visual C++ .NET, the potential miscast is caught and flagged as an error. The developer can fix the potential problem by replacing the return type (with LRESULT) and recompiling.

DHTML editing component: CHtmlEditCtrl, CHtmlEditView, CHtmlEditDoc

DHTML dialog boxes: CDHtmlDialog, CMultiPageDHtmlDialog

ISAPI support for parsing argument lists: CHttpArg, CHttpArgList

Support for windowless controls: COleControlSite, COleControlContainer, and COccManager

Enhanced support for using HTML Help in an MFC application: Displaying the Help Viewer.

Windows 2000 print property sheet: CPrintDialogEx.

DAO support: The Visual C++ MFC Application Wizard and MFC DLL Application Wizard no longer support DAO database projects. You can still add DAO-derived classes using the Add Class Wizard. Microsoft recommends using OLE DB or ODBC for new native C++ projects. You should use DAO only in maintaining existing applications.

TRACE0, TRACE1, TRACE2, and TRACE3 are now considered obsolete; use ATLTRACE2. TRACE now has the same functionality as ATLTRACE2.

When selecting a dialog box font, use MS Shell Dlg, not MS Sans Serif or Helv fonts. Previous versions of MFC would automatically replace MS Sans Serif or Helv with DEFAULT_GUI_FONT or the system font, but MFC no longer does that. See General MBCS Programming Advice.

Enhanced support for localized resources in satellite DLLs: Localized Resources in MFC Applications: Satellite DLLs.

As far as the stream classes not being there, just change your headers to point to the standard classes ( <iostream> instead of <iostream.h> ), and qualify your usage with the using namespace std; or std::fstream.

Lots of changes to the C-Runtime. Attributed programming was added for COM/ATL. ATL Server is new.

A more comprehensive list:

http://msdn.microsoft.com/library/default....lcversion70.asp

[smurfiness]

As far as the stream classes not being there, just change your headers to point to the standard classes ( <iostream> instead of <iostream.h> ), and qualify your usage with the using namespace std; or std::fstream.

Ah, didn't know that. I remember seeing the "iostreams are deprecated" message in VC 2002, and I figured they were just gone. Dammit, that means I learned how to use ReadFile/WriteFile for nothing. *LOL*

[Mave]

ahh ok then i would rather start learning .net which wont effect my ability to code a progrm with the old one

[Lycander]

Visual Studio .NET can create several types of C++ projects, including managed, MFC, and Win32. Win32 is the C++ code you'll use with most of the C++ self-teaching books out there. MFC, you know what that is if you're talking about it. Finally, .NET code is managed C++ that runs on the .NET framework, like C# and VB.NET (Y)

Win32 is C code, NOT C++. MFC is the C++ wrapper for the Win32 API.

VC++ 6.0 compared to VC++ .Net, not much different. They're both just IDEs and a collection of software development tools (compiler, linker). If you just look at them as simply tools, it doesn't really matter what runtime library/environment you use. Except where .Net is concerned, then the .Net Visual Tools are required.

Also note that if you want to write MFC apps using the VC++ .Net IDE, it uses the new MFC v7.0 runtime DLL. When I first started using Windows XP about 6 months ago it didn't ship with the MFC 7.0 DLL. But it does come with VC++ .Net obviously. So as a developer, if you want to redistribute your applications you made with VC++ .Net, you'll also have to bundle the MFC 7.0 DLL. I forget which programs I installed, but I have seen commercial apps shipping with the MFC 7.0 DLL included locally in the program directory rather than installing it into the System folder.

If you want to reach a broader audience and reduce dependency, and especially if you're doing distribution over the Internet and want smaller downloads, and third if you don't want to deal with Install Wizard tools then your best bet is to stick with VC++ 6.0 and MFC 4.0.

[smurfiness]

Win32 is C code, NOT C++. MFC is the C++ wrapper for the Win32 API.

Incorrect. The Win32 API is written in C. You can write a Win32 project in C++ without using MFC. If you need proof, just start a Win32 project in VC++ (any version), and create a class. Bingo, C++.

[Lycander]

Incorrect. The Win32 API is written in C. You can write a Win32 project in C++ without using MFC. If you need proof, just start a Win32 project in VC++ (any version), and create a class. Bingo, C++.

Let me rephrase that: Win32 IN-AND-OF-ITSELF is C code. The API is procedural. That's what I meant. It goes without saying that C code can be mixed with C++.

I know you can use Win32 in C++ code, but gameguy had said Win32 is C++ code which is incorrect and that's what I was trying to straighten out.

[John Veteran]

I know you can use Win32 in C++ code, but gameguy had said Win32 is C++ code which is incorrect and that's what I was trying to straighten out.

No, I said that in VS.NET, a Win32 project was a 'normal' C++ project...

Edit: I should have just taken a screenshot earlier :rolleyes: This is what I'm talking about:

[Lycander]

No, I said that in VS.NET, a Win32 project was a 'normal' C++ project...

Yeah the screen shot helps, didn't sound like that the first time around.

Anyways... does anyone know how to make VC++ .Net (7.0) link against MFC 4.2 instead of 7.0?

[John Veteran]

Yeah the screen shot helps, didn't sound like that the first time around.

Sorry for the confusion :/

[smurfiness]

Yeah the screen shot helps, didn't sound like that the first time around.

Anyways... does anyone know how to make VC++ .Net (7.0) link against MFC 4.2 instead of 7.0?

Link to the MFC 6 (the mfc42xx files are actually MFC 6.0) .lib files instead of the MFC 7 files, which the IDE uses by default.