I'm used to using Xcode for my C++ class homework. I usually just create a command line project, write code, and test it with the console that appears at the bottom of the window. But since I updated Xcode (it's now 8.3.1), I can't make the console appear when I run my command line app. This question seems to have come up before, and I followed the instructions here, but the console is weird. For example, I wrote a simple function, and then the main program. The console wouldn't do anything until I first typed a number, and then it used my input as the parameter for the function. That's not how it's supposed to work. The console didn't give the prompt or anything. The main program worked, but only because I knew the program. Someone else who didn't know how it worked would simply see a blank console.
Related
I am trying to write up a C++ program for a class using XCode. One of the things I wish to do, is to simply clear the screen. I've looked into how to do this, however the catch is that the code needs to run on both a Windows and Macintosh computer. I've looked at some other similar questions, but none of the answers help me. I know there is no "screen" but I want the system to clear the output window. I know that the command system("clear"); does what I want it to, but when XCode tests the program, instead of clearing the screen it prints TERM Variable not set
I've tried opening up the terminal and typing clear and it does in fact respond the way I want it to, so why doesn't the 'terminal' inside of XCode do the same? I just want to get the output window in XCode to respond to clear the same way that the terminal already does.
Here is something I have already tried;
I went to the terminal and ran echo $TERM, to which the terminal responded xterm-256color. I then went over to XCode and opened the "Scheme" settings, and found an Environment Variables setting under "Arguments". I added a variable (to the blank list) called TERM and gave it value xterm-256color. Upon running the program again, the output displays ¿[H¿[2J in the output window, positioned where the TERM Variable not set used to be printed.
Last thing, as a reminder, I cannot change the source code from the way it is now, or it could cause errors when the program is run on a Windows machine.
It does not work because you are "lying": The terminal in Xcode is not a xterm-256color, but it is dumb terminal. More precise, the display represents a NSTextStorage that collects stdout and/or (depending on target switch) stderr.
A dumb terminal is not able to clean the display. If you want to change this, you can write a plug-in similar to Xcode-Colors what adds the ability to understand ansi color codes.
However, if your requirement that the code simply run at Windows and OSX, you may stick with your solution system("clear"), since it works prefectly in the "normal" OSX terminal.
My application is a GUI app that has helpful (though optional) information through the terminal (via cout).
In Windows I either have a console appear (by compiling as a console app, or allocating it dynamically) or I don't.
My intention is to make use of the console IF it is being run from the console, but ignore the console completely if it was not. (Essentially what happens in Linux and OS X).
I do not wish to redirect to a file (and in the case of using cin, this is not a viable solution anyway).
Is there a way to attach a GUI app in Windows to the console it is run from, if and only if it is run from a console?
and in the case of using cin, this is not a viable solution anyway
This is the killer detail in your question. It is simple on paper, just first call AttachConsole(ATTACH_PARENT_PROCESS) to try to attach to an existing console. That will fail when your program got started from a GUI program like Explorer or a desktop shortcut. So if it returns FALSE then call AllocConsole() to create your own console.
Using cin is a problem however. The command processor pays attention to your EXE and checks if it is console mode app or a GUI app. It will detect a GUI app in your case and then doesn't wait for the process to complete. It displays the prompt again and waits for input. You will then also wait for input but you'll lose, the command processor got there first. Your output is also intermingled with the command prompt, the easy problem to solve.
There's a simple workaround for that, your user should start your program with start /wait yourapp to tell the command processor to wait for the process to complete. Problem is: nobody ever uses that. And the user will not realize what happens when they type input, intending it to go into your program but it is actually interpreted by the command processor. Producing a mystifying error message or formatting the hard drive.
Only two good ways to solve this unsolvable problem. Either build your program as a console mode app and call FreeConsole() when you find out you want to display a GUI. Or always call AllocConsole(). These are not great alternatives. The first approach is the one used by the Java JVM on Windows. One of the oldest bugs filed against the JVM and driving Java programmers completely batty from the flashing console window.
The third alternative is the only decent one, and the one you don't want, create another EXE that will always use the console. Like Java does, javaw.exe vs java.exe.
A trick is possible, you can rename that file from "yourapp2.exe" to "yourapp.com". It will be picked first when the user types "yourapp" at the command line prompt, a desktop shortcut can still point to "yourapp.exe". Visual Studio uses this trick, devenv.com vs devenv.exe.
You can check CONSOLE_SCREEN_BUFFER_INFO (via GetConsoleScreenBufferInfo) on startup to determine if you've been run from within an existing console. If the buffer's position is 0,0, you were run from outside of the console. For details, see this Microsoft Knowledgebase Article which describes the process.
In order for this to work, you need to compile your application as a console application (using /SUBSYSTEM:CONSOLE), and then detach yourself from the console if the application started a new console (buffer at 0,0). This will cause the program to properly "attach" to the calling console when launched from a command line.
As others have pointed out you have to create a console app and a window app. So, you'd end up with console.exe and app.exe. To make it less obvious at the command-line, you can take advantage of the PATHEXT trick like devenv does. cmd.exe treats a file as a command if its extension is in the PATHEXT environment variable. COM is there by default so you could rename console.exe as app.com, allowing the command app to start the console app attached to the current console.
Note: Of course, a console app can show a GUI if desired.
The difference in the build between app.com and app.exe depends on your build system but it could just be the one attribute that sets the output type. With msbuild (for .vcxproj files), it's just a matter of another build configuration.
you can create an application in console that get a line using argc and prints it;
////
int main(int argc, char *argv[])
{
//here print argv....using cout or printf
}
save the file as console.exe in the folder of your app.
now in your app if you want to see any line in console you can call the command
system("console.exe this is the line i want to print and see in console");
i am new to python and am trying to call a c++ function from python, I cam across this answer from Florian Bösch and found it really helpful, i did everything as in the link but i have a small problem which really surprised me, when i run the fooWrapper.py from command prompt it displays the result "hello" but when i run the program from idle by clicking run as module the python shell opens and displays nothing, only action is the cursor moves down as when you press enter. Is this normal or is this a problem???
I use python 2.7.3(32bits),with windows 7 and MInGW complier.
The problem is that IDLE redirects standard input and output, but your C++ function writes to the original standard output and thus IDLE will not show it. If you launch IDLE from a terminal you will see the C++'s output in the terminal.
It's a problem of IDLE, and I doubt that you can do something about it.
If you want to develop something bigger than a really small script you ought to use a different IDE.
As you can see in u413.com: Text comes on the screen, letter by letter, which looks kind of cool,
I want to do the same thing in Console
I got the source code of version 1.2; because I dont need all the complexity of version 2;
I just need a simple Command Prompt, with text that comes on to the screen letter by letter.
I dont need most of the builtin functions offered by Console, like Transparency, Taskbar Icon, etc.
The source code base is pretty small with only about 5 files.
The main class file seems to be Console.cpp;
Since console is like a GUI application, things dont get written to the STDOUT.
but heres what happens;
A Handle is called;
And that handle apparently writes to the console;
m_hStdOut = ::GetStdHandle(STD_OUTPUT_HANDLE);
Now what I want to be able to do; Is somehow read the handle; see what text it has; And throw in a loop with a ::Sleep(20) method in it; to make sure that text appears letter by letter.
#Alf P. Steinbach I wrote the psuedo code for making the sleep command(in java) I also made use of it in every other java program I wrote, but the disadvantage was that it will work only for my programs and not every program run in the command prompt, but what I dont know is code to make a console, a windows console subsystem program, I wish it was possible with java, so that I could use it on linux too, but now, let me ask you exactly what I had in mind...
A program which simply, took input from the screen, send it to cmd.exe for processing, and sent back the reply, and all I have to do is throw in a sleep command between every character...
All I need is help, in getting this done, I wish you could start me up with this, and possible provide links and refrences to get this done...
This Console.cpp seems like a console emulator, meaning it runs OTHER programs. You don't need the source code, you can run existing console applications.
STD_INPUT_HANDLE, STD_OUTPUT_HANDLE and STD_ERROR_HANDLE are the windows handles for STDIN, STDOUT and STDERR. They basicly does the same with only a few differences in how to use it.
If you want to integrate the console into your code, then you have to understand it, and find its own output function and call that. But it won't be any standard handle or things like that.
I wrote a small C++ program in VS2k8. When I launch it from windows (double click the exe file) it runs fine. When I go to the command prompt and try to run it it will hang and eventually crash. I've created test programs with simple outputs that work fine both ways.
Is there something I'm missing? I'm relatively new to programming. I'm trying to launch this program using the VBA shell command but it produces the same outcome as the command prompt.
The funny thing is it was working fine at first until I went in to change the value of a constant variable and rebuilt it (I didn't think that had anything to do with it but I changed it back with no success). No settings where changed.
Edit: I've name it time.exe and than copies.exe (when I tried copying and pasting the code into a new project). The actual code is about 250 lines, not sure what part of it would be causing the issue. It opens a .csv file, loads the information into vectors, and then compares the vectors to each other (adding something to the end of it if it meets certain conditions). It than outputs the file to another .csv file.
Might suggest that the current directory on start up is different and this is causing your issue as you make some assumptions about the current path or drive?