So, I've written a C executable on Linux for Windows using mingw32-gcc. It is a basic Input-Output program, you type an input and get an answer.
Problem is the cmd shuts down immediately, so the user can't see the output.
Assuming I cannot use Windows to edit the executable there, what should I change in my code/ what flags should I use when compiling it?
inb4:
the user is supposed to click and run it, so running it from cmd won't help.
adding getchar()/scanf() at the end of my code doesn't work, and it feels a bit like cheating.
SOLVED: so all I had to do was to actually add a getchar() after every scanf() and one more at the end of the code for the user input to close the cmd.
Waiting for input at the end is not cheating, but common practice. How else should program know for how long it should stay opened? Closing program by closing console window directly is more cheating than waiting for user input to finish.
You can for example prompt user to hit any key like Press any key to exit... or something similar.
If you want some specific delay, you can use Sleep() from windows.h instead of waiting for input.
See https://stackoverflow.com/a/3379146/3035795
I'd like to create a diagnosis script and would like somehow to get all the variables the user inputs in a watch window to a script. How may i access the watch variables and manipulate them?
I tried with a DIALOG.view but that wastes too much time. There might be another trace command but I don't know it. Thank you!
Getting the content of open Var.Watch windows from script is not directly supported in TRACE32.
However you can do the following in you script
Redirect printing to a file PRinTer.FILE "~~~/winpage.txt" ASCIIE (of course you can choose any other filename instead of winpage.txt)
The window WinPAGE.List shows you all open child windows. With WinPrint.WinPAGE.List you can sent the list of all open windows to the file specified before (winpage.txt).
Now parse the content of winpage.txt for the names of the windows, which are a watch windows. The window names start by default with a capital 'W' followed by three decimal digits (but can also be totally different) and are then followed by the command (in round brackets) which was used to open the windows. Compare case insensitive!
The watch windows have a command which starts with:
B::Var.Watch
B::V.Watch
B::Var.W
B::V.W
Redirect printing to a new file e.g. PRinTer.OPEN "~~~/varwatch.txt" ASCIIE
Send the content of each open watch window to the file varwatch.txt with the command WinPRT <window name>. The relevant window names you've got from step 3. Execute WinPrt for each open watch window.
Close varwatch.txt with PRinTer.CLOSE
Now you should have the content of all open watch-windows in the file varwatch.txt.
Other idea:
Use command STOre "mywindows.cmm" Win to save commands to create all open windows to a script.
Parse this script for all lines starting with Var.Watch (or one of it's shorts forms) and the lines starting with Var.AddWatch (or one of it's shorts forms). Parse case insensitive!. The arguments followed by Var.Watch or Var.AddWatch are the variables currently shown in the watch windows.
I'm new to code blocks and I'm writing code that takes in a command line input such as a file name, but once I compile and run the Code the console prompts "press any key to continue" like always and I'm unable to type anything in the console? So I can I write in console making my code run.
CodeBlocks will run your executable file without arguments, so you'll probably want to do it yourself. Open a command prompt (cmd.exe) and invoke your program with the desired arguments: C:/path/to/your/project/bin/Debug/program.exe filename.
Alternately you can request the user input via scanf or similar.
Hope it helps!
You cannot pass commandline arguments to your program in the Code::Blocks
console, because Code::Blocks has already started your program when you
see the console. You need to specify any commandline arguments in the
the Project settings before you run it. Then, when the console appears,
your program will be running with the commandline arguments you have
specified.
To specify commandline arguments, select the Project menu on the
top menu-bar of the IDE. In the Project menu, select Set program's
arguments, enter the commandline arguments you want and then OK out.
Once your program is running in the console (with or without commandline
arguments), if it requests any input from the user, then you will be
able to type the required input in the console.
I have a Windows GUI app written in C (MinGW) and would like to have the app perform different tasks depending on whether it was launched via the command line with a filename argument or by dragging a file onto the application icon. The way it is now, the following function doesn't differentiate between the two:
int argc;
LPWSTR *argv = CommandLineToArgvW(GetCommandLineW(),&argc);
When a file is dragged onto the application's icon, it assumes it was launched via the command line. The problem with this is that I need additional arguments that must be passed via command line in order to do anything useful. The filename itself is not enough, so the app just quits because it doesn't have enough information to proceed.
What I would like is for the user to be able to drag a file onto the app icon, and have a window come up asking for the required options. If the user launches the app via command line with the required options already supplied, the app would immediately start processing without asking for additional input. Is this possible?
Another issue I am having is that sometimes when a file is dragged onto the app's icon, it crashes. I narrowed it down to anything operating on the argv[] values. It doesn't do this if launched via command line with the same argument. For example, this will crash the app about 20% of the time:
fprintf(stderr,"argv[3] was %ls\n",(LPWSTR)argv[3]);
Why would this only happen when launching via drag-n-drop? I am on Windows 7 x64.
Windows will by default call your program with the file name of the file you dropped on the its icon as the first and only argument. So you will get exactly the same invocation parameters in this case that you get when somebody starts your program from the command line with the full qualified name of the same file as the one and only argument.
You can however add additional arguments to a shortcut icon when you install your application i.e. "path\myapp.exe -gui". That allows you to differentiate between invocations via the icon in general (also applies to double clicking without any parameter) and invocations on the command line where the -gui parameter will usually not be specified.
It's certainly possible. Let's say the user must specify -slow or -fast on the command line. Your code then looks something like:
int main( int argc, char *argv[] ) {
if ( argv contains "-slow" or -"fast" ) {
we were launched fronm the command line
else
we were either launched from an icon, or the user has
not specified -slow or -fast. In either case, pop up
a dialog to get the options
endif
}
I don't think you can, when you drag a file over an icon, the OS executes the program using the file name as argument in the command line, so they are effectively the same.
I'm trying to build an .exe file for the K&R "Hello, world". The code given in the book is:
#include <stdio.h>
main()
{
printf("Hello, world!\n");
}
When I build & run from Code::Blocks (under Windows XP), I get the prompt window with the "hello world" message. It stays open until I close it manually. However, when I double click the .exe file, the prompt just flashes and disappears, why is that?
No one is explicitly telling you this, so I will:
What you see when you double-click the file is normal. What your IDE does (keeping the window open) is a feature to help you debug the application.
Why is this so?
Since you're developing a console application, there has to be a console for your application to display its output on. If there is none yet, a new console is created (which is the black window).
If you launch your program from inside a console (say, from cmd.exe), it will just inherit the console of the parent without creating a new one[1].
After the last application using the console exits (which, in the first case is just your program), the console closes. You will notice this all the time for console applications that print nothing but a help text when run without parameters. If you double-click them from explorer, a black window with some text will flash and then immediately close.
Sometimes, a program that does something and them immediately closes is what you want. For example, you can call these applications from scripts.
On the other hand, your application could be interactive: waiting for user input, doing some thing, and only exiting when the user tells it to. You cannot script these applications, obviously, as you will need to have a human present at the keyboard to tell the application what to do.
Now we get to the IDE part: let's say you're developing an application of the first kind, one that does something and then immediately closes. It's not very convenient to have the screen flash and disappear every time you run it, because how can you tell if the program worked? Assuming you can tell this from the output it generates.
You could of course start a command-line window and run the application from there, but the program would execute separately from the IDE, and you would lose live debugging capabilities.
So, IDE makers came up with a feature for console applications: when you run the application directly from your IDE, they afterwards, usually waiting for a keypress. This gives you the opportunity to inspect the window with the output, to confirm that the application is working properly.
[1] Esoterica: unless you go through an application that does not inherit the console. Any console app launched by that application will not inherit the console, since the inheritance was broken by the GUI app. For example, start.exe does this. Compare:
foo.exe (inherits the console)
start foo.exe (start.exe is a GUI app, so foo.exe is launched in a new console)
If you're not running a command line exe from an already open command line window, Windows will automatically close the windows after the program has terminated. Try opening cmd.exe, navigating to your program's directory and running it from there, the window should stay open.
When running from IDE's like this, they run the program and when its done running, they close it.
Since your program's only function is to print out a value, it does that and closes.
You should try to add something that asks for user input at the end or compile it into an .exe and run itself from the command line yourself.
Since you are starting I would recommend to just run it from the command line yourself. You will eventually learn about user input and there you can have the command line window open when you use your program.
Normal behavior.
Your program executes every action in the order of the main. So it prints, and then moves on to the next operation, there is none, so it exits. Since the console window is tied to your .exe, the command window closes with the program.
If you don't want your program to exit right away, you can make it sleep, or wait for user input before exiting.
When double clicking a .exe in Windows, you are launching a new process. Windows has 2 basic process types: Window and Command line. The hello world sample you've written is a command line process.
A command line process will launch a new command window on startup. This is the window that pops up which is largely a black background with white text. Upon completion of a program the window will close down.
Add getch(); before the closing brace. This will prompt for an input after the output is printed. Once you key in a character the window will close. This should solve your problem.
The preferred solution is to run the executable from the command line.
Try running your binary from the command line.
That is because the executable file opens its own dialog box. When the executable has completed running it shuts down the dialog box that it opened in order to run. However, when YOU are the one that opened the dialog box, it disappears when YOU close it.
So if you were to open up a command prompt and then run the executable, the dialog box would not automatically close.
That is because from the executable, it executes your code in a new window and then the process is done, it has no reason to stay open, what you wanted to do is complete. There are a couple of things you can do. You can execute it from the cmd.exe command line, or you could even put something at the end of your code that listens for a key press, and once the key stroke is detected, allow the program to exit.
just add
system("pause");
line before return. it`s not the best, but universal method.
Here is my take on this:
// Hello sweetie (Spoilers)
#include <iostream>
using namespace std;
int main()
{
// Print the text to screen
cout << "************************************";
cout << "\n";
cout << "Hello World!";
cout << "\n";
cout << "You may close me by pressing Enter";
cout << "\n";
cout << "************************************";
cout << "\n";
cout << "\n";
/*
This will prompt for an input after the output is printed.
Once you hit the Enter key the window will close.
*/
if (cin.get() == '\n')
return 0;
}