Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm learning about MFC.
Now I want to develop simple GUI Application, but there's a problem
First, How can I create empty MFC project? Visual Studio 2013 always give me a sample project, but I don't want it. I don't want to understand sample codes and edit it. I just want to write a simple project code by self from hello world.
Second, Is there a difference between starting with a empty mfc project, starting with a WIN32 application mode?
Third, I want develop a program with custom UI design, then Can't I use 'Dialog-based Mode'? Someone said me that "In dialog-base mode, It's hard to use Custom Design". Is it really?
A completely empty MFC project would be somewhat pointless because you would need to add back in the things that the sample code already has. For instance, every MFC program has a CWinApp-derived class and usually some kind of main window class (whether dialog or frame window). It might be easier to start learning the framework when you already have something working that you can edit, rather than trying figure out how to put the basic pieces together from scratch. But either way, you probably would want to get ahold of a good book to help explain the framework.
A Win32 Application sets up basic example code that only uses the raw Windows API (which is what MFC is built on top of and wraps). The WinAPI is very C-like. Out of the box, there are no classes or such things to make life easier. You would have to learn how to make them yourself... or use something like MFC since that's exactly what it is - classes the wrap the Windows API to make it easier.
"Custom UI design" is a rather vague phrase. Just what all are you trying to customize? Layout? Colors? Animations? Fundamental control logic? A dialog-based program is one of the simpler kinds, so if nothing else it's at least easier to start learning with. But as far as customization goes, it really just depends on what you're aiming to do.
Really though, MFC or the Windows API itself isn't all that great when you want to customize a lot of stuff. Sometimes you end up having to take over and re-implement more functionality that you would expect just to customize one little piece. Furthermore, even sticking to the stock controls and behaviors there's a lot left to be desired, such as a good sizing/layout framework. MFC was created a long time ago and in some ways hasn't been enhanced to keep up with the features people need/want/expect from the GUI framework these days.
Personally, I would recommend investigating other newer and more-feature rich GUI frameworks. In the C++ world, Qt is a notable one. In C#, WPF has a lot a nice things about it. For myself, even though I work in MFC all day long at my job, I usually do my personal projects in C#/WPF.
To create a simple application I would suggest to use .NET/C#.
Why not MFC: it is old, bulky and loads a lot of unnecessary stuff for simple application.
Why not Win32: you will write a longer and more low-level code with respect to .NET code.
Very generally speaking, Win32 API is a low-level thing, MFC is an old and bulky wrapper, .NET is a new and the-highest-level wrapper.
So, write a .NET/C# application. As far as I know, there is a way to appeal to Win32 API from .NET, just in case of very specific features. C# is not mandatory, but the code is much simpler and clear, than in C++.
As for 'Dialog-based Mode', right after you created an empty .NET/C# project in Visual Studio 2013, you can simply drag-and-drop desirable controls and then run your GUI application.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'll try to summarize my issue as concisely as I can:
I have a legacy C++ project that uses WinAPI to create and manage UI elements. I want to replace this with a more modern framework that supports OOP and has some kind of visual designer. I intend to achieve this by gradually replacing the old WinAPI-based code with the new framework (e.g I could introduce a new popup window that uses the new framework, while the rest of the UI would still use the old window procedures and whatnot)
My initial plan was to use Qt, since it allows me to conveniently wrap UI code in objects, which I can easily instantiate and manage. It also has a Designer that lets me create custom UI elements (including automatic layout management), a Visual Studio extension, and in general, past experience has shown me that Qt would suit my purposes quite well. However, users here have warned me that it does not cooperate well with WinAPI, and I would basically have to rebuild the app from scratch.
It was suggested that I use WinUI instead, i.e XAML coupled with C++/WinRT, as these supposedly offer the same flexibility as what I described above. I managed to successfully replicate the results of the "host UWP control in a Win32 app" guide, but there seems to be little useful material beyond that.
The Microsoft documentation is rather difficult to navigate in order to get a clear answer. At the moment, the guide above is leading me to believe that I'd still be stuck with using WinAPI, as there doesn't seem to be an obvious way to wrap UI code in objects, preferably those that I can derive from existing base classes (e.g some kind of basic Window object)
I have the following environment to work with:
Latest C++ feature level supported by MSVC
Visual Studio 2019
Windows 10 (i.e I don't mind if I'm no longer compatible with Windows operating systems)
What I need:
An explicit answer on whether it is possible to work with XAML and C++/WinRT in a similar fashion to how one designs UI code in Qt with C++. Exact parity is not necessary, I just want to eliminate the hassle of managing UI using WinAPI, where I practically have to do everything "by hand"
If the above is true, then where can I find guides for the various steps of the workflow? How do I make a "window object", how can I design a window with layout management, how do I handle UI events, etc.?
Are the above equally possible if it needs to be done in the context of a legacy WinAPI application that I am trying to upgrade?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I know this question has been answeared before, since i rad most of the answears already, but they didn't fully address what i was looking for, also i'm trying to get a heads up really really case-specific, since i need to develop an app really fast and i have almost no G.U.I. experience, so here is my problem:
I need to develop an application wich allows the input of some text fields (actually a database support-like would be awesome) and i need to store the inputs (like in a database, a .txt file could be good too if it would fasten up the developing)
once the input are fully stored (some text field must be unique) i need to pull some data from the database.
the final intention is to code a simple "random winner extractor" by simplying assigning a list of "number" to each entry and then calling the rnd function i will check who is the winner.
in addition to this i would love to be able to add a little animation to the whole gui (a gif would be enough)
Coming from vb6 Gui developing (that's the only G.U.I. developing experience i have so far) i searched from some good "drag and drop visual gui framework" and i bumped up into QT and into the .net Framework for visual c++ 2010, and i must admit i like them both, but i have no idea where can i get the Heads up to start coding in them... for example i have no idea how to change a text field value, or how to call the equivalent of "onChange" javascript handler for any of the forms (in neither the Qt or .net framework)
since i'm a little rusty with actual Event handlers and api codes,here are my 2 questions:
1.Between .NET and QT, for the sole realization of this single application, wich will be run in a windows computer, based on the "simplicity to learn and develop" wich should i choose?
2.Given the answear for point 1, where could i get some reference or material on how to easly understand the basics? (all the tutorial i found or tried so far gives me only case specific knowledge, but they won't cover overall function i need to know, like how to display a message box, or how to interact with the object values, or how to write down the values into a file...)
C++ is more difficult than C#. But it is more flexibel. C++ is an independent standard. C# on the other hand is safer to use.
Qt is cross platform. It can be used almost everywhere (except web applications) easily. .NET is for Microsoft and Windows only but common on that platform.
Qt is easy to learn and it is powerful. .NET is also powerful but I experienced .NET being harder to learn than Qt.
Qt is open source while .NET is closed source.
Pick the points that are important for you. I think the main question you should consider is: Do you intend to create a cross-platform application (today or in future)?
PS: Normally you should not ask such questions here since they tend to start endless discussions. The above is my personal opinion and hopefully it will be taken as subjective without the need of commenting it.
"Simplicity to learn and develop" is kinda subjective if you think about it and can rely on what you feel more comfortable with I think. I don't know much about .NET but you said you have a background in VB so maybe .NET might be the best approach for GUI development for you. If you know your way around C++ better, QT is surely the way to go, it's fast and powerful. I can't give you any reference material for .NET but you should definitely start with the qt documentation provided online. If you prefer to learn from video tutorials you can check out the Void Realms Qt youtube tutorials. The videos target Qt 4.7 if my memory serves me correctly but alot of the stuff he teaches are still more or less applicable with the newer versions of Qt. And finally, if you look in the examples section of Qt Creator (or online as well), they are some examples that are tutorial style and they can teach you some core concepts of Qt like the signals and slots system for one.
"simplicity to learn and develop" is what .NET is for, especially for database apps. But to get that simplicity use VB.NET or C#, not C++.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I started C++ programming not long before and I want to learn GUI programming in C++. I looked at windows programming and the syntax looks really difficult. So my question is, should I use windows api at all? If so, what are the advantages of windows api over a toolkit like Qt or Direct2D?
It somewhat depends what sort of application you are trying to build. Most frameworks provide a level of abstraction over the Windows API but do so at the cost of flexibility. You should try and pick a framework that's designed to build the sort of application that you are trying to build.
For building Windows client applications then the Windows API (I assume you mean the Win32 API) will do the job but is very low level. The advantage is it gives you a great deal of control and also forces you to learn how a Windows application really works. For a lot of people these aren't always positives.
If you are trying to create a more graphically rich application then Direct2D gives you this but also means that you have to learn COM and some would say this API is also quite complex.
If you are just learning C++ and want to build simple graphical applications then I would recommend checking out Cinder. It's perfectly possible to build simple graphically rich applications and games in a few hundred lines of C++. Here's an example of the Conway's Game of Life written in a couple of hundred lines.
Qt is also an option but I've not used it. Again it depends on you goal. For example one of Qt's features is cross platform portability, which may, or may not be important if you are just starting out with C++.
If you are just creating some projects for your own learning, then I would suggest that you create some GUI using Windows API without any framework. This will help you learn the internals on how things work (messaging, etc).
But to make any real world project you must choose existing framework (MFC, Qt etc) so that you can save a lot of time. You will understand the framework better if you create some GUI projects with plain Windows API SDK.
If you platform is only Windows, then you can in fact develop faster using .Net Framework. Of course there is also Xamarin that will allow you to write in C# for cross platform.
So what you choose depends on your goals.
With WinAPI you can use all Windows GUI features, controls, styles, respond to some rarely used messages etc.
It's easier to achieve native Windows look&feel.
Higher-lever GUI libraries, especially multiplatform ones, are usually "least common denominator", limited in many ways, with some controls (e.g. dialogs) reinvented just for the sake of it. You can patch your code with WinAPI calls, but that quickly turns into spaghetti.
For one, tools like Qt, OGRE, OSG, OpenGL etc are cross-platform. So you won't be stuck with using your program only on Windows.
If by windows API you meant VC++ with WM_PAINT etc, then it's worth learning it only for the sake of knowledge about how Windows works. The parts about dirty rectangles etc will intrigue you.
"I started C++ programming not long before.." - so I would advise to start with well-documented library such as QT. You'll have much to learn in C++ itself and to learn WinAPI at the same time will be twice (or more) difficult.
The answer in general depends on the requirements, and if you want to learn "GUI programming in C++" I'd say it means QT (or some other library/framework). I do not know any rich GUI projects now which are written on pure WinAPI (what for?). (If smb knows, please put a link here.)
But you can ask yourself another question - you want to learn C++ or GUI programming? :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am new to programming. I'd like to learn a new application programming language. I Googled and found the old MFC framework. I would like to ask: Is MFC still valuable?
I want to develop desktop applications. If not what should I choose to learn in depth?
If you want to develop desktop applications, then I'd recommend to avoid MFC and study Qt instead. Qt is quite powerful/flexible and using it won't lock you into single platform/OS.
First, you must have clear the platform where you want your applications to run; Windows? Linux? both?
In case you just care about Windows, MFC can be a good option if you want to do C++ native programming, which I suppose it's your case (otherwise, C# and .net could be a better way to start programming...)
MFC is a mature framework and once you get the basics, it will be as easy (or difficult) to use as any other library (e.g. Qt or TCL/Tk). IMHO.
I recently tried to use to MFC for a small client application.
After struggling for two days with trivial things (like how to change the font on a button!!) I gave up.
I gave a quick look at Qt and wxWidgets but (after having lost another couple of days), they seemed too compex for my task. Qt is probably the right way to go if you have time and/or the constraint to stay with a C++ framework.
It was not the case for me, so I decided to try Tcl/Tk to see what it had for me.
In its "tclkit/starkit" incarnation it allows you to create standalone GUI application with native look and feel. C/C++ code can be placed in a DLL that is embedded in the exe itself (no DLL hell, thanks!) and can be called directly from the Tcl script.
In two days work I almost finished the entire GUI with all the user interactions (enable/disable menaingful button, load listbox depending on other fields, ...) that would have taken weeks in MFC.
Tcl/Tk has its learning curve and may result unfamiliar to some but it repays many many times in productivity. Also, there are a lot of books, tutorials, examples, etc to learn from.
I would suggest you to give a look to see if it suits your need before going elswhere.
If you are happy with the document-view (MDI or SDI) nature of MFC go for it. It's great if your worried about distribution becuase you dont need a hefty framework, just a couple of DLLs. Don't expect rapid development without considerable background knowledge.
If you're interested in more modern C++ frameworks for Windows, consider using WTL and ATL instead of MFC.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I use wxWidgets to create test tools at work. I have always created the GUI by creating the widgets in code. I haven't tried any of the tools available that help to do this. How do other users of wxWidgets typically create their interface? If you use a tool, which tool do you use? If you use a tool, what advantages and disadvantages do you think there are for using that tool?
I've used wxFormBuilder for two reasons:
It's cross-platform and I needed something that would work on Linux.
I'm new to wxWidgets and I didn't want to spend lots of time futzing about with building the GUI.
I think it works quite well, and being familiar with similar GUI building tools (Borland C++ Builder, Jigloo for Java, Delphi) I found it easy to use.
If you stick with the paradigm of using wxFormBuilder to generate base classes, and then you make a class that inherits to layer your application specific logic on top, absolutely not hand-editing the C++ code wxFormBuilder generates, then it works well and you can easily update and modify your GUIs in wxFormBuilder again (and again...).
Advantages:
Can generate your base GUIs quite quickly, in a visual manner, without having to constantly look up the documentation.
Don't have to do as many code/compile/run cycles just to make sure your GUI is looking like what you expected.
The base class/derived class paradigm can make a reasonably clean separation of your GUI and business logic code.
Potential Disadvantages
Disclaimer: I've only used wxWidgets to create very simple, straight-forward GUIs, so haven't really pushed the tool to any limits.
Potentially the base class/derived class paradigm could sometimes get in your way if you are doing something too sophisticated with your GUI (OTOH that could indicate that you may need to re-think your approach.)
I had a situation where I needed a menu item when compiled for one operating system, but not when compiled for another. There is no logic in wxFormBuilder to support this. I ended up taking the short-cut of always creating the menu item and then having my derived class make it invisible if it was the wrong OS (not ideal.)
That's about it, I think.
What I find is that I often build the first cut at a GUI using a tool, and when it seems to be converging on the "final" form, I start to recode/refactor by hand.
Some of this depends on the tools, though, too. I'm not a big wxWidget fan.
You know, it depends.
E.g. if I need some standard behaviour, I usually use DialogBlocks for GUI because it is the fastest way.
If I need custom behaviour (e.g. my current project is cross-platform media manager whose GUI supports skins) then I do all GUI-relates things in code.
As for custom controls:
If a control does some project-specific thing, then I create it in DialogBlocks using the same project file (with other forms and dialogs used in this project)
If my control should be reusable (general-purpose control) then I create a separate project for it and create a keleton in DialogBlocks - add empty event handlers and class variables if possible, then write logic manually in Visual Studio.
That's it :)
You might want to look into using XRC/XRS files.
Though I must admit I haven't bothered to do so myself. Just generating static GUI code using wxFormBuilder (which has XRC support, btw) has been enough for all my (small-scale) GUI designs.