|
1> winnocc.cpp
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinition Are you compiling the file winocc.cpp? That is a MFC source file that must not be compiled by applications (it is part of the MFC DLLs).
Regarding the file name cases:
Windows file names are not case sensitive. While the case is preserved by the file system, it is ignored when opening files.
As already mentioned by Richard:
Never change any of the system include files.
|
|
|
|
|
Hmmmm,
bkelly13 wrote: While trying to chase down this problem I discovered that the file name is really Message_Constants.h. When I chase down the error the file name at the top of the edit windows shows the name "message_constants.h" It also shows "Message_Constants.h" What is with the all lower case versus the leading caps?
I execute a Save As to ascertain the actual location and it is as expected. Open Windows explorer and it finds "Message_Constants.h and it does not find "message_constants.h" Now I have changed all occurrences to use the leading caps version but this problem remains.
Why on earth are you editing those header files? It technically should not matter if headers use "message_constants.h" or "Message_Constants.h" unless you have modified the OS group policy that enforces case sensitivity[^]. File a bug if this is an issue for your organization.
Learn to use the tools you are given. You should be using the /showIncludes (List Include Files)[^] option for debugging nested include bugs.
How to: View, Save, and Configure Build Log Files[^]
Enable 'Diagnostic' verbose logging. Search that log for message_constants.h and you should quickly find the offending file.
Career Advice: You should always avoid #including headers from headers... from other nested headers.
Yes, this means you may need to add #include "your_header.h" in 50 different CPP files.
Best Wishes,
-David Delaune
|
|
|
|
|
Three people have posted and chewed me out for editing the Visual Studio files.
Still, as I perceived this thread, the core problem has been ignored.
I had a project that compiled an ran and started getting errors where it should not. Why might I get YesNoMaybe redefined?
If the code that has that is prefixed with #pragma once, why might Visual Studio re-read that file that is knows is has already read, then declare the item redefined. The error appears, from my perspective, to be a failure of #pragma once to not do fulfill its intended purpose.
I will be adding option /showIncludes and see if I can derive any information from that.
Just as a side comment, these kinds of problems would probably be much easier to deal with if I could find anyone else around here that uses Visual Studio.
Edit: I edited more information into my original post at the bottom.
Thank you for your time
modified 22-May-17 10:23am.
|
|
|
|
|
Hi,
Aren't you an experienced C/C++ software engineer? I have seen you on this forum for many years... how can you get this wrong? The answer you are looking for is located in your edited original message above:
bkelly13 wrote:
c:\program files\Microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(57): error c2011: 'vc_attributes::YesNoMaybe' : 'enum' type redefinition
(indented here) c:\program files\Microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(57) " see declaration of 'vc_attributes:: YesNoMaybe'
Your project is pulling in the sourceannotations.h header from both VS2008 and VS2010.
Fix your project #include paths.
Best Wishes,
-David Delaune
|
|
|
|
|
David,
Yes, I have been here for maybe 15 years. I have never had a good opportunity to work with anyone that knows Visual Studio itself well. I have written some rather good code, but have not and do not know how to use VS to its best advantage.
Side question: Do you have a good reference I can read or purchase about using Visual Studio itself. Maybe something to help me make a little progress in being a "Visual Studio power user" (for lack of a better term.
On to this problem.
Now that you guys have egged me on a bit, a very good thing, I discovered:
Click on start, computer, properties, Advanced system settings, Environment Variables.
Under System variables there is an entry for include and lib. Both of them had three copies of the line that goes something like: C:\Program Files\...\v7.0A\... All three exactly the same. Three in "include" and three in "lib"
I have never messed around here and I surmise (careful choice of words here) that this is an artifact of installing multiple versions of VS, one after another, since VS 2005. As of just now, I have messed around here and I deleted two versions of the line and some of my problems were resolved.
Now I am back to an older problem where it cannot find occimpl.h. Having learned this,I might be able to fix that problem tomorrow. For local reasons, Must call it a day for today.
I do thank each of you for the time you took to reply.
Thank you for your time
|
|
|
|
|
bkelly13 wrote: Side question: Do you have a good reference I can read or purchase about using Visual Studio itself. Maybe something to help me make a little progress in being a "Visual Studio power user" (for lack of a better term.
I have no idea... I have not read a Visual Studio manual since ~1994 back when I was using Visual C++ 1.0. Here is a screenshot[^]. I keep it installed in a VM running Windows XP for nostalgic reasons.
Unfortunately my technique for becoming a "Visual Studio Power User" is to spend 20+ years of my life in the IDE almost daily.. including many weekends.
bkelly13 wrote: Now that you guys have egged me on a bit, a very good thing, I discovered:
Click on start, computer, properties, Advanced system settings, Environment Variables.
Under System variables there is an entry for include and lib. Both of them had three copies of the line that goes something like: C:\Program Files\...\v7.0A\... All three exactly the same. Three in "include" and three in "lib"
I have never messed around here and I surmise (careful choice of words here) that this is an artifact of installing multiple versions of VS, one after another, since VS 2005. As of just now, I have messed around here and I deleted two versions of the line and some of my problems were resolved.
I believe the older versions of Visual Studio had an option in the Installation Wizard to "Set Environment variables for LIB, INCLUDE and PATH" so that you could compile code from a command prompt. I would recommend removing them... you can always use the Visual Studio command prompt and allow \VC\bin\vcvars[*].bat to set the environment variables.
bkelly13 wrote: Now I am back to an older problem where it cannot find occimpl.h. Having learned this,I might be able to fix that problem tomorrow. For local reasons, Must call it a day for today.
That one is located in the MFC source folder.
\VC\atlmfc\src\mfc
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.
Best Wishes,
-David Delaune
|
|
|
|
|
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 !~
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
