Windows C++: a bit shocked
-
Richard MacCutchan wrote:
MFC is an add-on that does not come with VS
How dare you call it a...a... :(( add-on. :(( :laugh: I think they are silently dropping it in 2019.
-
I used MFC for quite a few years in my last job, and after climbing the learning curve, I actually got to love it.
-
Blimey, I cant imagine why they would drop it, it is still a very useful framework.
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.
-
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. :mad: Java-like? Throw away this investment into the MFC? :mad: 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!!!! :wtf: :wtf: It's the unwrapped, unvarnished message loop!!!
// Main 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).
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEXW wcex;wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS\_HREDRAW | CS\_VREDRAW; wcex.lpfnWndProc = WndProc; wcex.cbActually, 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 lo
-
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. :mad: Java-like? Throw away this investment into the MFC? :mad: 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!!!! :wtf: :wtf: It's the unwrapped, unvarnished message loop!!!
// Main 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).
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEXW wcex;wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS\_HREDRAW | CS\_VREDRAW; wcex.lpfnWndProc = WndProc; wcex.cbWhen you install Visual Studio 2015 and later, MFC is not installed by default. When installing tools for native, ALWAYS use the install components.
-
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 lo
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. :thumbsup:
-
When you install Visual Studio 2015 and later, MFC is not installed by default. When installing tools for native, ALWAYS use the install components.
-
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. :mad: Java-like? Throw away this investment into the MFC? :mad: 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!!!! :wtf: :wtf: It's the unwrapped, unvarnished message loop!!!
// Main 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).
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEXW wcex;wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS\_HREDRAW | CS\_VREDRAW; wcex.lpfnWndProc = WndProc; wcex.cb -
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 lo
It seems that good stuff never get out of fashion, even in software development ...
Find more in V-NET: connects your resources anywhere[^].
-
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.
-
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
-
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)
-
I just installed 2019 on a VM, make sure the individual component for MFC x86 was checked and it installed.
-
Richard MacCutchan wrote:
after climbing the learning curve, I actually got to love it.
:thumbsup: 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?"
-
MFCwere (are?) a thin wrapper aroundWin32(nowWinapi). If you miss them then the wrapper wasn't that thin, after all. :) -
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. :mad: Java-like? Throw away this investment into the MFC? :mad: 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!!!! :wtf: :wtf: It's the unwrapped, unvarnished message loop!!!
// Main 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).
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEXW wcex;wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS\_HREDRAW | CS\_VREDRAW; wcex.lpfnWndProc = WndProc; wcex.cbI 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: Yay, C!
-
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. :mad: Java-like? Throw away this investment into the MFC? :mad: 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!!!! :wtf: :wtf: It's the unwrapped, unvarnished message loop!!!
// Main 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).
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEXW wcex;wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS\_HREDRAW | CS\_VREDRAW; wcex.lpfnWndProc = WndProc; wcex.cbYou might like this blog?! ;P 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
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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. :mad: Java-like? Throw away this investment into the MFC? :mad: 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!!!! :wtf: :wtf: It's the unwrapped, unvarnished message loop!!!
// Main 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).
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEXW wcex;wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS\_HREDRAW | CS\_VREDRAW; wcex.lpfnWndProc = WndProc; wcex.cbSo my work is now cutting edge? That's a good laugh! :laugh: ;P
-
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. :mad: Java-like? Throw away this investment into the MFC? :mad: 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!!!! :wtf: :wtf: It's the unwrapped, unvarnished message loop!!!
// Main 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).
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEXW wcex;wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS\_HREDRAW | CS\_VREDRAW; wcex.lpfnWndProc = WndProc; wcex.cbFrom the release notes for VS 2019 Preview 2:
The following C++ ATL/MFC wizards are no longer available: ATL COM+ 1.0 Component Wizard, ATL Active Server Pages Component Wizard, ATL OLE DB Provider Wizard, ATL Property Page Wizard, ATL OLE DB Consumer Wizard, MFC ODBC Consumer, MFC class from ActiveX control, and MFC class from Type Lib. Sample code for these technologies is archived at Microsoft Docs and the VCSamples GitHub repository.
I assume that this means that MFC is still present. Perhaps it is not installed by default (you may have to drill down in the installation program, and select it...)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
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. :mad: Java-like? Throw away this investment into the MFC? :mad: 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!!!! :wtf: :wtf: It's the unwrapped, unvarnished message loop!!!
// Main 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).
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEXW wcex;wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS\_HREDRAW | CS\_VREDRAW; wcex.lpfnWndProc = WndProc; wcex.cbMaybe this is an effort to force C++ people to use WinRT/UWP instead of MFC. They will end up forcing everyone to switch to Qt.
