I just wondering about this.It is said that .NET is better than MFC in a lot of aspects.But when I use my PEID to recursive scan my 'program files' directory,it turns out there are still a lot of programs written with 'Visual C++ 6'(esp. for security software),whose GUI should be written with MFC.
So my questions are:
Is MFC still the dominating framework
for windows desktop aplication?
What frameworks do IE,firefox,Microsoft office(or other famouse desktop applications,if you'd like to list some) use?
What frameworks do the desktop applications(e.g. explorer,card games) of Windows itself use?
thanks.
I say windows forms and WCF are pretty widespread. C#/VB.NET are well-entrenched in corporate america.
IE is COM-based.
Office is MFC/COM.
Windows Apps are usually native code to demo the platform.
For new projects I don't think MFC is the dominant platform, but mostly because newer platforms shield developers from the idiosyncrasies of Win32 and MFC itself and allow for faster development. MFC applications take longer to develop but are, imo, unmatched in responsiveness.
I will not deny that some parts of the platform are irrelevant in 2010 (for example CArchive and most of the Doc/View foundation); on top of that, the dwindling availability of 3rd party components (mostly GUI) is a bit worrisome. FP1/MFCNext was a step in the right direction, I'm anxious to learn about the new MFC functionality in VS 2010.
For optimal integration with the OS, imo C++/MFC is still the best choice because of the nature of C++ as low-level and the fact that Win32 is still the foundation of Windows and that it can most easily be accessed in C or C++.
By the way, I had to write code to change screen resolution and found that C# could only handle detecting screen resolution but not changing it.
To change resolution you had to do a lot of Interop gobbldygook which I tried but was too complex because the Win32 APIs to do that had too many old style arguments.
So, instead I wrote a quick MFC DLL that accessed Win32 API directly and wrapped all the calls to Win32 in a simple API. Then I did an interop call to my simple API in an MFC User dll.
Everything worked fine.
So, there's still no substitute for Win32 API. That has the ultimate power, and you have full access to it via MFC. So, yes MFC is still relevant and so is ATL and so is direct Win32 all of which I'm forced to use from time to time.
So, you may get 90 percent of your work done with .NET, but you have to go under the covers for a few things. Also, I've done a lot of Qt, and would never use it for quick jobs that are windows only. Qt also has become prohibitively expensive if you're doing anything commercial and also it is very very bloated. It's libraries take up gigabytes.
Related
This question already has answers here:
How do I build a graphical user interface in C++? [closed]
(8 answers)
Closed 6 years ago.
is there a way of creating a classic GUI with cpp like for the case of JavaFX? I want to create elements like floating buttons, tables, graphs, etc. I know of tools like qt but I'm not ok with it. I tried win32 API but it's only for Windows.
GUI libraries are generally called "widget toolkits", and there are a variety of cross-platform GUI widget toolkits available, however they are rarely a good idea for a great UX because different operating-system environments have different UI paradigms (e.g. how macOS and Ubuntu has a single always-on menu-bar at the top, whereas Windows and other Linux desktops do not).
So you have two fundamental choices to make:
Use a single cross-platform GUI toolkit - which means creating a single GUI project, but restricting you to that toolkit's selection of controls and functionality, and generally subjecting your users to a (relatively) poorer user-experience, either because your toolkit does not use native widgets (e.g. Java, WPF, Qt) or because you cannot use a platform's native paradigms.
Write a new native GUI for each platform. This means more work, but a better user-experience.
For cross-platform GUI toolkits, the main options are:
Qt
GTK+
WxWidgets
For a comparison between the three, see this QA: Which, if any, achieves Windows native look: GTK+, wxWidgets, Qt, FLTK?
(TL;DR: WxWidgets uses native controls but is difficult to develop with; Qt offers the best developer experience but has many other bullet-points which you need to be aware of)
For a native UI for each platform you need to target, you'll need to familiarize yourself with each API:
Win32:
MFC (the API is ugly by modern standards, but does encapsulate the main Win32 UI paradigms and APIs, such as Common Controls. However, be prepared for an uphill fight to support latter-day UI features, such as High-DPI, bi-directional text and high-quality 2D rendering. GDI/GDI+ is on the way out, which means using Direct2D - which is fun because MFC assumes GDI)
UWP/XAML: If your application can be sandboxed (and run only on Windows 10) then you should take a good look at UWP/XAML (it's all native, so the CLR is not involved).
WPF: Using WPF makes it easier to create a high-quality user-interface, if you're comfortable with your application taking a dependency on the .NET Framework and writing UI code in C# - however the visual aesthetic of un-skinned WPF apps took a nosedive with Windows 10 (i.e. they're ugly) and WPF's default control set is very aneamic - but if you have the means (i.e. time, money, people) then you can get great results - and as a bonus the XAML for WPF is generally portable to UWP.
macOS: Cocoa - you will have a hard time doing this in C++. If you're targeting macOS I strongly suggest writing your UI layer in Swift (or Objective-C if you have to) and then linking-in to the rest of your application code using C++ bridges.
Linux: As Linux is just a kernel the set of "native" widgets depends on the desktop environment of the user - but most desktop programs seem to use GTK. And if you're going to use GTK then you might as well use GTK's cross-platform features to support Windows and macOS.
In conclusion: it's difficult and a lot of work. :) - and explains why many software titles today (mid-2017) often built as web-applications either on the web directly (e.g. Facebook, StackOverflow, SalesForce) or hosted webviews using Electron (e.g. Slack, VS Code, Atom) or some other hosted-webiew (PhoneGap apps, Spotify, etc).
I don't know if I had gotten it all wrong, so I'm asking for directions here.
Let's take for example, back in college, when you learned C++ and used Turbo C++ or GCC to compile, you get an idea of what a low level programming language is.
Now let's say I want to make a basic 2D video game, just as a personal project, nothing fancy, and I want to develop it using C++ just because. I'd code it using Visual Studio since it's a pretty good IDE.
Is it right to say "I'm going to use MFC" for this kind of project? (Consider the fact that I'd be using OpenGL).
MFC is a C++ framework that encapsulates the core elements of the Windows API. It's primarily intended for creating standard, windowed applications that the user interacts with on the desktop.
It comes with a built-in graphics framework: GDI. The one that was introduced with Windows, revolutionary for its time because it abstracted away hardware-specific details and allowed programmers to write general code that ran on any machine Windows ran on. But it was never particularly good for games; it was designed for Windows-style business applications. It was awesome for text (and is still arguably the best option that there is—have you looked at how Direct2D renders text lately?), and handled simple graphics, but consider that before alternative graphics-specialized frameworks like OpenGL were available, most game developers stuck with DOS, where they could/were forced to interact directly with the graphics hardware at a low level.
So if you want to use MFC and OpenGL together, you can, but I don't really see the point. The only real benefit you'd be gaining from MFC is a reduction of 100-some-odd lines of code that sets up the fundamental skeleton of any Windows application. For example, considering this sample OpenGL program, using MFC would essentially allow the WinMain and the MainWndProc functions to be buried deep in the bowels of the MFC framework code, rather than appearing directly in your code. But, like I said, big deal. The majority of your code is going to be OpenGL-specific, and MFC won't help there.
The only way it might make sense for the two to interact is if you wrote the launchpad/host for the game using MFC and GDI (i.e., the part that displays windows and dialogs on screen), and then the game portion itself in OpenGL (launched once you clicked a "Start" button on the dialog interface).
And of course, even if you wanted to do this, MFC is not your only option. There are tons of C++ frameworks for writing Windows applications. Everyone has their favorite. Despite what some may tell you, there's nothing wrong with MFC if you already know it and/or are comfortable with the Windows API. But don't waste time learning it. Use WTL instead.
You would NOT use MFC simply because it is meant for general application development giving you features and classes that you will most likely never use!
A good start would be to look at SFML http://www.sfml-dev.org/ or (my personal favourite) SDL http://www.libsdl.org/. These libraries were written to develop games or at least multimedia applications using them.
Writing a Game Editor in MFC can be a good idea though!
I want to develop native c++ windows application using windows API.
but i find it being difficult because i am unable to render the window and drag and drop components, change the location etc..
How can i view, drag and drop components like i can do in C# ?
May be there is no way to do. if so, what is the fastest procedure to design the application ?
If you like so much the drag and drop of components (and of course for good reason) why would you need to develop it using C++? You can use PInvoke if you need to call some C++ functions from C# code that are not in the .net framework.
But if you really insist, maybe you could try QT.
Using a library framework such as Qt is really the way you want to go. It makes things very simple and still allows you to write code in std c++ to keep most things very fast.
If you EVER have intentions of porting the code to a different platform than windows (whether it be Mac, Linux or even Android ... yes its possible), qt is definately the way you're going to want to go.
I can get an app up and running... smoothly in a few minutes using Qt but much longer and with more confusion using MFC.
Dragging and dropping 'widgets' to form a gui is very easy and possible with Qt's built-in QtDesigner!!! Check it out!!!
http://qt.nokia.com/downloads
Assuming you are using Visual Studio, if your app can be implemented as a dialog box, then you can use the dialog editor to lay things out. Otherwise, you just have to write code to create the windows and place controls. Look at the MFC examples included with Visual Studio.
Jeff Prosise's PROGRAMMING WINDOWS WITH MFC was one of the better books for learning how to do this, but I think it is out of print, and so could be hard to find.
Charles Petzold's PROGRAMMING WINDOWS is the bible for the Win32 API. Again, may be hard to find these days.
If MFC isn't your cup of tea, you could also look at QT, GTK+, or wxWidgets. There are GUI builders for each of those, but they are all pretty primitive compared to what you can do with C#.
As far as I know there is no ide out there that will let you "drag and drop create" standard win api windows like you would with C#.
Personally for that kind of application I always recommend Borland C++ Builder (Which is now Codegear Rad studio)
Although it is not standard API, it allows you to drag an drop and static linking is very easy, so you dont have to worry about redistributables
Imagine you are on Windows 7 and you have to write a GUI for a GRAPHIC application, (like a terrain editor, mesh viewer ..) which involves a great use of DirectX and OpenGL (so written in native C++).
If your goal is a multi-platform software then you should go for wxWidgets, but imagine you're doing a Windows' only app...what would your choice be? and why?
I'm supposing that the application would work on both XP and Vista/7 and obviously in the WPF case the UI will be managed, but it will call native functions by a C++/CLI proxy-like class
( will "bouncing" from managed-native and native-managed cause performance issues? ).
RAD Studio can also make the job
Enhanced in 2010! VCL (Visual
Component Library) for rapidly
building Microsoft Windows
applications now includes seamless
Windows 7 support, and graceful
fallback compatibility with Windows
Vista, XP, and 2000
Enhanced in 2010! Windows Vista and
Windows 7 API headers to fully
exploit the latest Windows
capabilities
New in 2010! Support for Windows 7
Direct2D API
you can also make WPF with Delphi Prism and wxWidgets with twinforms
If you are comfortable with your C++ skills, I recommend WTL. It is very lightweight and results in lean machine code. The Windows version of Google Chrome was written with WTL.
To minimize development time and maximize performance I would definite go with Delphi 2010 (Rad Studio 2010). You get native execution, direct interfaces with Windows 7 Direct2D API, and arguably one of the best IDE/Development environments available on Windows 7. What else do you want?
Larry Drews
TheSoftwareRonin
You might consider using Qt, even for a Windows-only app, simply because the Qt C++ API is so nicely done. Qt supports OpenGL and can be used in conjunction with DirectX.
In WPF, you can actually use DirectX Shaders to apply effects on interface objects, (here's a CodeProject article detailing development aspects) and it is expected that the support for this will continue to grow, so I would choose WPF as a development platform. Furthermore, it focuses on creating attractive user interfaces with a reasonable amout of effort, and I think this is quite important in building a Graphics oriented aplication.
will "bouncing" from managed-native and native-managed cause performance issues?
definitely, but since you write just editor (not a game, in general) it's not a thing you should worry about
WPF applications rendered by DirectX subsystem as i know. so if you using only DirectX it will be a good choice.
I would personally use http://sourceforge.net/projects/win32-framework/ to create any Windows based applications in C++. Otherwise I would just use VB.Net or C# because you can easily port code between both and the form designer is very useful.
MFC :: Just say NO for any kind of project.
Win32 :: Well, I can not really recommend using it.
wxWidgets :: I have used it and seen no problem, good choice.
WPF :: I have not and never will use it as it is .Net bound.
FLTK :: Also look at http://fltk.org/, probably has better OpenGL support.
Be sure to check out WDL ("whittle") by the Cockos team (headed by Justin Frankel of Nullsoft/Winamp fame).
It's an extremely lightweight C++ library that includes "WDL Virtual Window system."
I personally haven't used it, but I can vouch for some great software that's been made with it. Extremely efficient and lightweight apps.
Link: WDL
I can't really comment on wxWidgets, but WPF is vastly superior to MFC and good old Win32 API. WPF uses DirectX for rendering and there are some 3D support in WPF. Unfortunately this support is still somewhat rudimentary and not the most performant. You can actually get better 3D performance if you host a Windows Forms control that renders OpenGL (at least we had to do that in a recent project I worked on). If you want to do 3D rendering in a WPF application you could have a look at the XNA Framework. The next version of the .NET framework will also include improvements to WPF and I'm sure there will be better support for 3D.
How do you develop UI in MFC?
do you use any free libray, or usually develop from scratch?
There are always so many DLL files in a C++ developed software, what are them used for ?
What's the difference between MFC ActiveX Control and MFC DLL ?
Visual Studio 2008 enhances MFC by adding the 'Feature Pack'. This allows you to create MS Office 2007 style GUIs (amongst others), complete with a Ribbon Bar.
http://msdn.microsoft.com/en-us/library/bb982354.aspx
I cut my C++ teeth using MFC, but I'd recommend you look at Qt instead - it's a much more modern framework plus you get cross-platform support (Linux, Mac, etc.) for free. MFC is pretty much a dead framework IMHO (the Feature Pack was bought in and is actually a cut-down version of the BCG library.)
http://www.bcgsoft.com/
If you want to stick with MFC there is another popular GUI framework, by CodeJock:
http://www.codejock.com/products/overview.asp?platform=mfc
MFC (Microsoft Foundation/Frustration Class) is an old approach of Microsoft to provide an Framework to C++ developers. In those days it was the only framework offered by Microsoft so the approch is very old (Win95 I think).
The MFC is a toolbox consisting of String, Gui, Controls etc...
CString, CWindow, CTreeControl, ...
In addition it contained an component framework (ActiveX) and Gui based component framework
ActivX Controls that may include all of the parts of the toolbox.
All the functionallity is hosted in the mfc??.dll and other dll taht have become part of the Microsft OS itself and contains a lot of compatibility stuff of Windows. (Most of the applications including Word Excel, ... are implemented using MFC).
Today I wouldn't suggest to start using MFC anymore. If you have to care about MFC you are doomed but I would suggest to use one of the newer hype things of MS or use Qt or whatever Gui based toolbox.
Most of them are more modern than MFC.
Get yourself a good book to begin with. There are still some third parties controls if you do not mind spending a bit of money. Finally, codeproject has hundreds of MFC examples.
The standard book for learning MFC is this one.
Since you don't list the DLLs that are troubling you, I can't comment on them. However in native code it's common practice for frequently-used functions to be separated out into DLLs.
An ActiveX control is a COM (Component Object Model) "chunk" of functionality, designed to be accessible from multiple languages. COM has no specific connection with MFC, other than the fact that MFC can use COM components like any other MS product.
MFC DLLs come in two types, extension and regular. Regular DLLs are just like any other DLL. An extension DLL is more tightly integrated with MFC, can only be used with MFC applications, and can export MFC classes and functions.
How do you develop UI in MFC?
More often than not the MFC GUI will be defined as a Windows resource file that is compiled using the Windows resource compiler and edited using the MFC specific resource file editor that is built into Visual Studio.
But since the resource file is just plain text it can also be created and edited by hand inside any text editor.
What's the difference between MFC
ActiveX Control and MFC DLL ?
MFC is nothing more than a set of C++ library classes designed to wrap around existing Windows technology.
So for example the MFC ActiveX control is nothing more than a Windows ActiveX Control written in MFC and likewise the MFC DLL is a Windows DLL written in MFC.
I would also recommend taking some time to also learn a little about the underlying Win32 layer. In reality MFC is only a very thin layer over the top of standard Win32 so any knowledge of Win32 always comes in handy.