MFC under VS2010
in [MFC]
|
Prev: MDI App: start 2 DocTemplates in CMyApp::InitInstance
Next: How To: CStatubar panel Right-align text
From: Joseph M. Newcomer on 30 Mar 2010 13:28 See below... On Tue, 30 Mar 2010 04:37:01 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:f5q2r5hrd0sj3sv0j59lla2lf4jkpg0qmd(a)4ax.com... >> One of the things Microsoft discovered is that native code is NOT going to >> go away. That's >> why we are getting enhanced support in new versions of MFC, constantly >> improved native >> mode compiler, etc. So they have realized that the managed world is NOT >> going to supplant >> native code for a lot of applications. >> >> And nobody has mentioned "managed C++". >> joe >> > >Did I say native code was going away? Clearly, it's not. > >What I said is: "if native development is the only trick in your bag, you >are not going to be well positioned to develop Windows in the future." >Clearly, that is true as well. **** I agree. I feel culturally displaced because I don't know WPF. But I have difficullty justifying it because my customer base is purely C/C++ based. But I really think I should be learning it. **** > >For the past three years, it's been very difficult for me to find Win32/MFC >jobs here in the Bay Area. Mostly all the job ads for Windows client want >at least some .NET experience, and most of them are interested ONLY in .NET. >C++ is still used for cross platform or embedded, but then we are not >talking about Windows. And it's not just me. I have former colleagues who >have been programming MFC (and MFC only) for the last decade who are now >having difficulty being attractive in the job market. **** I am kept sufficiently busy with C/C++ work that I don't have spare time to learn WPF. I keep feeling this is going to come back and bite me soon. **** > >Conversely, from the hiring side, one of my current gigs is at an extremely >large and well known global nework company. They hired me as a C# engineer >and even though I suggested writing their app in C++, they expressly did not >want that for fear they would not be able to hire capable people to maintain >it, as "MFC programmers are dying out." So it's a cycle that spells the >doom of MFC. **** Sadly, these myths persist. My clients don't want C# because they have no in-house people to maintain the code (having ONLY C/C++/MFC experts) **** > >It's funny that the lip service MS pays to MFC with "enhanced support in new >versions of MFC" is not improving the job market at all. Well, duh. I look >back at our debates on what is the proper prefix of user defined windows >messages - UWM_, WM_, or whatever. Then I think, how quaint it is to be >using Windows messages as a communication mechanism in the first place! >Qt's signals and slots, and .NET delegates are so simple and powerful in >comparison. **** Yep. joe **** > >-- David > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Tom Serface on 30 Mar 2010 13:42 I just worked on another complete .NET application and since it was very file system intensive I had to resort to pInvoking all sorts of Win32 functions since the .NET System.IO implementation can't support file paths longer than 260 chars. Sure, Windows supports it, Win32 supports it, but I guess the .NET architects thought they didn't need to. So far I haven't been able to do any C# programming without calling on Win32 functions directly. I don't find the GUI editor to be that much better either. I do like how some things, like font settings, are settable in the properties, but other than some conveniences like that, I don't see the big deal. Tom "Ajay Kalra" <ajaykalra(a)yahoo.com> wrote in message news:644c9093-eec0-4e02-bc0d-01202e021824(a)x12g2000yqx.googlegroups.com... > On Mar 29, 7:24 pm, "David Ching" <d...(a)remove-this.dcsoft.com> wrote: >> "Ajay Kalra" <ajayka...(a)yahoo.com> wrote in message >> >> The point is, if native development is the only trick in your bag, you >> are >> not going to be well positioned to develop Windows in the future. MS is >> slowly making essential capabilities managed-only. > > I have forgotten what native development is. It seems odd but I hope I > dont ever have to do that for GUI development. For server side work, > unmanaged is OK. > > -- > Ajay > > >> >> -- David >
From: Tom Serface on 30 Mar 2010 13:43 I think they also discovered that C++ remains popular in spite of all the of rhetoric to the contrary. Tom "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:f5q2r5hrd0sj3sv0j59lla2lf4jkpg0qmd(a)4ax.com... > One of the things Microsoft discovered is that native code is NOT going to > go away. That's > why we are getting enhanced support in new versions of MFC, constantly > improved native > mode compiler, etc. So they have realized that the managed world is NOT > going to supplant > native code for a lot of applications. > > And nobody has mentioned "managed C++". > joe >
From: Tom Serface on 30 Mar 2010 13:45 Hi David, I fully agree with you. Any good programmer these days can live in several program paradigms. I often jump between 3 during the same day. I also agree that MFC is becoming more cob-web covered as time goes on. There is some improvement in 2010 with ClassWizard, but ... Tom "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:u0UYR1$zKHA.2436(a)TK2MSFTNGP04.phx.gbl... > > Did I say native code was going away? Clearly, it's not. > > What I said is: "if native development is the only trick in your bag, you > are not going to be well positioned to develop Windows in the future." > Clearly, that is true as well. > > For the past three years, it's been very difficult for me to find > Win32/MFC jobs here in the Bay Area. Mostly all the job ads for Windows > client want at least some .NET experience, and most of them are interested > ONLY in .NET. C++ is still used for cross platform or embedded, but then > we are not talking about Windows. And it's not just me. I have former > colleagues who have been programming MFC (and MFC only) for the last > decade who are now having difficulty being attractive in the job market. > > Conversely, from the hiring side, one of my current gigs is at an > extremely large and well known global nework company. They hired me as a > C# engineer and even though I suggested writing their app in C++, they > expressly did not want that for fear they would not be able to hire > capable people to maintain it, as "MFC programmers are dying out." So > it's a cycle that spells the doom of MFC. > > It's funny that the lip service MS pays to MFC with "enhanced support in > new versions of MFC" is not improving the job market at all. Well, duh. > I look back at our debates on what is the proper prefix of user defined > windows messages - UWM_, WM_, or whatever. Then I think, how quaint it is > to be using Windows messages as a communication mechanism in the first > place! Qt's signals and slots, and .NET delegates are so simple and > powerful in comparison. > > -- David > >
From: Tom Serface on 30 Mar 2010 13:47
I still don't think you can do managed code without unmanaged code being included. With all of the library support .NET has it is still lacking in some of the basics (like interface to DirectShow/DirectX for example). I haven't done any WPF, but I've heard from people that I respect that it's not all it's advertised to be either. Tom "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:euc4r5dtrah9m7altmoot415ta5jf2l6ai(a)4ax.com... > **** > I agree. I feel culturally displaced because I don't know WPF. But I > have difficullty > justifying it because my customer base is purely C/C++ based. But I > really think I should > be learning it. > **** |