|
Is it coming, though?!
|
|
|
|
|
I just looked out the window: It's here.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Ha! those northy!
South hemisphere here!
|
|
|
|
|
So ... bush fires, droughts, flies, and spiders that are out to kill you?
I'll live with snow, thanks!
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
And episodes of "Peppa Pig" being banned because the theme of the episode was "spiders are very small and they can't hurt you".
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Seriously? I guess that makes sense over there ... mind you, my neighbour was bitten by a spider and had to take months of work because her arm didn't work - some of them in the UK are dangerous: e.g. the False Widow. But that doesn't use it's net as a trampoline to try and catch Drop Bears like some of theirs ...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Try restarting your window. That clears the memory cache, so it'll take a fresh look.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
"he managed to hack through the ice on the back side"
|
|
|
|
|
I have Visual Studio 2019 installed on my machine. I just built a C++ desktop app from template.
I will continue the shocking part of this story but first a little history...
Around 1993
Long ago (1993) I started learning C++.
The developers in my group at that time were writing a large program using Visual Studio 1,2,3, etc. and developing on the Windows SDK -- SDK style programming which was basically C wrapped up in Microsoft's way of doing things.
MFC : I Thought It Was Fantastic
Okay, but at that same time a fantastic thing was born: MFC (Microsoft Foundation Classes)
This was true C++ wrappers around the API calls. It was quite fantastic and I began to learn it.
It was kind of like C# before C# was released.
I was stuck between these amazing devs who knew Win API SDK style programming and the MFC (which used true OOP). The generation in front of me wanted little to do with these "unnecessary wrappers around the API"
But I continued into MFC.
Finally, around 1999 Microsoft announces C# and I am angry. Java-like? Throw away this investment into the MFC? Well, it'll be okay, because people will come to their senses and see that MFC is already doing all this stuff they're only promising with C#. Yeah, that's the ticket!
I Jump On Board C#
Finally, I jump on board the C# train and it becomes a rocket. It's the Windows API wrapped in OOP. There are missing things (as the .NET libraries become mature) and I understand how to get to those with pinvoke which is based upon my experience with (yes, Visual Basic) and knowing the Win API from MFC, etc.
We Now Return To My Original Shock
So, now, it's like 20 years later and I build a desktop app from the Visual C++ template and what do I see? Original Windows API stuff!!!!
It's the unwrapped, unvarnished message loop!!!
while (GetMessage(&msg, nullptr, 0, 0))
{
if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
It's the old RegisterClass (not related to OOP and classes but related to WNDCLASS).
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEXW wcex;
wcex.cbSize = sizeof(WNDCLASSEX);
wcex.style = CS_HREDRAW | CS_VREDRAW;
wcex.lpfnWndProc = WndProc;
wcex.cbClsExtra = 0;
wcex.cbWndExtra = 0;
wcex.hInstance = hInstance;
wcex.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_FIRSTC));
wcex.hCursor = LoadCursor(nullptr, IDC_ARROW);
wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
wcex.lpszMenuName = MAKEINTRESOURCEW(IDC_FIRSTC);
wcex.lpszClassName = szWindowClass;
wcex.hIconSm = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));
return RegisterClassExW(&wcex);
}
And where is MFC that wrapped all of this up in nice C++ OOP?
I don't know.
This is MODREN TECHKNOWLEDGY!!! The old has come back to haunt us!!!
This is 1993 tech, okay?
And I know lots of greybeards are going to chime in, "This is the special domain of geniuses and you just don't understand." I know. I know. But the MFC was so nice.
I blame C# for this travesty. Sorry...I'll crawl back over to the C# projects.
EDIT - MFC Desktop Template Gone from 2019?
I believe the Visual Studio template for building desktop apps with MFC is actually removed from Visual Studio 2019.
Here's the explanation of how to get to it in 2017 -- similar to previous versions of VStudio:
Windows desktop development with C++ in Visual Studio | Visual C++ Team Blog[^]
However, if you attempt to find that in 2019 you get no results (shown in following snapshots):
https://i.stack.imgur.com/ZRG43.png[^]
https://i.stack.imgur.com/REriZ.png[^]
The Desktop project template does not allow you to choose the MFC option in 2019.
It may be gone. Interesting.
It could be because it is 2019 Preview 2 and not in yet, but not sure.
EDIT 2 - Found Out How To Get MFC to Install
Ok, I found it way over on the right side in the installer.
There is one checkbox you have to select way over on the right.
That is independent from the item you can see on the left which says Desktop Development with MFC -- which I had already installed. Really terrible. You can see it at:
https://i.stack.imgur.com/ue4FM.png[^]
modified 30-Jan-19 10:03am.
|
|
|
|
|
Build the windows app from MFC rather than the win32 API.
Anyway, things change even slower in the kernel.
|
|
|
|
|
|
I went back to the Visual STudio installer and checked and it does mention MFC in the desktop tools installation.
https://i.stack.imgur.com/CBHX4.png[^]
Maybe I'm just not finding the right template project??
But, this was more about the fact that MFC was just left behind and ignored. Alas. Alas.
|
|
|
|
|
I just installed 2017 and it has MFC stuff in the templates still. Sure you didnt miss it?
|
|
|
|
|
2017 yes. But 2019 doesn't have it.
I could just be too far on the cutting edge.
|
|
|
|
|
Blimey, I cant imagine why they would drop it, it is still a very useful framework.
|
|
|
|
|
Munchies_Matt wrote: Blimey, I cant imagine why they would drop it, it is still a very useful framework.
I agree. But from a product standpoint I bet they hate it because they are like,
Random Product Manager at Microsoft Visual Studio: "Look people have C# if they want that type of thing and this is just a long-term maintenance and support nightmare."
|
|
|
|
|
I looked into it when it first came out in the early 1990s. My reactions then was that "This framework takes over so much of the program logic that it will hijack the entire application and make it extremely difficult to adapt to another [i.e. non-Windows] application!"
The application was planned for multi-platform - Windows was certainly not as dominant then as it has become now. Today, making a Windows-only application is perfectly fine. But as far as I have seen, MFC today is no less (rather more than in the beginning!) a "framework" in the straightjacket sense. It dictates how you write your application logic far more than I appreciate. I wanted to see it as a "library" rather than as a framework, a library that could be replaced by another library (on another platform) without affecting the program logic very much. It didn't appear that way to me, certainly not in the 1990s.
For some reason, I never got that same feeling with C# and WPF. Maybe that is because I have more experience now and simply ignore the elements that try to force me into an application design style that doesn't suit me. Porting C# applications to other platforms is not a very relevant question today, nevertheless I feel that I am the master, WPF is my servant. With MFC it was the other way around, as I experienced it.
|
|
|
|
|
Quote: I wanted to see it as a "library" rather than as a framework, a
Actually MFC is not an all or nothing framework - you can pick and choose what you want to use.
Just want to use their collection classes fine, or prefer to roll your own socket classes fine.
Can even mix MFC window UI components and good old fashioned SDK style.
MFC is really just a wrapper around the Windows SDK API
|
|
|
|
|
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!
|
|
|
|
|