Switching from MFC to .NET
-
For the last 4 years I've been teaching a course in Windows programming. I've been using MFC all this time - MFC was used before I started teaching this course and I was hired to do this basically because of my MFC experience. This is a course in the first year - second semester. The first semester currently teaches the students the basics of C/C++. Now the school is determining - what should we continue to teach? Should this course continue to use MFC and leave the .NET issues until later? Should we drop MFC / Win32 programming entirely and focus on .NET? Or should we mix them together? And then in what proportions? I.e. how much should attention should MFC get vs. .NET - should the perhaps only be a Win32 part and no MFC in the first half and strictly .NET in the latter? Or only MFC in the first part? (I find it hard to teach MFC without at least mentioning Win32). And what language should we use to teach .NET? C#? Managed C++? These are a lot of questions and I don't expect to get an answer to all of them but would like to know your opinion in this matter.
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
-
For the last 4 years I've been teaching a course in Windows programming. I've been using MFC all this time - MFC was used before I started teaching this course and I was hired to do this basically because of my MFC experience. This is a course in the first year - second semester. The first semester currently teaches the students the basics of C/C++. Now the school is determining - what should we continue to teach? Should this course continue to use MFC and leave the .NET issues until later? Should we drop MFC / Win32 programming entirely and focus on .NET? Or should we mix them together? And then in what proportions? I.e. how much should attention should MFC get vs. .NET - should the perhaps only be a Win32 part and no MFC in the first half and strictly .NET in the latter? Or only MFC in the first part? (I find it hard to teach MFC without at least mentioning Win32). And what language should we use to teach .NET? C#? Managed C++? These are a lot of questions and I don't expect to get an answer to all of them but would like to know your opinion in this matter.
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
dabs wrote: Now the school is determining - what should we continue to teach? Should this course continue to use MFC and leave the .NET issues until later? Should we drop MFC / Win32 programming entirely and focus on .NET? Or should we mix them together? And then in what proportions? I.e. how much should attention should MFC get vs. .NET - should the perhaps only be a Win32 part and no MFC in the first half and strictly .NET in the latter? Or only MFC in the first part? (I find it hard to teach MFC without at least mentioning Win32). And what language should we use to teach .NET? C#? Managed C++? Your courses should answer questions not answered by Petzold's book (on Windows Forms) and Richter+Box's (CLR). With the flood of web sites, books, and stuff around .NET these days, I believe the real added value of your training is to provide real world cases to your audience. Here are some : - migrating VB6 code to VB.NET - interoperating Dlls and COM in the .NET world (platform invoke is a nightmare, proper use of marshalling requires a lot of education, ...). - using .NET objects from a non .NET context (backward interop) - profiling .NET apps (profiler APIs) - memory performance (hardcore use of the GC) - the use of .NET reflection to improve software design - Windows Forms GUI apps when you know MFC (CWnd, CView, ... and owner drawn controls) : relevant internals about the initialisation/creation steps, the WndProc method, ...(in other words, how Windows Forms actually rely on WIN32 window classnames and styles).
-
dabs wrote: Now the school is determining - what should we continue to teach? Should this course continue to use MFC and leave the .NET issues until later? Should we drop MFC / Win32 programming entirely and focus on .NET? Or should we mix them together? And then in what proportions? I.e. how much should attention should MFC get vs. .NET - should the perhaps only be a Win32 part and no MFC in the first half and strictly .NET in the latter? Or only MFC in the first part? (I find it hard to teach MFC without at least mentioning Win32). And what language should we use to teach .NET? C#? Managed C++? Your courses should answer questions not answered by Petzold's book (on Windows Forms) and Richter+Box's (CLR). With the flood of web sites, books, and stuff around .NET these days, I believe the real added value of your training is to provide real world cases to your audience. Here are some : - migrating VB6 code to VB.NET - interoperating Dlls and COM in the .NET world (platform invoke is a nightmare, proper use of marshalling requires a lot of education, ...). - using .NET objects from a non .NET context (backward interop) - profiling .NET apps (profiler APIs) - memory performance (hardcore use of the GC) - the use of .NET reflection to improve software design - Windows Forms GUI apps when you know MFC (CWnd, CView, ... and owner drawn controls) : relevant internals about the initialisation/creation steps, the WndProc method, ...(in other words, how Windows Forms actually rely on WIN32 window classnames and styles).
Could not be better. I will just add .NET security. Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
-
For the last 4 years I've been teaching a course in Windows programming. I've been using MFC all this time - MFC was used before I started teaching this course and I was hired to do this basically because of my MFC experience. This is a course in the first year - second semester. The first semester currently teaches the students the basics of C/C++. Now the school is determining - what should we continue to teach? Should this course continue to use MFC and leave the .NET issues until later? Should we drop MFC / Win32 programming entirely and focus on .NET? Or should we mix them together? And then in what proportions? I.e. how much should attention should MFC get vs. .NET - should the perhaps only be a Win32 part and no MFC in the first half and strictly .NET in the latter? Or only MFC in the first part? (I find it hard to teach MFC without at least mentioning Win32). And what language should we use to teach .NET? C#? Managed C++? These are a lot of questions and I don't expect to get an answer to all of them but would like to know your opinion in this matter.
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
In my opinion, You could teach .NET and Managed C++, doing this would allow you to have the option of coding Windows Native C++ or Managed C++ (.NET) or mixing the two. However, Managed C++ is cumbersome when doing just .NET, if you want a language to teach students that is easier to use, yet is similar to C++, I would definitely use C#. This would be focusing on learning programming concepts and not learning the idosyncrasies of Managed C++. If you do stick with MFC/C++, I would consider teaching WTL, it seems to resemble ANSI C++ more than MFC. Good luck!
R.Bischoff | C++ .NET, Kommst du mit?
-
dabs wrote: Now the school is determining - what should we continue to teach? Should this course continue to use MFC and leave the .NET issues until later? Should we drop MFC / Win32 programming entirely and focus on .NET? Or should we mix them together? And then in what proportions? I.e. how much should attention should MFC get vs. .NET - should the perhaps only be a Win32 part and no MFC in the first half and strictly .NET in the latter? Or only MFC in the first part? (I find it hard to teach MFC without at least mentioning Win32). And what language should we use to teach .NET? C#? Managed C++? Your courses should answer questions not answered by Petzold's book (on Windows Forms) and Richter+Box's (CLR). With the flood of web sites, books, and stuff around .NET these days, I believe the real added value of your training is to provide real world cases to your audience. Here are some : - migrating VB6 code to VB.NET - interoperating Dlls and COM in the .NET world (platform invoke is a nightmare, proper use of marshalling requires a lot of education, ...). - using .NET objects from a non .NET context (backward interop) - profiling .NET apps (profiler APIs) - memory performance (hardcore use of the GC) - the use of .NET reflection to improve software design - Windows Forms GUI apps when you know MFC (CWnd, CView, ... and owner drawn controls) : relevant internals about the initialisation/creation steps, the WndProc method, ...(in other words, how Windows Forms actually rely on WIN32 window classnames and styles).
There are a lot of good suggestions in your answer and this is something I'll consider. You must however remember that this is on the first year and the experience these students have is minimal. They have just been introduced to C++ classes and inheritance is still a new word for them. So I guess a lot of these issues would be better suited for a course later in their education. But I had indeed thought about stuff like how the Windows Forms and basic Win32 are related. Teaching them what happens behind the scenes as well as teaching them some useful stuff. .S.Rod. wrote: Your courses should answer questions not answered by Petzold's book (on Windows Forms) and Richter+Box's (CLR). So you would recommend these books for this course? And would you say I should let the students read these books themselves without actually covering their material myself?
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
-
In my opinion, You could teach .NET and Managed C++, doing this would allow you to have the option of coding Windows Native C++ or Managed C++ (.NET) or mixing the two. However, Managed C++ is cumbersome when doing just .NET, if you want a language to teach students that is easier to use, yet is similar to C++, I would definitely use C#. This would be focusing on learning programming concepts and not learning the idosyncrasies of Managed C++. If you do stick with MFC/C++, I would consider teaching WTL, it seems to resemble ANSI C++ more than MFC. Good luck!
R.Bischoff | C++ .NET, Kommst du mit?
Soliant wrote: If you do stick with MFC/C++, I would consider teaching WTL, it seems to resemble ANSI C++ more than MFC. WTL is definitely a great library, and I use it in my company works too. However, it remains unsupported and may not appeal to most students wishing to grab some money quick from the first class! .NET market makes sense, but it seems to be more in the ASP.NET than any other thing. There is hardly a reason why I will wish to rewrite my WTL/MFC Windows applications using .NET. Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
-
For the last 4 years I've been teaching a course in Windows programming. I've been using MFC all this time - MFC was used before I started teaching this course and I was hired to do this basically because of my MFC experience. This is a course in the first year - second semester. The first semester currently teaches the students the basics of C/C++. Now the school is determining - what should we continue to teach? Should this course continue to use MFC and leave the .NET issues until later? Should we drop MFC / Win32 programming entirely and focus on .NET? Or should we mix them together? And then in what proportions? I.e. how much should attention should MFC get vs. .NET - should the perhaps only be a Win32 part and no MFC in the first half and strictly .NET in the latter? Or only MFC in the first part? (I find it hard to teach MFC without at least mentioning Win32). And what language should we use to teach .NET? C#? Managed C++? These are a lot of questions and I don't expect to get an answer to all of them but would like to know your opinion in this matter.
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
I suggest teaching both. MFC isn't going away, and recently graduated people are often relegated to the roles of maintenance, which means older code. They should have a solid foundation in legacy systems, but should also have training in what's new and upcoming so that they are capable of introducing such technologies into corporate environments. Concentrating on one or the other gives your new students a decided weakness in a market that is not dominated by either technology. -- Where are we going? And why am I in this handbasket?
-
There are a lot of good suggestions in your answer and this is something I'll consider. You must however remember that this is on the first year and the experience these students have is minimal. They have just been introduced to C++ classes and inheritance is still a new word for them. So I guess a lot of these issues would be better suited for a course later in their education. But I had indeed thought about stuff like how the Windows Forms and basic Win32 are related. Teaching them what happens behind the scenes as well as teaching them some useful stuff. .S.Rod. wrote: Your courses should answer questions not answered by Petzold's book (on Windows Forms) and Richter+Box's (CLR). So you would recommend these books for this course? And would you say I should let the students read these books themselves without actually covering their material myself?
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
dabs wrote: You must however remember that this is on the first year and the experience these students have is minimal. They have just been introduced to C++ classes and inheritance is still a new word for them Well you told us they knew about MFC. From what I read, that's in fact more academic stuff. On the one hand, either they have already been playing around MFC classes, and there is an interesting way to train to make them switch as seamlessly as possible to .NET Windows forms (the relation with Windows Forms is the this.Handle property, base class native window wrapper, WndProc method and CreateParams struct). Unfortunately, Windows Forms don't directly provide any CView equivalent mechanism. On the other hand, you may just as well introduce Windows Forms with the multicast event-based model in mind, ie a totally new way to drive GUI logic.
-
For the last 4 years I've been teaching a course in Windows programming. I've been using MFC all this time - MFC was used before I started teaching this course and I was hired to do this basically because of my MFC experience. This is a course in the first year - second semester. The first semester currently teaches the students the basics of C/C++. Now the school is determining - what should we continue to teach? Should this course continue to use MFC and leave the .NET issues until later? Should we drop MFC / Win32 programming entirely and focus on .NET? Or should we mix them together? And then in what proportions? I.e. how much should attention should MFC get vs. .NET - should the perhaps only be a Win32 part and no MFC in the first half and strictly .NET in the latter? Or only MFC in the first part? (I find it hard to teach MFC without at least mentioning Win32). And what language should we use to teach .NET? C#? Managed C++? These are a lot of questions and I don't expect to get an answer to all of them but would like to know your opinion in this matter.
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
I'd go with both since MFC isn't going away anytime soon for companies that need the faster performance possible while still making it bearable to program (I get a headache thinking about WTL). And .NET will be widely used soon and perhaps even replace VB and some Java as the interpreted language of choice. As for proportions, put a greater emphasis on .NET. Teach .NET first since it's easier, then reserve maybe a 1/4 of the latter part of the course for MFC.
-
dabs wrote: You must however remember that this is on the first year and the experience these students have is minimal. They have just been introduced to C++ classes and inheritance is still a new word for them Well you told us they knew about MFC. From what I read, that's in fact more academic stuff. On the one hand, either they have already been playing around MFC classes, and there is an interesting way to train to make them switch as seamlessly as possible to .NET Windows forms (the relation with Windows Forms is the this.Handle property, base class native window wrapper, WndProc method and CreateParams struct). Unfortunately, Windows Forms don't directly provide any CView equivalent mechanism. On the other hand, you may just as well introduce Windows Forms with the multicast event-based model in mind, ie a totally new way to drive GUI logic.
.S.Rod. wrote: Well you told us they knew about MFC OK I've obviously not explained the situation well enough. Here is a more thorough explanation of the background of the students: my course is taught on the second semester in the first year - the first semester teaches them the basics of C and C++ but no MFC in a course that takes 12 weeks. Then for 3 weeks they do a final project at the end of that semester where they use Borland CBuilder to build a simple windows application. Then on the second semester I take over and introduce them to the world of MFC. At that time they've used C++ classes for a few weeks but are still very unsure about things like inheritance and polymorphism - they've heard about these concepts but not necessarily used them. The next year will probably see a bit more emphasis put on this programming course on their first semester - i.e. they will learn in more detail about C++ features such as inheritance, polymorphism, exceptions and templates. So I can assume that the next year I will get students that have some basic understanding on these issues but no deep understanding and certainly not much experience in using these techniques. Hope this clarifies the situation somewhat.
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!