I am in desperate need of help.... :). I am running a script from cmd line console. It does a sequence of operations. whats the best way to pause the script in between to check the results and resume it back using mouse????? or any key
I would appreciate for your reply back,
-Abishek
If I understand your question correctly, and if your program is writing to the standard output (the console window) and you are running on Windows:
You can turn on 'quick edit' in the console window by editing the cmd.exe window properties.
Open a command prompt (start | run | cmd.exe)
Click the upper left corner of the window and choose 'Defaults'.
Click the Options tab and then in Edit Options section make sure the QuickEdit Mode box is checked.
Click OK and you should be set.
If you click with the mouse inside the console window when quick edit is enabled, it will block the program from continuing while it is waiting to be able to write the next message to the output. If you then hit 'esc', the program will continue.
It's a useful shortcut for pausing a running console program that I use all of the time.
try cin.get()
There isn't any easy way to do that. You'd need to create a wrapper to run the program (for example, a debugger is a wrapper to a program), and this wrapper would have to have mouse functions programmed into it.
Without use of the mouse, use cin.get();. It will take an input from the keyboard before continuing.
I'm not sure about using the mouse to pause, but you can pause the execution of command line process by pressing the Pause / Break key or Ctrl + NumLock .
You can then resume the execution with Ctrl + Z
Related
I don't want to deflect the button hit or ignore the close event. I just need to run some cleanup code.
Let me tell you what I've tried so far:
atexit()
_onexit()
SetConsoleCtrlHandler()
~QCoreApplication()
No code set by these is being executed.
The process just get killed when I press the X.
I certainly can make a windowed app and solve this, but is there a solution for a console application?
Thanks!
I am working on a TCP server that I'm developing on CLion under Windows 10.
I would like my program to be able to end properly, when I click on "stop" my program. I thought CLion was sending a signal, but after trying to catch them all, it looks like it does not.
So my question is, how does CLion stop running the program? Is it possible to detect it within the program?
Thank you in advance.
I found my answer here.
According to this link, signals are actually used :
Click this button to terminate the current process externally by means
of the standard shutdown script. Clicking the button once invokes soft
kill allowing the application to catch the SIGINT event and perform
graceful termination (on Windows, the Ctrl+C event is emulated). After
the button is clicked once, it is replaced with icon run tool window
kill indicating that subsequent click will lead to force termination
of the application, e.g. on Unix SIGKILL is sent.
I have a GUI Windows application written in C++ (with MFC) that attaches itself to a parent console for an output via stdout stream. It uses the AttachConsole API and the RedirectIOToConsole method described here.
So if I call the following line from a regular console application (that natively has the output to stdout):
_tprintf(_T("Test message.\n"));
I get this output that I'd expect:
But if I call the same line of code from my GUI app (with an attached parent console) I get the following, except that the control doesn't seem to be returned back to the parent command prompt window (see red circle):
Note that I can type into the parent command prompt window, so it's not hanging, and if I hit enter it will execute whatever I typed as a command.
So what have I not called from my console app to return control back to the parent console?
It's not about returning control.
When you run a console application from a command prompt the command prompt waits until the console application finishes, so you see the output from the console application followed by a fresh prompt, as your first picture shows.
When you run a GUI application from a command prompt the command prompt doesn't wait for the GUI application to finish, so you normally see a fresh prompt followed by the output from the GUI application, like this:
C:\>TestGuiProjWithOutputToConsole
C:\>Test Message.
_
As you've noted, nothing has gone wrong. You can type commands and they work, it's just that the prompt has appeared in the wrong place.
Your second example doesn't show the second prompt, maybe because you've got a carriage-return character so the prompt is being overwritten. Try outputting a newline before the test message and you should see the prompt (though still in the wrong place).
You can tell the console to wait for a GUI application by running:
start /wait TestGuiProjWithOutputToConsole
In short, GUI applications don't play well with the command-prompt because they are both running at the same time outputting to the same console so their output is jumbled up.
I have created a Win32 Console Application in Visual Studio but when I start the program the console apears just for a second and then disapears again. What should I do that the console remains on the screen ?
Well, the program has finished running, so it closes.
Either make the program wait for input (e.g. with getchar()), or press Ctrl-F5 to run the program without debugging (but then you won't be able to set breakpoints and stuff).
You can set breakpoints anywhere in your code to make it stop. If you just want to see the output of the program when it's done, try setting a breakpoint on the last line of main().
This is happening because the program has nothing to wait for before exiting.
Try running std::cin.get(); before main() returns to make the console wait for keyboard input.
Suppose that
(gdb) print *this
resulted in 20 lines of output. Yes, there would be Type <return> to continue, or q <return> to quit, but I'd like to scroll back to the top after I got to the bottom of the output.
I don't think http://sourceware.org/gdb/onlinedocs/gdb/TUI-Keys.html answers my question. It states
<PgUp>
Scroll the active window one page up.
but when the focus is on the command window, PgUp rewinds the command history, instead of scrolling back in the command window. Is it only me who suffers from this behavior?
I'm using PuTTY in order to SSH to Red Hat Linux (if this makes any difference).
One way to see the GDB output history in TUI mode is to enable logging:
set trace-commands on
set logging on
and then tail the log in another shell:
cd where/gdb/is/running
tail -f gdb.txt
This has the advantage of separating scrolling from command interaction, so you can type commands while viewing some past section of the GDB output.
None of the scrolling keys work in my CMD window, so GDB effectively consumes and destroys its own output. Switching out of TUI mode allows me to scroll up, but the output that occurred while in TUI mode is not there--the non-TUI window only shows new output generated after switching out of TUI mode. So far log and tail is the only solution I can find.
Edit: if you activate GDB logging (via set logging on) before switching to TUI mode, you may find that the logging stops upon entering TUI (this is a bug in GDB). You can toggle it back on:
set logging off
set logging on
I found an answer here: http://beej.us/guide/bggdb/
Note that when the SRC window has focus, the arrow keys will move the source code, but when the CMD window has focus, the arrow keys will select the previous and next commands in the command history. (For the record, the commands to move the SRC window single lines and single pages are +, -, <, and >.)
There's also an example session illustrating this:
(gdb) info win
SRC (36 lines) <has focus>
CMD (18 lines)
(gdb) fs next
Focus set to CMD window.
(gdb) info win
SRC (36 lines)
CMD (18 lines) <has focus>
(gdb) fs SRC
Focus set to SRC window.
(gdb)
You can try Ctrl + P for the previous command and Ctrl + N for the next command (when you have used Ctrl + P to go back to the previous commands :)
Use C-x o (usually Ctrl + X, O). Using this you can change your active window and then use normal up down arrow to see previous commands.