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.
Related
guys! I'm currently working on new cross-platform application (iOS, Android, UWP). I have graphical library for UI written in c++, using freeglut for opengGL.
The problem is, I don't know how to use this library in my UWP application. I have read a lot of information about all the wrappers for OpenGL, but they all for WPF or written in C++. I also know about Microsoft ANGLE Project, but it is written in the c++ too, but I need to write the application in C# language.
So, how can I modify my own library using excluding freeglut and import it into my C# application?
By the way, sorry for mistakes in my English.
So you want to consume your legacy C++ assembly in your UWP application?
You can create a Windows Runtime Component(Universal Windows) project, in which you need to include the assembly, and declare as many APIs as you want to expose, all marked with DllImport attribute.
Eventually, this WinRT component will do the Platform Invoke, and works as a "wrapper" layer between your legacy code and UWP application.
It's up to your preference which language you use for the WinRT component, C++ or C#, either way, you need to worry about struct/type mashalling and unmashalling.
After you're done with above, you'll be able to reference the WinRT component in your UWP application, and call the APIs you declared in that assembly.
The same way works for Microsoft Angle project as well.
You might find this post useful.
One last word, you might want to avoid using forbidden APIs, otherwise your UWP app won't pass the Windows Store Certification.
According to https://msdn.microsoft.com/library/windows/desktop/jj714080.aspx there is an option to use DirectX and some native API functions including LoadLibrary and GetProcAddress functions https://msdn.microsoft.com/library/windows/desktop/jj714080.aspx
This should give you ability to use any native dll.
You can try to make RuntimeComponent project and put it there. Also you can try clr oldsyntax option to use native code as it is.
How can i make buttons in c++ and handle them.
I am targeting win32.
Till now i have no idea of how to make graphical programs in c++ . I have come from JAVA and therefore have no idea of handling c++ events and building GUI
It will be of great help if you give the links to tutorials or could name the books to do so.
C++ is merely a language and the framework and operating system services whcih enables you to make use of the services using C++.
Java contains a GUI framework which has implemented across the platform. When you come to a native windows application, you have to rely on mainly two things, Win32 and MFC(a C++ wrapper of Win32 APIs). Win32 provides C based APIs which expose the operating system services.
For your specific questions I can answre like, You can use CreateWindow() Win32 API or CButton::Create() (MFC) to create a button. Also Visual studio provide a really good resource editor where you can manage the controls and make the message handlers.
The APIs are largely classified in to three DLLs
GDI32.dll - provides APIs for drawing
User32.dll - provides APIs to creates buttons windows etc.
Kernel32.dll - provides APIs to use operating system services like file creation, threading, synchronization etc.
As a Java programmer, it would be easy to adopt C# rather than C++. For you C++ might be going back to stone age where you've to hit the stones and make the fire, where in C# you can enjoy the easiness of a matchbox.
I'd suggest you to read following books to learn basic GUI programming under Windows
Windows Via C++ - (Win32)
Programming Windows with MFC - Jeff Prosise
Programming Windows - Charles Petzold
Making UIs is not part of C++ itself : you'll have to use a framework or rely on something else (like MFC in visual c++).
If you want easier way of building a GUI and manage your events, while still keeping your code portable, I suggest having a look at Qt : it's really good quality and delivered with a bunch of well-done examples. (license is LGPL so as long as you link dynamically, you can license your code the way you like).
A very good book to understand win32 api is http://www.charlespetzold.com/pw5/.
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.
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.