|
|
I didn't claw my way to the top of the food chain to be a vegetarian.
Pass the bacon. I'll finish it off.
|
|
|
|
|
I like it difficult...
I want to make that C++ (with MFC if possible) and C# work together in .Net Core.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
we're still in the dark ages, using MFC/C++ with Visual Studio 2019 (16.4.5) and not having particular issues.
i can create c++ console app and MFC app.
I'd rather be phishing!
|
|
|
|
|
Really? I have Visual Studio 2019 16.6.4 Community Edition here at home and I can't create a console c++ app with MFC and before I could.
EDIT:
Now I can create it with the new precompiled headers, thanks to the tip by David Crow in the message below.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
modified 28-Jul-20 16:51pm.
|
|
|
|
|
No, Mickeysoft knows better than you what you need and what you don`t need. Or when you are going to need it and when you have to update to new and shiny, with butt ugly and monochrome obviously being Mickeysoft`s new shiny.
I have always said that my current installation of Win 7 would be my last. Well, my PC died with a bang yesterday, so I guess it`s time to move on.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
modified 28-Jul-20 12:28pm.
|
|
|
|
|
Nelek wrote: You can't create MFC C++ console projects anymore.
What happens if you opt for Windows Desktop and then Windows Desktop Wizard?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Wohooo....
That's it ![Jig | [Dance]](https://www.codeproject.com/script/Forums/Images/jig.gif)
partially 
It makes the new console APP with the new precompiled headers
#include "pch.h"
#include "framework.h"
But if I open an old project (working on them last month in Visual Studio 2017) with the previous
#include "stdafx.h"
then... no way.
At least the Visual Studio 2017 professional at work still can use it.
There must be a way without having to "copy + paste" the whole old project in a new "pch.h" structure, only have to find it.
But at least now I can continue doing my tests at home if I start a new project. Thanks for the tip.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Thanks for the warnings! I am still in the C++ and MFC world although we are slowly moving away from MFC. We will not be moving from C++ though.
Anyway, I haven't created a new project in many years. I had nothing but problems the last times I did so I just stopped trying. Now I have a few sample projects I always copy and adjust. Mostly because I have them set up with all the targets for 32/64-bit mode, MBCS/Unicode, Static/Dynamic RTLs, and Debug/Release builds - all 16 combinations of those options. I have never figured how to do that in the IDE so I just don't bother. I find it easier to copy, rename, and edit than to it is deal with that stuff in the IDE. They still have some things broken when I try to sort out debug file output options. There again, I don't bother - hand editing saves the day. It is cumbersome but at least it works. That's what annoys me the most : I try to do stuff in the IDE and it breaks things in the project file. Eventually, I figured how to do them by hand and I stopped wasting my time in the IDE on that kind of thing.
"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: I find it easier to copy, rename, and edit than to it is deal with that stuff in the IDE. They still have some things broken when I try to sort out debug file output options. There again, I don't bother - hand editing saves the day.
That was going to be my next move.
But... do you use the latest Visual Studio 2017 or 2019? Because I I can't even compile a previously valid project (which at work with 2017 still compiles fine)
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
That is odd. I use both VS2017 and VS2019. I never share project files between them. Each version has its own project files and I always keep them in separate subdirectories named VS2017 and VS2019 which are at the same level as the Source. I recently migrated over to VS2017, about a month ago, and I always copied the 17 files to the 19 directory and loaded them up, adjusted the SDK level, and everything worked.
I have not tried to share a project between versions because it never occurred to me that it could possibly work.
"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?"
|
|
|
|
|
Well... at work I only have the 2017 and we want to do tests with .Net core so I had to install 2019 at home.
Rick York wrote: I recently migrated over to VS2017, about a month ago, and I always copied the 17 files to the 19 directory and loaded them up, adjusted the SDK level, and everything worked.
Somewhen in the future we will have to port the BIG project to .Net core, and (AFAIK it is not expected that VS2017 will work with .Net Core) we will have to open all solutions in 2019 to compile them within the correct framework and with the target sdk.
So I started now with just open and see what happens. And it "works" as expected... wrong 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Sorry to read you have to move to .Net. You have my condolences.
"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: Sorry to read you have to move to .Net. You have my condolences.
Very kind of you 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I never left MFC because I refused to, back then, to use interpreter, garbage-collecting Java or its knock-off, interpreter C#. I use the latest C++17/20 community compiler, VS2019, and for free. The IDE serves me well too and I can configure it to compile today on any platform and machine setup I want. Every few years I have to re-seat my programs, though, since their MFC under-pinnings do change over time, the pch.h being one of them. From my perspective, Microsoft's most brilliant move was to humbly throw C# onto the Github code dump, hire Herb Sutter, the C++ ISO committee chair, and change all its docs to C++ examples. The code I daily write with modern C++ in modern MFC connecting to ultra-modern MFC GUI libraries like BCGSoft's BCGControlBar GUI library, is becoming more and more ODR compliant and maintainable, and even elegant. Doggedly hanging onto past versions of past versions of your programs (not to mention OSes), as well as past IDE versions are, IMO, not taking advantage of the 1000s of paid developers improving them. And as for C++, I am eagerly waiting for C++20 with Modules and C++23's Networking so I revamp my many MFC projects and evolve away from problematic dllimport/dllexports and Winsock2 (C++23 Networking will look very much like Winsock2 is my guess). Will it take time to re-do my projects? Yes. But this is where technical-debt comes from: taking the easy way out until everything breaks. Herb Sutter said in one of his posts that there were ~200 papers addressing/modifying/correcting C++ features last year, up from ~125 the year before. There is no comparison in long-term robustness of a language supported by the world's voting body (ISO) to a company who is only beholden to its shareholders (think: Microsoft's C#). Of course, if you are writing programs that don't need to survive the test of time, then I guess interpreters will do. I don't have that option. 40 years ago, Bjarne Strustrup invented C with classes and transformed programming with his principles. 29 years ago, Microsoft went all in on C++ and produced MFC. In the past few years, Microsoft has elevated MFC back on top. Go Microsoft. Excellent use of your trillions of dollars. Now, back to my MFC programming, but I thought it was worth the time to describe the other side of views on MFC. Avoid updating VS is silly advice.
|
|
|
|
|
rtischer8277 wrote: Avoid updating VS is silly advice.
Not if you don't have the time / mood to re-do all your work.
I have given the "heads up" for the people to avoid surprises like mine. That from one day to the other... pam, you HAVE to.
This way, the ones that want to keep it up to date as you (and actually me too) have the possibility to plan it.
The ones that don't want to be forced to update... now they know, they have to stay in their current version.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I hit this wall quite a while back. I'm frozen at VS2017 15.7.6 because the subsequent versions of VS2017 broke the compiler for some of our legacy projects. Any VS version newer than 15.7.6 will result in memory buffer overflows while compiling these projects. Granted, these particular projects use an excessive amount of shared memory storage and other likely non-optimal code practices, but the older compiler handles them just fine.
|
|
|
|
|
So many people are so quick to jump on use of mfc... lol
I have to use a variety of technologies at my job. We have a large project in MFC, several C# WPF apps, and then many many flavors of embedded applications, some bare metal, and some have OS's (linux, threadX, even GHS integrity). There are even some older 16 bit windows programs that customers STILL use which I refuse to work on...
Anyhow, I can most definitely understand how people use MFC still... there is simply no time to convert everything. And if you are adding on to someone else's native project via DLL's, bringing in .NET will cause too many managed-unmanaged transitions and give you a slower end result.
Back to your question. I have 2019 installed as well. I have no option for wizard creation of an MFC "console" project. But, I do have one for a Windows console project. I was able to pick this one, it created the project. I then went to project properties and picked "Use MFC" and then I added "#include <afxwin.h>", and then I was able to use some MFC. Yes, I agree, it did not do everything for me, but it definitely wasn't that hard... I feel like maybe I had to do this before and they used to have an option for "include MFC headers" when you made a Windows SDK console project. Guess that is gone.
|
|
|
|
|
DanM2 wrote: So many people are so quick to jump on use of mfc... lol
Need to add functionality to a legacy project
DanM2 wrote: Back to your question. I have 2019 installed as well. I have no option for wizard creation of an MFC "console" project. But, I do have one for a Windows console project. I was able to pick this one, it created the project. I then went to project properties and picked "Use MFC" and then I added "#include <afxwin.h>", and then I was able to use some MFC. Yes, I agree, it did not do everything for me, but it definitely wasn't that hard... I feel like maybe I had to do this before and they used to have an option for "include MFC headers" when you made a Windows SDK console project. Guess that is gone.
My biggest rant was not for the I can't create a project with MFC (although I hadn't found the "C++ Windows desktop wizard" yet).
My biggest problem is that the old projects with #include "stdafx.h" won't compile now because the new standard is with #include "pch.h" and #include "framework.h". So far I have added the VC++ v141, I have edited project properties (but not the project file directly) and tried to add it manually... that didn't work.
I have given up for a while, because I have started my tests in the new structure and want to finish them first.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Yesterday we had 6 or 7 brown outs / electric flickers due to weather and then fix.
My cable modem and wifi router (separate units) are powered on the same home circuit and got power-cycled 6 or 7 times also. It was really annoying and sent me on a search for a UPS.
But as I read about UPS it seems as if they are all a bit dangerous. So many reviewers say that their units emitted sparks and/or fire and if they had not been home when it happened it would've been disastrous.
What is your experience with this? Are these things safe?
I was looking at APC ones but then also saw this one which seems good.
CyberPower CP1000AVRLCD Intelligent LCD UPS System, 1000VA/600W, 9 Outlets, AVR, Mini-Tower [^]
Any experience with any of these? Thanks for any reccommendations.
|
|
|
|
|
I've had a UPS for years and the only problems I've ever had is the battery goes out every few years.
I've got a CyberPower 1500
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
Thanks for the input. Good to know which one you're using. 
|
|
|
|
|
My personal unit is an APC 550 which I've had for about 9 years. I got about 3.5 years from the first battery and the current battery is 5.5 years old. [Either I got lucky or the batteries are better.] This unit beeps and warns when the battery is failing, and it was easy to replace.
My work unit is a Tripp-Lite ECO580, and it's about 4 years old. Yesterday I discovered the battery is completely dead when I experienced 8 brown outs (very unusual), and my monitors went dead each time. The monitors are plugged into the battery side while the laptop is plugged into the surge protection only side.
Before buying a unit, ensure the battery can be replaced.
My first unit (cannot remember the brand) did not have a replaceable battery, so when the battery failed I had to recycle the entire unit. Both it and the APC cost about $75 USD, while the price for the battery for the APC was $25.
BTW: the units I'm familiar with have 2 rows of outlets -- one is surge protection only and one has surge protection + battery.
Plug only necessary items into the battery side. My personal unit has the CPU, monitor, cable-modem, and wifi router plugged into the battery side -- other items are plugged into the surge-only side. The battery power of a home unit is limited, so the more devices you have on battery, the faster it is expended.
Use the home unit to protect from brown-outs and provide time to gracefully shut down the system in the case of a full power failure.
|
|
|
|
|
Great info. I will keep these things in mind as I research what I will buy. Thanks very much for sharing.
|
|
|
|
|
I did a quick search on surge protection. While the UPS has surge protection, one article suggested buying a separate surge protector to protect the UPS. A strong surge can damage the UPS, and a surge protector is cheaper to replace than the UPS.
This makes sense. The surge protection capability of a device is limited an erodes with usage. An old surge protector is nothing more than a power strip; it's necessary to replace surge protectors on a periodic basic. This article[^] explains how surge protection works.
I found several articles that recommend replacing the surge protector every 2 years, and if the unit is 10 years old, it's worthless as a surge protector.
It's a good bet my APC has no surge protection left, and the surge protector on my main TV is 15 years old and the one on my smaller TV is even older ... so I'll be making purchases this weekend.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
