|
David,
Re: Quote: It is somewhat unusual that you need to pull this file into your project... it means that your project may be extending MFC functionality relating to OLE.
I am not intentionally doing anything with OLE. I can google and see that it means Object Linking and Embedding but in this app I barely use the user dialog. I did get rid of something and now when I capture the Output windows that file is no longer there. I now get a successful build.
We are working on moving up to VS 2015 and having similar problems with it on another computer. Now is a good time to perform a bunch of searches and get rid of any detritus that has accumulated over the years.
Thank you for your time
|
|
|
|
|
There is no point going to VS2015 it's obsolete you need to go straight to VS2017. It will import and adjust most solution files automatically and is fairly reliable at it. It also has all the MFC code source files because MFC is no longer sold or directly supported by Microsoft as it has been replaced.
VS2017 is also free for individual or small companies under it's community edition which is identical to the full product save it excludes direct support and the team workspace and code share options are disabled.
The only time you now need earlier versions of VS is if you need to have code for Windows O/S earlier than XP. Every Windows O/S from XP onwards can be targetted by VS2017 as well as Android, iOS Mac, Unity3D, Linux Command line and some new ARM mobile phone stuff.
I have uninstalled all my earlier versions of Visual Studio there is no situation I have found they are ever required.
In vino veritas
modified 23-May-17 2:05am.
|
|
|
|
|
leon de boer wrote: MFC is no longer sold or directly supported by Microsoft as it has been replaced.
When did that happen?! 
What replaced it?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
.NET is Microsoft replacement framework if you open VS2015 or VS2017 it's everywhere in the templates at the top of the project settings.
I quote from May Wang at Microsoft in 2015: "MFC is limited to Windows desktop apps, and you cannot currently develop "Modern" or "Universal" apps that target the Windows Store, phone devices (including Windows, Android, and iPhone), MFC is not slated for any investment at this time."
They then went on to release the sourcecode even in the free community edition of Visual Studio which was there equivalent of saying up to you to support it yourself going forward if you want to use it. The code itself no longer has any commercial value to MS.
That is pretty much by the book end of life cycle for software development 
In vino veritas
|
|
|
|
|
Thanks. I agree with what you've said, but what replaced it as far as building native desktop applications?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: I agree with what you've said, but what replaced it as far as building native desktop applications?
MFC is actively maintained for Desktop development. The latest version MFC 14.10.25008.0 was released back in March 2017.
Of course everyone is encouraged to move towards adopting the modern Universal Windows Platform.
Best Wishes,
-David Delaune
|
|
|
|
|
MFC14 is from VS2015 it only supports .Net 4.6 and later .NET 4.6.1
They patched a few dropdeads in it for the release of VS2017 so it supports .NET 4.6.2.
The history is clearly covered in Wikipedia if you need to reference:
Microsoft Foundation Class Library - Wikipedia[^]
You will note the major revision revision number has not changed from VS2015 to VS2017 on those releases unlike earlier situation and that is a direct consequence of no further development.
As we speak right now MFC is currently broken again under .NET 4.6.2 on Windows 10 after the anniversary update is applied and now .NET 4.7 has been released. It's been like that for months so lets see how long it takes them to fix and support 4.7 as an indication of the support for MFC. Note VS2017 auto updated and downloaded WPF changes so it was compatible with .4.7 basically two days after .NET 4.7 update was released and it made it into the advertising blurb (Announcing the .NET Framework 4.7 | .NET Blog[^])
In vino veritas
modified 30-May-17 0:41am.
|
|
|
|
|
If you mean what does Microsoft marketing want you to use to program desktop apps then the answer is C# with .Net that was the whole push with VS2017 you actually have to select to install C++ as an option with VS2017. I don't know how successful they were with it, there was considerable pushback at them over the C++ issue.
As a fulltime commercial programmer I have always programmed on the Windows API so it all means little to me because I would never waste my time supporting any of the frameworks they all come and go. Once you have you own library sets there is little attraction in any of the framework groups. So I really want nothing more than a functional C++ compiler with a good IDE and debugger which VS2017 has in spades.
I probably represent the problem for MS compiler marketing that they need to sell me something and there is very little I need from them
Anyhow here is the Desktop Marketing blurb for C++ from VS2017 make of it what you will (but notice it's an option not the default install as is MFC within that)
Windows desktop development with C++ in Visual Studio | Visual C++ Team Blog[^]
I suspect somewhere down the track customers like me will end up using just the IDE with a linked compiler module. MS has an interesting community IDE called confusingly Visual Studio Code
Visual Studio Code - Code Editing. Redefined[^]
MS finally added C++ to Visual Studio Code compiling options late last year but it has several drawbacks to VS2017. The intellisense on it is not as developed as VS2017 and the compiler technology is very different and the code produced is not as efficient as VS2017.
It's also worth looking at the backdrop to the c++ compiler at MS which now stands apart from Visual Studio itself
Rejuvenating the Microsoft C/C++ Compiler | Visual C++ Team Blog[^]
In vino veritas
modified 30-May-17 1:32am.
|
|
|
|
|
Hi,
leon de boer wrote: "MFC is limited to Windows desktop apps, and you cannot currently develop "Modern" or "Universal" apps that target the Windows Store, phone devices (including Windows, Android, and iPhone), MFC is not slated for any investment at this time."
You can distribute your MFC or Win32 application in the Microsoft Store via the Desktop Bridge[^]
Bring existing legacy apps and games to the Windows Store.[^]
Best Wishes,
-David Delaune
|
|
|
|
|
The problem is glaringly obvious it's telling you the problem
You must have noticed the file path names... Microsoft visual studio 9 ... Microsoft visual studio 10.0
You either compile for VC9 or you Compile for VC10 what you can't do is mix and match the system files.
That means either
1.) Your project file incorrectly references both sets of VC base directories ... a big no no
2.) Some header directly includes the VCx files from the other system.
FIX IT .. CHOOSE 1 VERSION OF VC !!!!!!!
There is a fast haxx way which is to rename one of the VC base directory trees temporarily ... the compiler can't use what it can't find
It will either fix everything that means your project file is DORKED or it will spit it can't find xyz file and that will be the wrong VC directory so fix it.
In vino veritas
|
|
|
|
|
bkelly13 wrote: if I could find anyone else around here that uses Visual Studio.
Just about everyone who comes here uses Visual Studio on a daily basis. As stated by two other posters your project was in a mess, which was why you got that problem, but the information you originally provided did not show it up. In fact from your original question it was not possible to figure out what you were doing, hence my comments.
|
|
|
|
|
Hi,
Just a Comment.
I assume that you understand that each 'C' or 'CPP' File, gets compiled into One and only One '.obj' module.
The Linker stitches all those 'Obj' modules together, to create an Exe or DLL, your Target. In doing so, your program needs to link with other libraries and DLL's already on the system. For Instance, your program uses the keyboard, and uses the mouse. You did not have to write the code inside your program to track the mouse movements, register the clicks, etc. That was already done by Microsoft, and comes as part of the Windows Package. Now, Microsoft wrote all that stuff, but, the compiler needs to know what is available from Microsoft, I.e.: the function and other specifications that the Windows API provides. These specifications are included in the System Headers. If you change these specifications to suit your own purpose, well, it Might work if you also 'Re Compiled Windows'
If you mess with your system header files, you are actually telling your compiler that Windows works different than that it actually does.
Your Compiler caught you out, and stopped you writing a disaster.
include files do not make your program larger, at most it slows down your compiler and linker
All Software Engineers should Learn and Train Machine and Assembly Language, so as to really Understand how a computer Works
Bram van Kampen
|
|
|
|
|
sdfesrgdth
modified 21-May-17 13:11pm.
|
|
|
|
|
No.
We do not do your homework: it is set for a reason. It is there so that you think about what you have been told, and try to understand it. It is also there so that your tutor can identify areas where you are weak, and focus more attention on remedial action.
Try it yourself, you may find it is not as difficult as you think!
If you meet a specific problem, then please ask about that and we will do our best to help. But we aren't going to do it all for you!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I would go with Zod,Clod and ZooDude some aliens from outerspace came down and ate my programming assignement .. and that is why it's not ready for hand-in sir.
In vino veritas
|
|
|
|
|
Wasn't a question the first time this was asked, and still not a question now. If you do not understand your homework assignment. ask your teacher. It's their job to teach you, not ours.
Speed of sound - 1100 ft/sec
Speed of light - 186,000 mi/sec
Speed of stupid - instantaneous.
|
|
|
|
|
hello,
Can anyone help me out in writing large number of files(almost 8000) parallely in a directory using openMP support in VC++
I am also using a recursive function inside WriteFile to do the writng texts to the corresponding file
My code snippet is as below
===========================
#pragma omp parallel private(i)
{
#pragma omp for schedule(dynamic, 1)
for ( i= 0; i< 10000; i++)
{
WriteFiles("directory path..", "w+");
}
}
But it is not working and crashing particularly inside recursive function.
Can anyone help me out?
Thanks in advance
asdsa
|
|
|
|
|
Ashish Ranjan Mishra wrote: it is not working and crashing
You will need to provide much more detail if you want help with this. We have no idea what "not working" means, or where it is crashing. Also, you need to understand that trying to write that many files at the same time will run extremely slowly as the system tries to schedule the different threads.
|
|
|
|
|
Apart from the problem, you also did not show the WriteFiles function that you have. The function that you have is not recursive, it does not call itself, or does it? If that does, remove the recursion as soon as possible.
Secondly, also show the code of that function.
OpenMP is helpful in most cases, but multithreading can be overkill in majority of the cases. Use with caution.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Until your code works with 1 file, non-recursively, don't bother adding the complexity of multiple files, in parallel, using recursion.
Start small until you have a firm understanding, and then bother building it up.
"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
|
|
|
|
|
Hi,
Ashish Ranjan Mishra wrote: But it is not working and crashing particularly inside recursive function.
Can anyone help me out?
Unfortunately you did not give any error message or debug information.
Also wanted to point out that you will need to avoid the C runtime if you plan on opening more than 512/2048 files at a time. If you use the C wrappers you will be limited to 512 file handles which can be extended to 2048 via the _setmaxstdio function[^].
Best Wishes,
-David Delaune
|
|
|
|
|
Hello all... I have this C code which I can compile and modify using NetBeans. But problems come when I try to separate some of the code to new files (.h & .c). I get these Unresolved External Symbols xxxxx. Example
int add(int a, int b);
int add(int a, int b)
{ return a + b; }
#include "newFile.h"
int main()
{
int result = add(5,6);
_getch();
return 0;
}
How do I overcome this error....thanks for anything you share.
|
|
|
|
|
You have to make sure that newfile.obj (or whatever it compiles to) is being linked during the build process.
|
|
|
|
|
Get yourself a copy of Visual Studio, it is much better for building C/C++/C# projects.
|
|
|
|
|
Hi all of you. How can I convert COleVariant to COLORREF ?
I have used CMFCPropertyGridColorProperty to store a colorref into CMFCProperrtyGrid, but I need to retrieve correctly the colorref value, because CMFCPropertyGridColorProperty have been filled with COleVariant ...
I get the value just like this:
CMFCPropertyGridProperty* pProp = m_wndPropList.FindItemByData(TRM_PROPERTYGRID_COLORWINDOW);
pProp->GetValue();
but GetValue get me COleVariant, and I have there COLORREF value ... how can overcome this ? I get the following error:
error C2440: 'return' : cannot convert from 'const COleVariant' to 'COLORREF'
Thank you.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
