Windows C++: a bit shocked
-
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.
-
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?"
-
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 notice the event loop in the template still doesn't deal with the return from GetMessage being TRUE, FALSE or -1. For details on this little treasure of the Win32 API see the middle-bottom of the following page (under return value): GetMessage function | Microsoft Docs[^] Regarding MFC, I always found it a bit of a cludge in places and fairly incomplete. I often had to resort to Win32 calls to get stuff done. I recently had to do some additions to an old MFC project and started to think this wasn't all that bad...until I realised that a list control needs each line measuring to determine whether to show a horizontal scrollbar! Mercifully, you get a vertical one automatically. When the .NET framework/Forms/WPF came along this sort of thing just went away. The API was much more complete, along with the revelation that you can still use something that looks like C++ (C++/CLI, NOT managed C++ which needed taking out the back and shooting) to program it - it seemed like a whole new world! I still use C++/CLI rather than p/invoke as I find it much cleaner where I need to get down to low level stuff or interface with pure C++ libraries.
-
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.cbstandard microsoft practice. they do what they want and they don't care. if there is popular unrest that will imply negative $ outcome they'll think about it, but still do what they know is "for the good of the world". they can sustain negative $ outcome for a couple of years before they cancel the "for the good of the world" action, but in those years they will support countless trolls in the fight for their "good of the world" view. interestingly, my developing path was the opposite of yours. i switched from turbo pascal on dos to c++ on windows programming with mfc, that's what we used in the firm. we could do some things but i soon discovered that nor me nor the seniors knew how things worked and just to say that, in c or pascal, pointers are one of my strongest points and i knew (1998 year) c++ well enough so virtual destructors, copy constructors and assignment overloading were a piece of cake for me. then i got me the win32 forgers tutorial and later the petzold's programing windows. i never looked back at mfc or even oop for that matter. c++ is okay because you can switch to plain c anytime you decide. it is not c here that is important, it is the liberty to chose your style to organize the code and the liberty to pass by value or pass by reference as you like. unlike java that puts a constraint on you. oop and graphical user interfaces got popular at the same time and they are a perfect match. gui's best match for a data type would be a hierarchy of objects. other than that it has more weak points that strengths compared to common good programming practice. of course "in matters of taste, there can be no disputes". my taste is for freedom. i fight for a standard where c compilers would not issue a compile time error if you pass a "wrong" type of argument to a function without type casting, but a warning would be mandatory. let the juniors learn programming in the most strict type safe languages, but when they come to work in c they'll have to face complete freedom and responsibility.
-
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
-
standard microsoft practice. they do what they want and they don't care. if there is popular unrest that will imply negative $ outcome they'll think about it, but still do what they know is "for the good of the world". they can sustain negative $ outcome for a couple of years before they cancel the "for the good of the world" action, but in those years they will support countless trolls in the fight for their "good of the world" view. interestingly, my developing path was the opposite of yours. i switched from turbo pascal on dos to c++ on windows programming with mfc, that's what we used in the firm. we could do some things but i soon discovered that nor me nor the seniors knew how things worked and just to say that, in c or pascal, pointers are one of my strongest points and i knew (1998 year) c++ well enough so virtual destructors, copy constructors and assignment overloading were a piece of cake for me. then i got me the win32 forgers tutorial and later the petzold's programing windows. i never looked back at mfc or even oop for that matter. c++ is okay because you can switch to plain c anytime you decide. it is not c here that is important, it is the liberty to chose your style to organize the code and the liberty to pass by value or pass by reference as you like. unlike java that puts a constraint on you. oop and graphical user interfaces got popular at the same time and they are a perfect match. gui's best match for a data type would be a hierarchy of objects. other than that it has more weak points that strengths compared to common good programming practice. of course "in matters of taste, there can be no disputes". my taste is for freedom. i fight for a standard where c compilers would not issue a compile time error if you pass a "wrong" type of argument to a function without type casting, but a warning would be mandatory. let the juniors learn programming in the most strict type safe languages, but when they come to work in c they'll have to face complete freedom and responsibility.
K&R C is great / required for writing interrupt handlers and low level drivers - those tasks assigned to a few selected bit fiddlers with at least ten years of experience. They can handle the freedom and responsibility. In the old days, they were assembly coders; today they are K&R C coders. It was said that the core part of Lotus 1-2-3 (for the below 50y: The grandfather of spreadsheets) was coded in assembly to fit on a 360 Kbyte floppy. Today, you might have to code in C for your code to fit on a memory stick :-) ... It sometimes seems like application developers have completely lost control over code size. Yet: I don't think the solution to that problem is to ve them the "complete freedom and responsibility" of K&R C - preferably not even C++. Even though the freedom is not "complete", it is too high, even in 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.cbNice post. I understand exactly where you're coming from. One bit I can add is that I can remember, about 15 years ago, taking a relatively large application written in C++/MFC and recompiling it with C++/CX, adding .Net features, hooking it up to WCF, and even having it support auto-install when new versions were available. As far as I was concerned, that was the future. Little did I know how strongly Microsoft was hated. Why didn't C++/CX catch on? Because it was Microsoft-only, and that meant you couldn't write software for the 5% Mac/Linux market that zealots struggled mightily to target. Then Java comes along and, though it does have some strong points, it really has nothing over VB other than it's not Microsoft. Finally, someone figures out the right coding gymnastics and mystical incantations to get javascript to work in a browser. True, the resulting software was and still is vastly inferior, but it does have one thing going for it: It's not Microsoft! So now a generation of developers is condemned to a world where javascript is actually considered capable of making production-quality code because the users have been conditioned to accept it. So here we are now writing software whose responsiveness would make the 90's VB guys laugh all while laboring under platform burdens: *Types, what's that? *Threads, you mean link on my shirt? *Oh, F5? Yeah, don't touch that. *No, don't use that menu, that's the browser's menu. Use the menu within the menu. *No, that window can't be moved. It's just drawn to look like a window. *Sorry, you need Internet access to use the software, but have I mentioned that it doesn't require Windows to run? Yeah, I know most people still run Windows, but Windows isn't open source!
-
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.
-
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: 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. :sigh:
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?! ;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!
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. :laugh:
-
So my work is now cutting edge? That's a good laugh! :laugh: ;P
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. :wtf:
-
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 had a look at my VS2019 installation. I had to install the Visual C++ MFC x86 and x64 before I could create a MFC desktop application. All working as expected now.
-
Maybe 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.
