|
That's the Win32 template, and hasn't been updated since Visual C++ 6.0. AFAIK MFC is an add-on that does not come with VS.
|
|
|
|
|
|
I used MFC for quite a few years in my last job, and after climbing the learning curve, I actually got to love it.
|
|
|
|
|
Richard MacCutchan wrote: after climbing the learning curve, I actually got to love it.
It's really a very nice library. Wrapped up things very nicely.
|
|
|
|
|
Most things, yes. I still use it and run across overlooked things on occasion.
What is really angering me right now is how many bugs I have run across and they seem to have zero interest in even addressing them. For example, if I do a build with MFC in a static library my app can't access any 'built-in' resources like bitmaps. This means things like the file browser control won't have bitmaps on its button.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Rick York wrote: how many bugs I have run across and they seem to have zero interest in even addressing them.
Yeah, I think MS has definitely stepped back from MFC. I'm sure they see it as a product pain point since few(er) people really use it. And that's too bad.
|
|
|
|
|
Actually, I pity that the mainloop didn't catch on as a programming model 
I am not talking about the mainloop itself, but the idea of event-driven programming - designing and implementing your application as a state table: The FSM driver is 20-30 lines of code. Whenever something happens - an event - it indexes the 2D state table by the current state and the event, to find the action to perform and the next state. The state table is where the program logic is expressed.
The action part is application specific code, but you'd be surprise by how few different actions are required, and how simple and fucnctionally isolated they are. 95+ percent of traditional program flow control is replaced by the "next state" logic. In a properly designed FSM application, each state tansition and associated (when required; it often isn't) action is so rapid that there is very little need for any preemptive scheduling (which 16-bit Windows didn't have).
In a proper FSM design, event transition is conceptually instantaneous, from one consistent state to another consistent state, avoiding all racing conditions. "Synchronzing" is not a relevant concept. Complete error handling is very easy to achieve: For every emtpy state table entry, i.e. any state/event combination for which there is no well defined meaningful transition from the current consistent state to another consistent state, you fill in an error action. Any table entry that doesn't have a (normal or error) action filled in will glare at you, reminding you: You must handle this error!
To keep state tables to a moderate size, it is common to accept a few well defined "state variables" accessible for testing and setting from the action routines. In some FSMs, the logic of testing some of these variables are put into the state table: Each state/event entry may list a small sequence (usually no more than 3 or 4) alternate actions guarded by logical expressions on the state variables.
Probably the most complex protocol in the entire OSI protocol stack family, the X.225 Session Protocol, is described by 32 states, 80 events, 79 predicates and 34 transition actions. The 79 predicates can all be expressed as a one-line boolean expression. Most of the 34 actions fill less than 50 lines of code (assuming a proper service interface to the Transport layer). From an FSM modelling point of view, X.225 is a beauty! (I am not saying that the protocol is, I am talking about the modelling of it!)
The old Windows message loop model is ideally fit to this kind of modelling. That's what I am missing: That sort of modelling!
If I, anno 1985, had had the divine power to choose between steering the software world into OO or into FSM, I would definitely have chosen FSM! I still think so - maybe because I learned to code in a style that adopts at least 75% of the OO benefits even without a trace of OO language syntax. On a solid FSM foundation, that coding style becomes quite natural. It has been shown empirically that OO concepts certainly does not naturally lead to FSM style of thinking!
You can do FSM implementation style even within a traditional sequentially-algorithmic framework, if you can succeed in casting everything that happens into one homogenous "event" concept. (That can require some effort!) The major problem is that your co-workers probably has no clue about FSM modelling and want to cast ten minute computations into single state transition actions, and might challenge you into a fistfight if you don't accept it... Computer kids are not trained to do FSM today. That is a pity.
If after that fistfight you need to calm your nerves a bit, search up some old telecom guys. They know what FSM is all about!
|
|
|
|
|
Very interesting post, could almost be an article. Better write one up, because FSM application would be very interesting.
I agree with you about the program logic part. FSM would make it completely simple technologically and maybe that part of the message loop should be handled that way since it simplifies a lot.
OOP : Just Code Organization
OOP is just a way of organizing code though and that is what most of the world needs: code organization. Code organization (when done properly) allows maintenance to be done quickly and by a large number of people.
Data encapsulation (think hiding algorithms) allows more people who don't necessarily understand the ugly innards of the algo itself to still do maintenance fixes since code is organized into components that work properly as black boxes.
That's what I thought was nice about the MFC wrapper. It organized some things that I didn't want to know how they worked so I could put them together in ways to build something.
Slow Down & Write K&R C
If only we all had the time to slow down and write programs like the K&R C book. But we don't. Things must be hidden and hidden means there will be things I don't understand. Not my first choice but I have to build a product.
I hope you'll write up an article on FSMs. It would be a great read.
modified 29-Jan-19 16:07pm.
|
|
|
|
|
It seems that good stuff never get out of fashion, even in software development ...
|
|
|
|
|
When you install Visual Studio 2015 and later, MFC is not installed by default. When installing tools for native, ALWAYS use the install components.
|
|
|
|
|
Yeah, someone had kind of already pointed that out, but that doesn't seem to be the problem.
I went back and checked the Visual Studio Installer and it shows that I picked the option for MFC:
https://i.stack.imgur.com/CBHX4.png[^]
|
|
|
|
|
I just installed 2019 on a VM, make sure the individual component for MFC x86 was checked and it installed.
|
|
|
|
|
Show me how to get to the project template please. Grab a screen shot and post.
if you need an easy way to post the screen shot.
1) go to Electrical Engineering Stack Exchange[^]
2) open any question
3) paste the image into an answer and it will create an imgur link for you.
4) grab the imgur link and post here
You don't have to save your answer -- it's just an easy way to get an imgur link
|
|
|
|
|
Open the Visual Studio Installer
For Visual Studio 2019 Preview, click "Update"
Click "Individual Components"
Scroll all the way down
About 8 lines up is "Visual C++ MFC for x86 and x64"
Make sure it's selected (it does NOT automatically select)
Also select "Windows Universal C Runtime" (at the bottom)
|
|
|
|
|
Ok, I found it way over on the right side in the installer.
https://i.stack.imgur.com/ue4FM.png[^]
Not easy to find. And very unexpected since the other main item shows MFC as part of the toolkit that is installing.
|
|
|
|
|
MFC were (are?) a thin wrapper around Win32 (now Winapi). If you miss them then the wrapper wasn't that thin, after all. 
|
|
|
|
|
Orginally it was but over time it has become a bit thicker.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
The wrapper around COM was a thick one, if I remember correctly.
|
|
|
|
|
I never did MFC -- or VB for that matter -- and I couldn't get my head around Borland's TWindows or whatever it was called. And I only ever dabbled in C++.
So I was (am) very glad to find that WinForms in .net (with C# of course) was (is) so easy to use.
On the other hand, I may be back to using just-plain-C soon -- to write packages for use in Python. ![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
Yay, C!
|
|
|
|
|
PIEBALDconsult wrote: So I was (am) very glad to find that WinForms in .net (with C# of course) was (is) so easy to use.
I agree. C# WinForms seriously took over and I left all my C++/MFC behind. Alas. 
PIEBALDconsult wrote: On the other hand, I may be back to using just-plain-C soon
PIEBALDconsult wrote: Yay, C!
Yes, I agree. Or even yay, C++ (console-based like the old K&R C, but C++ would be nice.)
Unfortunately there isn't a lot of call for that type of code. Arduino (embedded) allows me to do that kind of coding. But then sometimes over there I'm like, "Why can't I do X easier? I'm limited by this doggone framework."
|
|
|
|
|
You might like this blog?! 
https://moderncpp.com/
From someone who has never stopped working on C++ UI and now works at Microsoft
Basically the Microsoft recommended way of making C++ UI on Window is through UWP. And UWP is better used in C++ with moderncpp (still work in progress last I know) but can be done (in released fashion) using C++ /Cx
|
|
|
|
|
Super Lloyd wrote: And UWP is better used in C++
Hmm...I was trying to find out if you could build XAML (UWP basically XAML) UI and C++.
WPF never did get to C++ you were stuck in C# basically.
And I'm not sure that moderncpp is still going. It mentions Win/RT which I believe was left behind by MS also.
You really can't tell where MS is going with C++.
They're kind of leaving it behind....but they're kind of supporting it via Win API /SDK type of framework which is weird and old.
MS probably has no idea theirselves. 
|
|
|
|
|
Well.. UWP is a failure but.. it has some redeeming qualities nonetheless.
- All new devices API (like GPS, accelerometer, etc..) they are UWP
- (relatively) easy to mix and match DirectX and XAML (i guess if you are a game developer might be good? dunno you might go 100% Unity anyway)
- Best Microsoft provided API to write GUI application in C++ IMHO, or at the very least the most modern one
- easy deployment, but stringent limitations, so it's a tossup
|
|
|
|
|
So my work is now cutting edge? That's a good laugh!
|
|
|
|
|
That's very cool because I was thinking about Win API and MFC --- where would anyone ever learn it nowadays??--- even though it is still supported.
It doesn't make any sense because someone has to be doing legacy work at least and there are plenty of examples at MS site that show that they are using Win API type of tech and when Win/RT released they were showing all the samples as Win API even though the tech is ancient.
I mean, it does still work though. MS is confusing. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
add-on. 
