|
|
|
My biggest complaint with MFC/Visual C++ is...
Date: 9 July 96, 19:33 EDT From: Mike Lorenz Email: mfc-mlorenz@visionx.comMy big MFC beef: the fact that it's not really designed in an object-oriented way. IMHO, that's the big one. It makes everything harder to program and maintain than it needs to be.
Date: 10 July 96, 17:13 EDT From: Alex Goodstein Email: alexg@netgates.co.ukYep, it certainly isn't very Object-Oriented. In my opinion, the wrapper around API functions is a little too thin. Presumably, this was done originally to make the transition from API to MFC simple, and now we're stuck with it - in the name of backwards compatibility.
Date: 10 July 96, 17:49 EDT From: Tim Craig Email: CraigTT@PE-Nelson.comMy biggest beef is lack of documentation. I can't count the number of hours I've spent sifting through the MFC source and trying to figure not only "how it works" but "why they did it that way" when I'm trying to figure how to coerce MFC into doing what I want. I think part of the problem is the very simplistic view by Microsoft that all applications are some simple office automation editor.
Date: 12 July 96, 19:58 EDT From: Leif Terje Fonnes Email: leffen@bgnett.no1) I think the biggest problem with MFC is its not modular enough, You have to drag a lot of stuff that you dont need or want if you use the DLL alternative. I wish they made more modules to use. 2) MS speaks a lot of making tier code. And says that OLE is the way to go, but all the examples I see IS not n - tier code it is exmples on communications between two programs yous and the OLE server. I would like to see wizards creating business modules.
Date: 14 July 96, 8:10 EDT From: Ian Hegerty Email: ihegerty@sina.demon.co.ukMy biggest beef is the over-reliance on the document-view architecture. It's great for things that need it, but I often find I either have to shoe-horn my design into a D-V based approach, or write a lot of code myself. I think l there should have been a middle layer.
Date: 16 July 96, 5:12 EDT From: Alistair Israel Email: aisrael@hotmail.comI agree that MFC forces you to rely too much on its document/view architecture. I mean, this is fine and all -- I should know, I fooled around with a project once trying to make it 'elegant' before discovering MSVC and doc/view. Doc/View is well-suited for a variety of applications, but not all applications. What if I wanted multiple docs sharing a single view, for example, as in the case of a multiple (price history documents) superimposed on a single graph view? The application framework has absolutely *no* support for that, does it? My only recourse would be to heavily modify doc/view or even scrap it entirely and build from scratch, or change my design. Both of which may either be technically not feasible or politically/economically undesirable.
Date: 17 July 96, 13:02 EDT From: Ashvini Sharma Email: asharma@comshare.comVirtually no additional support for the 16 bit world. It would have been peachy if all our users were in the 32 bit environment, but they're just not moving as fast as Microsoft would have us believe.
Date: 17 July 96, 15:09 EDT From: Andy Barnhart Email: andy@ciinc.comIt bugs me that the multitasking stops a little short of the mark inside MSDEV. You can compile and edit at the same time, but you can't do a Find in Files command while compiling. Our project is pretty large - 150+ files. If I need to change a H file that is used by a lot of files, I change it and begin the compiling so that I can change source files as it compiles, then only recompile a handful. Find in Files is a very common editing command for me. But I can't do it unless I stop the compiles! Worse yet, if you stop the compiles, it has to start all over because of the code generation that it does at a multi file level.
Date: 1 August 96, 23:17 EDT From: Andy Ejzak Email: insite@cris.comI simply can't beleive that there isn't a huge development community uproar regarding MS's refusal to continue updating 16 bit C++ and MFC. My guess would be that probably 75% or more of current MFC developers require 16 bit capability. Suprise, they're doing it again with 4.2 - it doesn't support Win32s!
Date: 2 August 96, 13:23 EDT From: Alan Livingston Email: lal0001@jove.acs.unt.eduWhile I agree with the comments about not supporting 16-bit environments, I think MS has done a greater disservice to end users than to developers. Without recognizing it, MS has dropped the ball by forcing all end users to go to 32-bit environments. I don't know about other contractors, etc. but most of the companies I've dealt with lately don't plan on upgrading to 32-bit for another 2-3 years because of the hardware costs. As a developer, I'm royally screwed using Visual C++ because I can't get support from MS on the 16-bit platform. I guess MS forgot to ask the majority (end users) of users how long they planned to stay on the 16-bit platform. But, of course, that just my $.02 worth.
Date: 6 August 96, 13:59 EDT From: Petter Hesselberg Email: petter.hesselberg@ac.comI agree pretty much with all the comments seen thus far. One of the things I'd like to see is improved capability in the ClassWizard for MAINTENANCE. As it is, you'd better get everything right the first time -- you must jump through hoops to delete classes or change a base class. You can't even modify the type of a dialog member variable; you must first delete it, then add a new one. BUT. On the whole, I'm impressed with VC++. I know this is supposed to be a list of complaints, but let's not lose our perspective here...
Date: 7 August 96, 4:38 EDT From: Gervase Markham Email: grm@datcon.co.ukI hate the fact that they provide over 100 Meg of documentation and it's all really badly indexed and hard to explore. The Query engine produces several hundred irrelevant hits every time you use it, and there is no sample code to do simple stuff which works with Win NT.
Date: 19 August 96, 6:06 EDT From: Darren Poulton Email: darrenp@taskey.comI aggree that no 16bit support stinks. However, the 16bit world has to be left behind at some point and by not supporting it forces things along. Users who do not upgrade their machines will find they cannot upgrade their software either. BUT WHAT REALLY STINKS IS VB4.0 supports 16bits!!!!
Date: 29 August 96, 21:18 EDT From: Mike Haney Email: mikester@wl.netI have used MSVC professionally for 3.5 years, and overall I am pleased with it. But over those years, MS has made very few enhancements to ClassWizard. Sure, the latest version will map member functions as well as messages, but it's not enough. Every time I start a project, I always create an extra class layer in my design - IOW I create a CMyView derived from CView, and then all of my project's views are derived from CMyView. I do this from the start now, because in the past I have usually needed that extra layer and it's a pain to add later. However, ClassWizard becomes essentially useless at this point. Sure, I can use it to derive my first class, by deriving from CView and then doing a global replace, but after that it is usually easier to just use that class as a template for new ones. As long as ClassWizard is oblivious to user-created classes, it will have limited utility outside of the "ooohhh" factor it creates at MS product demos.
Date: 2 September 96, 13:14 EDT From: Herman R. Willett Email: hrwillet@dynasoft_.win.netHi. When I first got VC++ I ran into problems for almost a week, and about $200 on books. All the books said the same on the point that was giving me problems. I just could not find the reason I was getting the exception error when trying to launce a new document/view from a control. Even when I typed in the example code/app from the books. I finaly contacted MS, only to find out that ALL the books were wrong. There was a known bug in the MFC that any one who had wrote a program using the MFC would have known about. So, when are we going to get programmers writing MFC books instead of technical writers or plagerist who copy code fragments and publish them. This is my gripe.
Date: 24 September 96, 20:30 EDT From: Michael Feathers Email: feathers@icanect.netThis is a pheripheral gripe. In our department, we've had several development projects where document format have changed rapidly and the developers have not had time to handle it properly. We've required our in-house users to recreate their documents from scratch in our MFC applications. I wish there was a better way of handling document format changes than that silly version number scheme. When will Microsoft come up with something like POET; an object-oriented database to use for serialization.
Date: 16 December 96, 24:29 EDT From: Dinesh Jindal Email: dinesh@xox.comI have been working with VC++ for the last 4 years and I must say it has improved a lot from version 1.0 days. The most irritating thing I found is the developer studio not keeping include and library directory settings with the project file. Usually I work on more than one project while maintaining a few old ones and every time I switch between projects I have to go into Tools...Options...Directories to change the paths. Why can't Microsoft keep these settings project based instead of a single setting for a machine!
Date: 26 January 97, 24:54 EDT From: Hal Johnson Email: halj@kaiwan.comAs a new user, I'd like to see more source code examples in the online documentation. Especially for new areas (like the internet classes) where there is a lack of books or info in the public domain.
Date: 19 February 97, 6:57 EDT From: Bo Yang Email: dyang@sfu.caI hate those macros. Recently I need to write a COM DLL, and almost all the COM samples on MSDN use MFC interface macros. After figuring out COM, I just don't see the point of those macros. They're confusing and difficult to remember. For a beginner trying to learn COM, they make things more complex and difficult than they really are. And once you know COM, why do you need those macros? You can argue that they "simplify" things by handling some details for you, and provide logical encapsulation for low-level COM calls. Well, the macros just replace old details with new details. At least the old details are basicly closely-related to low-level COM stuff, so logically they're easier to learn, and once you learn them, you know COM at low level. The new details are arbitrary, not apparently related to anything, and serves no useful purpose.
Date: 27 February 97, 24:01 EDT From: Fred Huls Email: hulsf@icanect.netThe support for templates is poor - no support for templatized members, or default template arguments, explicit specialization leaves a lot to be desired as well. In addition, their implementation for the Standard C++ library in 4.2 is riddled with bugs, and they don't release patches or even a bug list for it, instead I have to spend my time determining that it is a bug in their implementation, and not in my code. If your going to give me something new, at least try to use it.... For instance: try linking with the new iostream library, and use MFC CArchive. Their own debugger complains of memory leaks. The assignment operator on list<> is broken, - how long does it take to come up with some test cases to check the common operations on all STL containers? It's sad!
Date: 25 April 97, 12:25 EDT From: Bill Boyles Email: bboyles@ipass.netHow about remembering those of use that don't develop for the internet. MFC/VC++ is moving toward an Internet Development platform instead of a solid IDE for general programming.
Date: 17 May 97, 9:16 EDT From: David Thompson Email: dthompsona@cix.co.ukMy gripe is that the MFC is primitive. Why does it use a Smalltalk style single inheritance appraoch - forcing MS to avoid using virtual functions (those damn message map macros!). If they'd used multiple inheritance, true RTTI, templates and buildt a forset of classes the thing would be a) More apporachable b) more effiecent in time and space c) more elegant. Oh, and its well overdue time to incorparte the STL. In short the MFC seems elderly. Time to move it into maintance mode and write the MTL (Microsft template library).
Date: 25 July 97, 1:20 EDT From: Pete Delgado Email: Peter.Delgado@sdrc.comI guess I must be in the minority here.. I like the improvements in Visual C++ and MFC from the 1.0 days. My only real gripe is that many of the possible classes (TAPI, MAPI) have not yet been developed and added to MFC. Pretty small gripes...
If you just added a comment, and you don't see it, hit your "REFRESH" button.
This thread is for entertainment and educational purposes.
We reserve the right to delete any messages without notice.