MFC under VS2010
in [MFC]
|
Prev: MDI App: start 2 DocTemplates in CMyApp::InitInstance
Next: How To: CStatubar panel Right-align text
From: Hector Santos on 27 Mar 2010 10:53 I am about to finally *commit* product porting and new development under VS20xx. Currently have VS2005 and successfully recompiled all our projects and MFC applications. 139 of 150 projects in total where moved over. But we never felt good to release it as an update. About VS2010, we definitely going to upgrade to it, and I heard it is the "new VC6 (VS98)" - that excited me. I am not like going to waste time downloading the RC and go thru any hassles installing it. Can people with VS2010 now tell me about about their experiences and reality? Such as: I didn't like the class wizard in VS2005. Is it better? What about controls? Was the property editor extended to better support extended aspects with controls (less sub-classing requirements))? One of the reasons I didn't want to commit to VS20xx compile based product packaging and distribution was based of new OS and different flavors of OS SxS and manifest stuff. The beauty of having a product under VC6 was that it was design purely for WIN32 and never had to worry about the version of windows users had. That seem to change now. So I guess, the deeper questions and answers I see is what are the "new got yas," if any? Thanks PS: What is WPF overall? A new GUI foundation? Do you recommend WPF over MFC? -- HLS
From: Woody on 28 Mar 2010 04:04 I have seen a lot of bugs in RC1, and, it is slow. Also, it suffers from feature bloat. No matter which technologies you are using, there will be 10 others that you will never want, that just clutter things up. The help system is practically non-functional. I've had lots of problems importing projects from VS6 and VS2005. Since the project file format has changed, all solutions and projects must be converted (and you can't go back). The download and installation process is pretty simple; you just burn an ISO CD and then do an install. There were bugs in the betas, but these seem to have been fixed in the RC. If you do an install, be sure to use a machine that isn't needed for VS production, as your default VS will become VS2010.
From: Ajay Kalra on 29 Mar 2010 14:53 > PS: What is WPF overall? A new GUI foundation? Do you recommend WPF > over MFC? > WPF will take you away from managed world to .Net, which is managed. WinForms and now WPF are available in .Net and obviate the need to use MFC in .Net world. In general, you would not use MFC in .Net, unless you have a very good reason to do so(existing controls which you dont want to migrate to .net). -- Ajay
From: Hector Santos on 29 Mar 2010 15:54 Ajay Kalra wrote: >> PS: What is WPF overall? A new GUI foundation? Do you recommend WPF >> over MFC? >> > > WPF will take you away from managed world to .Net, which is managed. > WinForms and now WPF are available in .Net and obviate the need to use > MFC in .Net world. In general, you would not use MFC in .Net, unless > you have a very good reason to do so(existing controls which you dont > want to migrate to .net). Thanks for the clear explanation. Whats the difference from WPF and WinForms. Would you say that MS is merging the .NET technologies anyway for MFC based code once compiled under VS2005 and more so with VS2010? In other words, does a distribution for a VS2010 recompiled MFC applet with no explicit action on my part to include WPF/WINFORM, will it still required some level of .NET to be installed on a end-user machine? For example, when I was playing with this OCX CTabStrip a few days ago, I noticed without further investigating or testing it as a standalone that it was loading .NET system dll. This has been one of my concerns and not getting committed to VS2005 development and staying with VS98 for my products until we are really to full commit to the new GUI foundation and/or .NET. I didn't want to get caught with MS ever increasing nature of indirect hooking into more managed and centralized sub-system for our customers, at least not yet. Now we are more ready to do so - or not be too concern about it. The market is more ready for it. Is it safe to say that if I include and OCX/COM into the MFC package, there will be some managed sub-system requirement when its recompiled under VS2010? -- HLS
From: Ajay Kalra on 29 Mar 2010 16:18
On Mar 29, 3:54 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: > Thanks for the clear explanation. Whats the difference from WPF and > WinForms. WinForms came originally with .Net. WPF is the newer framework. WinForms is now essentially not going to see enhancements(it will be still part of .net). > Would you say that MS is merging the .NET technologies anyway for MFC > based code once compiled under VS2005 and more so with VS2010? That happened long ago. Users who use MFC, dont typically use .Net . > In other words, does a distribution for a VS2010 recompiled MFC applet > with no explicit action on my part to include WPF/WINFORM, will it > still required some level of .NET to be installed on a end-user machine? No. A pure MFC app has no dependency on .Net. > For example, when I was playing with this OCX CTabStrip a few days > ago, I noticed without further investigating or testing it as a > standalone that it was loading .NET system dll. Then there is something worng. You shouldnt be depending upon .net if you are pure MFC. It has nothing to do with VS2005 or VS2010. You should identify by running Depends etc as to why do you have this dependency. -- Ajay |