I have a run.bat file that opens my .exe in devenv. In visual studio 2019, hitting the F11 key will break at the first line of the main function. When I do this in the 2022 edition, it just runs the program and doesn't show any of my files so that I can set breakpoints and such. I'm using SDL2 which defines the main function in it's .dll, so F11 probably won't work anyways. Is there a way to just open the files?
I tried using F11, which just ran the program, but that makes sense because SDL2 defines the main function itself. I tried looking in the solution window, but that just showed the .exe file, which, again, makes sense because that's what it has always done.
Related
I have written one very simple app in C. I know how to run it through Visual studio, but i want to start it from desktop with a double-click. If I double-click on a .exe file made in folder, it does not start. How can I do this?
If you do not wish to modify your code so that it will wait for user input before closing (and there are many reasons that might be inappropriate), you could create a batch file wrapper:
myprog.bat
myprog.exe
pause
Then either you can double click the batch file or create a shortcut to the batch file then edit the shortcut to set the path to the batch file and the path from which to run (so it can find the exe).
That pretty much emulates how Visual Studio runs your code without terminating the window.
Another method you might consider is a batch file such as:
runner.bat
%1
pause
Then you can drag-and-drop your executable onto the runner.bat icon to run it. The advantage being that you don't have to create a new batch file and/or shortcut for every new executable.
Really though this is not a C question, or even a programming question - it is most likely off topic. If your code is ever required to run to completion unattended in a batch file for example, you would not necessarily want to add any interactivity to the program itself.
Your problem is that double clicking on a console app will open a new console window, run the program and then close the window.
VS studio does a trick where it runs the app in a new console window but keeps it open till you press a key.
You can add that same thing yourself - put a getchar() call at the end
Or you can make a bat file to run the app as per Cliffords answer
1st open the code with visual studio code
Run or Build the program
then u will find an executable file where u have saved your code
Open that executable file
but you must have installed mingw installed in your environment
you must compile it first with mingw or like compiler. and start it with by code:
cmd> yourdirectory(e.g Desktop)/ gcc yourcodefile.c your question is available also internet => how-to-compile-c-program
I am extremely new to programming and have found that a good majority of my mentors use Visual Studio to code in C.
I would like to get an early start using SAMS C Programming.
Can anyone please tell me how to create a .c file in VS 2017? I am only able to create a .cpp file at this time.
Thanks
What you most likely actually want to do is create a project. Go to File-> New-> Project. Most likely, the first programs you will write are console applications (meaning they appear on that screen that resembles an old computer monitor, or what some computer screens look like when booting). If you want to create a console application, go from Project to Visual C++-> Windows Desktop-> Windows Console Application. Ignore any additional pop-up windows and just keep clicking continue. A file called main.cpp will automatically be generated. This is the file you will want to use for your code examples (but DO NOT DELETE the #include "stdafx.h" line, even if your example code does not have it).
Visual Studio compiles both .c and .cpp files as C++ by default. C++ has nearly everything that C has, but may take longer to compile when dealing with huge projects. If you want to use strictly C with no C++, then go to Project (a separate project tab on the same toolbar as the file tab -- it isn't within the file tab)-> ProjectName(Your Project Name) Properties-> Configuration Properties-> C/C++-> Advanced and select "Compile As". You should see a square with a upside-down "^" in it. Click that and select "Compile as C Code (/TC)". The "/TC" is just what you would type in if you were using command-line arguments instead of the convenient window that appears for you to modify everything. Finally, rename main.cpp to main.c.
Since you're learning C, I would also like to mention that I started making a C tutorial on my web site (and if anybody else also happens to see this post and the tutorial, criticize the tutorial as harshly as you can in the comments below).
Click on File, Choose Project --> Visual C++ --> Windows Desktop and under Windows desktop Choose Windows desktop wizard and give project name in the bottom then click on OK. a pop of Windows Desktop Project will come, check empty project and uncheck all options.then click on OK after that in the right side along with your project name more options will come..right lick on source file-> add -> new items -> choose c++ plus file but in bottom give file with extension .c..and you are done .enjoy coding
If you are truly interested in learning to program in C, then leave the VS Code IDE for later and learn to Build C/C++ code on the command line. VS provides a reasonably good compiler (cl.exe) and pre-configured command line (command prompt) windows to build both 32 and 64 bit applications.
The benefit to using the command line is learning what the compiler options are and what they actually do. Simply open a VS command line window and type cl /help. The compiler will list all options along with a short description. There are a great number of resource for command line building that can be accessed through the link above.
A second benefit is you can rapidly compile all your beginning C examples without worrying about projects, etc.. Just cl /nologo /Wall /Ox /Foname.o /Fename.exe /Tc name.c and you are done. (you will want to suppress unneeded warning with individual /wdXXXX options where XXXX is the warning to suppress) 50 Times faster than using the IDE.
Once you are proficient in using the command line, you will have a much easier time transitioning to the IDE -- because you can properly configure the IDE with the appropriate options for your build and you will know what the IDE is doing under the hood (or should be doing under the hood)
I have a Visual Studio solution which I'm trying to build using the Incredibuild tool. Two of the projects in the solution work in tandem - the first project (we'll call it "Project A") builds an executable (foo.exe) which can parse a data file in the second ("Project B") to generate some header files.
Obviously there is a dependency on Project A defined in Project B. If I use Incredibuild's Rebuild Project option on Project B, it correctly builds Project A and foo.exe is successfully built. Project B has a custom build tool file which should cause foo.exe to be ran with a command-line argument to the file it's supposed to parse. However, trying to launch foo.exe in this way always returns an error:
CustomBuild:
Running Foo
'path to executable\foo.exe' is not recognized as an internal or
external command, operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
Interestingly, if I then use Incredibuild to build only Project B (i.e. using the Build Project option), everything is ok - it correctly picks foo.exe from the location it was built to on the previous, failed, build. This makes me think that the path, at least, must be ok.
Can anyone suggest why the executable cannot be ran as part of the rebuild? Is it a timing issue, e.g. Project B commences before foo.exe is known to the file system??
It all works under Visual Studio's regular (re)build. It's just the Incredibuild rebuild which fails. Note that I'm doing all of this through the Visual Studio IDE, not from a command line.
Edit: this is the freebie version of Incredibuild that I'm using (the one which comes with Visual Studio), so all of the build is on the local machine.
I contacted the Xoreax technical support about this in the end and they told me that this is a "rare but known issue that is related to one of our extra accelerating features".
Their first suggestion was writing an executable which simply sleeps "for a few milliseconds" and having that run as part of the custom build tool post-link. This did indeed solve the immediate problem, but the solution I'm building has numerous similar problems and adding this delay in everywhere quickly became tedious and didn't always work. It felt like a fudge anyhow.
So I asked if this behaviour can be toggled to off, and indeed it can. In Visual Studio the Incredibuild menu has an Agent Settings option, and from the invoked dialog's Visual Studio Builds|Advanced page it's a simple case of unchecking the Enhance throughput using out-of-order tasks spawning option.
Case closed.
There are options how to offload or intercept custom tools during your build process. Try to look onto "c:\program files (x86)\IncrediBuild\Samples"
For years now my Windows C tagging/scoping solution has almost worked. I can build the filelist, build the tags (via Exuberant Ctags) for vim/gvim navigation, build cscope.out, and tag around within gvim.exe windows I launch by clicking on C source files.
The final piece that eludes me is that I can't seem to get cscope in cmd.exe to launch my editor when I select an item. I made sure gvim.exe is in my Path environment variable. I made sure the CSCOPE_EDITOR environment variable is set (more on that below). But when I select a line item from within cscope the editor is not launched. Instead I get one of the two following failures:
If CSCOPE_EDITOR is either gvim.exe -f or "gvim.exe -f" then I see that printed at the top of the cmd.exe window followed by the line offset and the filename (e.g. "gvim.exe -f +72 myfile.c") and then it quickly returns to cscope without the editor ever popping.
If CSCOPE_EDITOR is gvim.exe (without the -f option) then a gvim.exe process is kicked off (I see it in Windows Task Manager under Processes) but it never comes to the foreground as an application. Furthermore, the cscope window in cmd.exe goes blank and is unresponsive until I manually kill the gvim.exe process that was spawned.
For reference:
cscope -V returns "cscope: version 15.8a" and was downloaded from this site: http://code.google.com/p/cscope-win32/
My version of gvim.exe is 7.3 which the latest available from http://www.vim.org/
Also, I have tagged this post with "C" because, while this is not a C language question, cscope and ctags are primarily used for C programming and thus I think the C tag is relevant. (Thought I'd point that out before someone comes along and removes the tag and says this isn't a C question, since C programmers are the most likely people to have the answer.)
With help from #mattn and #mMontu and a lot of trial-and-error and an ugly but simple hack I finally have this working. Here are the problems I encountered:
cscope-win32 does not handle spaces in the EDITOR or CSCOPE_EDITOR environment variables. I tried every space-escape trick I could think of (single-quotes, double-quotes, backslash escapes) and nothing worked.
When gvim.exe is successfully launched by cscope-win32, if that gvim.exe tries to add the same cscope.out database (via cs add cscope.out) the add command hangs. If the add is part of a vimrc file then the editor will hang during opening (with the gvim.exe and cscope.exe processes starting but the application window never appearing). If the add is done after the editor window opens then the window will hang. This appears related to multiple cscope-win32 processes being attempted in the same process tree, but I have no actual proof of that.
Here's my solution to the problem. Like I said, it is an ugly but simple hack.
Create a wrapper batch file. I named mine gvim_cscope.bat. Make sure it is in a directory that exists in your PATH environment variable. You can verify this in a cmd.exe shell by calling "where gvim_cscope.bat".
Edit the batch file and add your editor command but precede it with the windows start command. For example, my batch file contains the following:
start gvim.exe %*
Create/Update your CSCOPE_EDITOR environment variable to be "gvim_cscope.bat". In case you've never modified a Windows environment variable before, you can get to them (on Windows 7 anyway) via Start -> right-click Computer -> Properties -> Advanced System Settings -> Environment Variables.
That's all I needed to get things working. Open a new cmd.exe window (so the updated environment variable is pulled in) and open cscope.exe and everything works. I am able to pop multiple gvim.exe windows from within cscope.exe, each with its own connection to the cscope.out database. The first problem is avoided by using the wrapper batch file (no more spaces in the command) and the second problem is avoided by using the windows start command so that gvim.exe is started as a separate process.
Thanks for the help #mattn and #mMontu. So nice to have things working right!
I am interested in programming for the Game Boy Advance using the Visual HAM IDE in C. However, every time I build a project I get a message stating:
'make.exe' is not recognized as an internal or external command,
operable program or batch file.
I downloaded GnuWin32 and make. Then, inside the ham visual editor I clicked advanced, options and set the directory of the MAKE_MODE (I guess some kind of environment variable) to the directory where the make program is.
Any suggestions on how to get this to work?
I had the same problem. Reinstall the hole vham package to the desired destination from the get-go. You can find it here: www.jharbour.com/gba/ham-280-full-win32.zip
You can't move the folders around. Even if you change the PATH variables this problem will persist.
Find where on your system the make program is in. Probably in cygwin's /usr/bin. Add that path to your system dos path.
Windows with cygwin is a screwed up hybrid system. You probably have three paths going on at once. You have the cygwin one. If you open a cygwin shell and type make I bet it finds the make program. Then if you open a dos shell ( in accessories/command prompts ) I bet it won't find the make program.
You will need to add it. Every version of windows does this differently but it is generally under right click on my computer/properties/advanced/environment variables. You will need to add it there.
And finnally there is the path known to your ide (probably). I don't know HAM, but it looks like you already did whatever they told you.
When you are done you should be able to invoke "make" from the windows/dos command prompt.