I just added a new reference and added a using statement for the assembly I want. However, intellisense isn't picking it up and gives me squigly lines when I try to use it. When I go to compile it corrects itself and everything is fine... for about 60 seconds then it starts complaining again as if it didn't just realize the reference was really there.
Anyone run into this before and know how I might go about figuring out why Intellisense is confused?
Basically, building the project fixed the problem. It was definitely telling me it couldn't find a reference that was there in the beginning, but I tried to 'correct' it not realizing that it was already correct. And there was some other confusion involved that I won't go into.
Long story short, Intellisense is not the habitual liar I thought it was... just a casual liar.
Related
I am programming in C with Visual Studio Code, but I am still a beginner.
I set a mark at a point where I had to solve a problem and somehow a yellow bell or something showed up at the beginning of the code line and I inadvertently clicked on it.
Now there are all of the warnings and error signs (wavy colored lines under the code) are gone and I think my compiler does not work perfectly as well.
So, what did I do and how can I fix it?
So this is my first post. I am preparing for some upcoming college courses on programming, one of them deals with C. I have been teaching myself for a little while and have never encountered this problem before, even though I have used the same code. I am having the issue on any ide that I use, which are MS Visual Studio 2019, and Codeblocks, both 16.01 and 17.12.
The problem is when I try to include an inline function, the compiler brings up an error: identifier "keep_window_open" is undefined, as well as the error: 'keep_window_open':identifier not found.
This never happened until I upgraded Codeblocks from 16.01 to 17.12, so that leads to believe something happened with the compiler or some settings that I don't know about, or how to change.
I have tried going back to Codeblocks 16.01, but still get the same error. All my previous programs, that use the exact same code still compile and run, so I am at a lost and completely frustrated. Enough so to think about changing my major, which I really do not want to do. I enjoy programming. But this problem is killing me.
#define _CRT_SECURE_NO_WARNINGS
#include<stdio.h>
inline void keep_window_open() { char ch; scanf("%s", ch); }
int main()
{
printf ("Lets see if this stupid thing works\n");
keep_Window_open();
return 0;
}
The problem is the line of code:
keep_Window_open();
If I comment it out, the program will compile and run, however I can't see it, because all it does is flash and then close the console window. And I need to use this code to see the output window. As I have said I have used this code in many other programs, most of which are much more complex than this, and they all still compile and run. It is only on new projects that I try to create.
I expect the window to stay open until the user presses and enters a key, like it always has before. I am stuck, and would appreciate some input on how to proceed, other than throw myself in front of a bus.
OK, so I was able to solve the issue in CodeBlocks, but not in Visual Studio. I changed the code to have the inline function below the main function, and now when compiled and run in CodeBlocks (17.12) it works exactly like it should, or how I thought it should.
However when I try the same solution in Visual Studio, after putting the inline function below the main function I now get a new error:
'keep_window_open' redefinition basic types
Since I usually use CodeBlocks for C, Visual Studio for C++ and intellij for java, I am not going to worry about this, as long as it works in CodeBlocks I should be OK. However I am curious as to why it work in one IDE and not the other?
I am new to this programming thing, and there is much to learn, and I know virtually nothing about compilers and linkers, as I am focusing on programming techniques and syntax in several different languages.
I am new to C. I encountered an error message which involves unexpected "}". However, I checked the number of "}" with an editor and indeed they pair up.
Then I wonder if there is a compiler command, so the compilation can stop whatever I want? It will be convenient to have such tool as debug help.
Thank you.
(Edited in 29-10-2015)
I typically write my code with gedit. Nonetheless, since my work is mostly done on cluster, it will be troublesome to transport the files up and down. I must turn to nano, vi or vim which causes difficulty in debugging.
Stopping compilation partway through is rarely a useful feature. You'll want to see all of the errors that may exist in your code so you can fix more that just one at a time.
That said, an error such as a misplaced brace or parenthesis can cascade down and cause several more errors to appear. So if you see a long list of errors that don't seem to make sense when you look at the code, start at the top and fix that, then recompile to see if it took care of any others.
The answer is no compilers are all or nothing.
However, a good editor is recommended. For example, you can match brackets with the % command in vi, or if you have a color editor, you can visually see what's going on. A better IDE would even allow you to hide/show blocks of code, format it with proper indentation, and flag any compilation issues from static rules without actually compiling your code.
Windows XP, Visual Studio 2005, C/C++, automation for Unigraphics NX using Open C
I'm trying to code an external program for NXOpen (i.e. a program with the NX library that runs on Windows, as opposed to an internal program that runs within NX). Right now I'm just testing to make sure the link structure is good, etc.
When I try to run the .exe that was generated, it does nothing for a few moments and then I get the following error: "The procedure entry point ?JPEG_convert_to_rgb##YAPAEHPAEPAH1#Z could not be located in the dynamic link library libimage.dll"
I have nothing to go on and Googling so far has been vastly unhelpful. The stuff on here seems to be file-specific for each case, and I'd never heard of this JPEG_convert_to_rgb before now. What can I do to fix this?
Additional info: I'm not sure if I broke something when trying to solve my last issue, or if this would have happened anyway.
It looks like you are compiling a C header file in C++ and suffering from the C++ compiler mangling your names. The DLL should export non-mangled names. Try wrapping the include of the header file in an extern "C" block.
Well, I called up GTAC. The issue turned out to be quite specific to the NX library and I'm not even fully certain what happened.
Basically, I had some environment variables that needed to be set: TC_DATA and TC_ROOT, though for some people it will be IMAN_DATA and IMAN_ROOT. These can be found if you open up NX through Teamcenter, go to Help->NX Log File, and do a ctrl-F to search for these terms. There you should find what the variables should be set to, and then set them as that. You should also make sure the UGII_BASE_DIR is set properly, and that your UGII_ROOT_DIR is at the beginning of your PATH variable. Also: call %tc_data%\tc_profilevars to set the other TC variables; call %iman_data%\iman_profilevars to set the other IMAN variables. There's also something else that I can't remember - this answer is not complete, it's just as complete as I can make it.
If this makes no sense to you, and you're using NX Open, you should probably call GTAC; if you can use an internal application instead of an external, you might be better off doing so.
When releasing source code for someone else to see, when coding style is not well defined
(no pun intended)
do you remove the #ifdef DEBUG parts?
(that is the parts that are compiled only when DEBUG is defined)
If I remove it, it makes the code looks better (or me look better - do I really want someone to know I've debugged, and how I've done it? ), but then I'll lose my debug parts, or have to keep two (or more) versions of the code.
What is to be done?
I think if your debug code is clean and has "professional" language in any logging statements, it's okay to leave it in. If the debug code is sloppy or has debug messages like "I'm here...," "Now I'm here..." you should take it out.
If your debug statements reflect the fact that there are issues that you can't figure out, it might be best to take them out, if you're trying to "sell" your software to someone. (Hopefully you can fix them later...)
You should leave the code as is, unless you make use of non-recomadable language in your commentary. If someone is to use your code, chances are they'll need those, or it will help them understand your code. (this is also true for commentaries)
Edit: I worked on drop of other studio code often in the past. I have seen debug code, dead path and many other stuff, still the only thing I hated, was people that strip their code of debug and commentary, this makes their code real hard to maintain
I also vote to leave it in. If/when you start work on your first patch, you'll likely need those DEBUG-blocked pieces. Also, QA won't love it that you removed the code, even if it is blocked in a directive.
If you do decide to remove them, just filter them out with a script when exporting the code, no need to maintain two versions.
Maintain your base version with everything in your source code management system.
Then if you want to distribute source code filtered in one or more ways, make a script that will make a release version of your source code.
Do not maintain these secondary filtered repositories, make them always generated.
But is it worth the time? Probably not, and you should probably just distribute everything including the #ifdef DEBUG parts.
Maintaining multiple versions of ANYTHING is undesireable.
Only do so if you must.