With MFC, problems that should take minutes to solve sometimes take days.
How so? I always found it very simple, and if you want part of th win32 api that isnt wrapped by MFC you just call it directly. You can edit the message map simply to add WM_XXXXX commands that arent handled by the class wizzard, and can simply modify the comnstructors to pass all kinds of data round.
The only complexity would be implementing something complex, like windows hooks or some such, but that would be the same with MFR of raw win32 API.
But I agree, learn .Net and C#, it has WAY more commercial demand. (By the way, I didnt know you can use C++ with ,Net. I am a kernel guy and dont venture into user mode that much these days.)
The consistently incomplete documentation for MFC makes it difficult to use.
Of course an MFC expert can easily use it to solve problems. But it's not user friendly to someone who's not an expert. With .NET and intellisense, you can use .NET effectively even if you don't know it very well.
A couple examples of MFC landmines that eat up the hours and days of your development time:
1. You have a CBitmap and you want to load a .bmp file from disk. How do you do it?
(HINT: CBitmap::LoadBitmap () doesn't work. How retarded is that?)
2. You see that OnDraw () is used to update windows. Fair enough. But you try to use it on a CDialog and it doesn't f***ing work!. Part B: You try to use it on a CFrameWnd and it doesn't f***ing work, but for a DIFFERENT reason!
MFC is full of garbage like this! (And I used it back in 1997 when you couldn't just go to the Internet for a quick answer.) MFC is one of the reasons I hate Microsoft!
I think it was a combination of incompetence, lack of vision, arrogance and a fear of lawsuits (for the JPG and zip stuff.)
Alan Balkany wrote:
undocumented functionality to slow them down.
Contrary to popular belief, that is very rare. Almost all undocumented functionality that is useful is actually provided through other means. Frankly, the biggest problems with Windows is the COM kick they got on in the 90s and that Microsoft engineers tend to over-engineer everything favoring complexity over simplicity (an all too common problem with all engineers.)
There is a value in MFC even this days. A lots of applications are written with MFC, and some of them(which are usually time critical or compute intence) are still will be written in MFC.
If you interested in learning MFC, the good start is Ivor Horton's "Visual C++ 2010".
That depends on what you mean by "value". If you're just thinking about its usefulness on your résumé there are probably better choices.
To the .net is better camp all I've got to say is, personally I'm glad I went from lower level programming environments and worked my way up. I think that actually knowing what's going on makes you a better programmer.
If your application is Windows specific and needs any sort of performance advantage, MFC is fantastic. Personally, I like the enhancements to it offered by CodeJock, but to each his own. People like to gripe about MFC because it doesn't have C++ purity, but who cares; it's fast and, with a few exceptions, stays out of my way (in what matters to me.)
On the other hand, for database front ends, ASP and UI applications where you are willing to give up some fine grained control, a little performance AND you are still Windows specific, .NET is the way to go. Some people here have advocated going the Silverlight route. I'm not a fan, but my work doesn't fall into the niche where Silverlight makes sense.
For cross platform, despite some its ugliness, including it's massive size and very annoying pre-compiler, Qt is probably the best bet. (WxWidgets is also worth looking into, but I'm more familiar with Qt and personally find it better going forward, though I could change my mind tomorrow.)
I do agree with a comment above; if you are just learning C++, don't bother with a GUI. Same with C#. Just use the console and try to keep the code as procedural as possible and build from there once you get the basic concepts down. To be honest, I prefer people start with C, but that may not be realistic today.
I have a picture control on a dilaog box which is contained in a property sheet. Now whenever I increase the resolution of the PC, size of the controls on my application will be same, and it will show some space to the right of the application controls when it is displayed. I can change the position of the controls but how to increase the width & height of a bitmap in mfc.
Controls size will remain same irrespective of the resolution of the monitor, rather it will show an empty space at the bottom & right of the controls ( in case ur monitor size is large and you increase the resolution).
Originally it was made for Visual Studio 7.1 (2003) but I managed to fiddle with it to get it compiling/working under Visual Studio 6.0 (because that's what I have).
Everything is working however the project is non-UNICODE. So I converted the project into UNICODE and now I get lots of build errors, such as:
error C2664: 'spell' : cannot convert parameter 1 from 'class CString' to 'const char *'
The whole MySpell library/code uses char * everywhere... and even HunSpell uses char * everywhere too. So how come previously (in non-UNICODE) there was an implicit conversion between CString & const char *, but after changing project to UNICODE I get this error.
PS: This is not problem about converting CString to char * - even though I've tried this, it just doesn't work.
A quote from the MySpell link of the SpellEdit article:
MySpell has been replaced with hunspell starting with OpenOffice.org 2.0.2. Hunspell builds on MySpell but supports Unicode and adds several other useful features.
So you can't use MySpell with Unicode builds because it supports only ANSI character sets.
Hunspell has Unicode support but uses UTF-8 strings while Windows uses UTF-16. So Windows strings must be converted to UTF-8 before passing them to the spell checker.
With UTF-8, strings are still passed as char* because a single character is encoded as sequences of bytes with variable length while UTF-16 charcters are represented by two bytes (wchar_t). When using CString objects, they will be CStringA or CStringW according to the Unicode setting of your project. You may use CStrings to convert between ANSI and Unicode:
I am creating a MfC Dialog based application using vs2010 in XP. I am adding some controls to dialog by using Template. Now,When I am opening that application in Win7, the default XP style with additional control is coming fine but it replacing Win7 Dialog standard controls like Search feature.
And If i Pass the last parameter to CFiledialog [bVistaStyle] to TRUE then only Win7 style dialog is appearing but not additional controls tht i added using template.
I want dialog should appear like Xp style with template and and with win7 standard controls too.
I want to change my system IP, subnet mask, host name etc. using win32 VC++.
I've tried AddIPAddress function but that's not persistent.
I want to change it that it should be change without rebooting system and should be there after restarting the system.
I am working on a project in which I have a Property Sheet and 3 Property Pages. I have some controls on Property pages. I want to make my project DPI independent, SO whenever I'll change the position of any control, the control at the bottom will get hidden. The control will be moved to the bottom but will get hidden. Say If I change the position of the control from rc.top to rc.top + 20, it will move down but will get slashed off from the bottom.
Is it possible that the size of the Property sheet is fixed.?
How to change the the size of Property Sheet or Property Pages in MFC.
This is my first code using DirestShow and could use some help with this linker issue. The “problem “ is that the second usage of CoCreateInstance with CLSID parameter of CLSID_VideoMixingRenderer fails to link. Here is “standard” linker error:
I have replaced ( in uuids.h) failing CLSID with working one , same linker error. Since I do not know squat about this I guess I need to find out what it should be to make this troubleshooting more effective.
The library is inluded. That is why I am lost since one of the CLSID works and the other does not. Maybe I should look for #ifdefs in the uudis.h, but the compiler "reported" the #pragma message I stuck in front of the "bad" CLSID. Go figure.
Then the chances are that there is another missing library. Unfortunately I have no experience of this package and only found the answer by searching through the documentation. I am afraid you will have to do the same.
I can understand if you are trying to stay with VC6 for financial reasons, but I have to echo the last line of the response "You should really think about upgrading to a more recent version of the IDE."
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
Don't worry, I will not give you a whole lecture about upgrading, just suggest it. I am using VS2010 and I don't have problems with Windows SDK 7.1, I think .
From what I have heard, VS2010 is slower than VS2012, so you might be even more disappointed should you switch to that.
I recalled reading a post a few weeks ago in the Lounge by Marc Clifton where he said VS2008 was the last usable IDE put out by Microsoft. I hunted the post down for you in case you are interested: I would have to say...[^]
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
Soren, I truly appreciate you sparing me from lecturing how cool MS stuff is. I was once interviewed by MS “experts” only to find out that the development “teams” do not maintain any records from one release to another – in their own words “ we do it from scratch because we have new “teams”. I was actually glad they did not hire me. I also believe the other reason their stuff so boated and full of holes need fixing is they are actually hardware company – pushing for more memory, larger HDD and even “developed” CD because loading OS using couple of dozen floppies was ridiculous. I wish I could figure out why the VFW is so flaky and skip the Direct whatever for now. If the DirectShow sample posted ( written with VC6.0) here worked for me I suspect I would find out that it also have problems to display the captured video. Actually that is the root of my current linker problem – the CVMRCaputre class posted here does not link either, I get same linker undefined symbol. Unfortunately the author is no longer active – so I got double trouble. Makes one wonder why so many authors of video capture programs posted here disappear from the scene fast. I guess the only stalwart is CxImage stuff. Sorry for the rant, going on my morning walk now. Cheers and have great day. Vaclav
Unless I can find a source code ( just dreaming) for this stinking stream id library to build my own - what are my alternative(s) to do RELIABLE video capture besides ( expletive deleted ) DirectShow? I really do not want to switch to Linux and start over. No more cheers from me on this one. Vaclav
i'm not sure how can I do the four function I did a lot with for loop function but how can I give the user ability to insert and remove at the position he prefers maybe he wants to remove elemnt at the binging maybe at the last maybe in the middle, also inserting , we have cases