Are there winAPI function (without classes) to create a daughter window from console application. It necessary to print graphics of shapes on window, and input commands to console.
Thank you.
it's simpler to create console window for your GUI application. Have a look here
I'm not sure if you mean something specific by "daughter", but it's certainly possible for a console application to create a window (or as many as it likes). It's also possible for a windowed application to allocate a console.
Allocating a console from a windowed program is theoretically a bit work, but does have one advantage: you can write the majority of your windowing "stuff" using an application framework of your choice (Qt, wxWidgets, etc.)
If you work directly with the Windows API, it's a bit easier to create a console application and create windows as you see fit. About all you have to do in this case is write your code just as you normally would a windowed program, but instead of WinMain, name your entry function main. Based on that, the linker will automatically set the "console" flag in the executable, and Windows will give it a console when it starts up. The big advantage here is that C++ standard library gets initialized automatically, so things like cin all work without any extra effort on your part. If you start from a Windowed program and allocate a console, all that'll work by default will be the Windows API functions (ReadConsoleInput, WriteConsoleOutput, ReadFile, WriteFile, etc.) You can get the C and C++ functions to work, but you have to deal with some fairly poorly documented areas (that are all open to change with the next release of the compiler) to make it happen. I'd generally avoid this unless I was only going to use the Windows API functions to deal with the console anyway.
Here is a much easier way that may work well for you, provided you're using Visual Studio:
If you are, you can start a forms application by creating a forms project, add the necessary forms, and then change the application type (by right-clicking the project and selecting properties) and changing it to a console application. It will still spawn the form windows as you would expect, but will also start a Console window (which will still be populated by cout, etc...)!
Related
I've written a program based on an empty Win32 console app in VS2008 running on Win7 64bit. The program is entirely menu based spawning from a main.cpp which only calls external functions that lead to other interfaces based on the users needs (e.g. cashier, inventory, report, etc...). What I would love to do is provide a new console window for each interface.
Ideally it would close the main menu upon invoking any other interfaces and so on as the user progresses through its functions, including reopening the main menu when necessary.
The basis for doing it this way is that I'm starting a new semester next week diving deeper in OOP with C++ and I wanted to go over my text and complete the capstone project which progresses with the topics to ensure that I have all the basics down pat. As much as I would love to do this the smartest-easiest way, it's best if I stick to the limited knowledge presented in the book which only hints at STL and speaks nothing of additional libraries like boost.
I, of course, have searched on SO and elsewhere looking for the solution. I have found answers, most of them falling outside of my tight requirements, some dealing with building a console window from scratch. While from-scratch seems the most promising, it seemed to be dealing with those not using a robust IDE like VS and I don't know if it will cause more conflict than it's worth, or if it can even be used in multiplicity. The majority, however, left me with the impression it isn't possible. The one exception to this was linking a console to a process. This is what I hope is in my future!
What brought me to this was the need to present a clean look at each turn of events. At first I was fooling around with trying to clear the screen with a basic function like void clearScreen(int lines); but this will always clear from the bottom. So, if I clear the screen before the next interface it's still at the bottom. If I clear it then accept input, the prompt is still at the bottom.
In case it hasn't been clear up to this point. My question is:
Is it possible, within reason, to produce multiple console windows which are tied to processes, or is there an easy way which I do not know to manipulate the scrolling of the main console window?
Even though I "need" to stay within the confines of the baby-step process of traditional learning, I would love to hear any input aside from switching the app type.
This is more of an OCD issue than a requirement of the task, so if the effort isn't worth the benefit that's okay too.
There is no portable way of moving the cursor around the console window - in Unix/Linux, you can send terminal codes for that, in Windows I have no idea.
What would work cross-platform, but be terribly slow and not too nice, would be:
read your input character-by-character
remember where on the screen the next character should appear
redraw the whole screen after each key press
If you want to do better, you must turn to platform-specific solutions, or find a library which would do it for you (like ncurses in the Unix world), but I don't know if any of these fit in your requirements.
You can set the cursor-position on Windows using SetConsoleCursorPosition.
Since you were saying something about VS, I assume restricting yourself to Windows isn't a problem. If so, you can use the Windows API for this.
Other than that, ncurses seems to be at least partially ported to most common platforms.
If you were looking for a way to do this in standard C++ - it doesn't exist. C++ doesn't require the platform it's running on to even have a console, so there are no console manipulation functions.
Both aren't that hard to use, but if this is really just some student thingy where you expect to learn something useful you probably shouldn't bother. Console manipulation isn't something you'll have or want to do very often.
Although it may not have been clear in my original question, I was looking for a solution to be used in a console window. Ideally the solution would have been operable on at least Linux and Windows because any programs I write for school must be compiled on each. This wasn't an assignment but it's obviously advantageous to learn things that are usable there as well.
Here's what I found ...Solution thanks to Tim Wei
void clearScreen()
{
#ifdef _WIN32
system("cls");
#else
system("clear");
#endif
}
This, as simple as it is, was exactly what I was looking for. The function clears the screen and puts the cursor at the top of the console window providing a way to provide static headers or titles with changing data tables. It also allows for simple text based animations - if you like that sort of thing. It made a significant difference in the look, feel and consistency in my console applications this semester!
I'm working on a windows application in C++, and I'd like to use cout for debugging purposes.
It seems that the effects of cout are hidden, is there a configuration option that will allow a console window to open with my debug information?
You have a couple of reasonable options. One is to rename your entrypoint from WinMain to main, so it'll be built as a console application. That can still use things like RegisterClass and CreateWindow just fine.
The obvious alternative would be to use OutputDebugString instead of cout. The output from that will show up in a debugger, or any number of programs built specifically to display what it produces (basically mini-debuggers that just don't provide other debugging capabilities).
A third solution I'd consider less reasonable is to call AllocConsole to allocate a console, then write to it. If you don't mind doing all your writing with Windows-native console functions (WriteFile, WriteConsoleOutput, etc.) that's fine. Unfortunately, it won't initialize the C++ streams to work with the console, so you'll need to either open file streams pointing the console, or else find and use the (undocumented) function that initializes the streams library for the console. While this can be made to work, you end up doing extra work to write non-portable code, and little (if any) advantage to make up for it (and in this case, "non-portable" can include not even working with other versions of the same compiler, at least if you invoke the library's initialization function).
To add a console window to a GUI application, you can use the AllocConsole API.
Then you just need to open the special file name "CONOUT$" and attach your streams to it (cout, cerr, etc)
See this explanation on MSDN.
I believe the accepted answers are actually not what you are looking for. You say you need it only for debugging, not for release. Your best options are:
a) redirect stdout and stderr to a file and then inspect the file. This you can set in the VS project Properties > Configuration Properties > Debugging > Command Arguments: you should enter >out.txt 2>&1. This will output both stdout and stderr to out.txt
b) set your debug (you say you need it only for debugging) configuration Properties > Configuration Properties > Linker > System > SubSystem to Console (/SUBSYSTEM:CONSOLE). Then you can run the project with F5, but it will hide the console window when your application finishes. If you run it with Ctrl+F5 (but then you will not have debugger attached), then it will not be hidden.
The simplest way to do this is to start a Console application from scratch:
In VisualStudio, File > New Project. Select Win32 Console Application. Select various options and create the new project.
Note that although it says Win32 Console Application, you can create x64 builds without restriction.
At this point you have an application shell. If you already have code and you want to bring it in to this new project, simply do Project > Add Existing Item... and select the files to include in the project.
Managing a console from a GUI program is horribly messy, and I suggest you do it another way. For instance, if you need to see the messages in real time, display them in a window; if not, write them to a file.
just use OutputDebugString() but remember to either set your character set to multibyte, or if you don't want to do that, you could write your code like this:
// with multibyte character set:
OutputDebugString("Failed to do something");
// without multibyte character set:
OutputDebugString(L"Failed to do something");
Is it possible to embed system command line right inside your application window?
I want to be able to have the command line take some space on the bottom of my C++ application, and my application to take the above space. Ideally it should work on Mac, Linux and Windows, but for starters Windows is the primary goal as I am developing on it.
Speaking for Windows, the Windows console window is "special" in that it gets special treatment, different than any other window on the system. You will not succeed in manipulating it for your own use. For a good example, try using Spy++ on a console window.
Note that the window created with AllocConsole is not a command-line interpreter, it's just a console window.
You should implement your own console window, and as far as interpreting the commands I can think of a few options to explore depending on what you expect, behavior-wise and complexity-wise:
Delegate commands to a hidden cmd.exe
Interpret commands yourself
There are probably open-source solutions for command line interpreting.
In Windows, you can do that using some WinAPI functions like ShellExecute and CreateProcess (there are a few others that I don't remember). You get the command string from your GUI, pass it to one of these WinAPI functions, then send the output back to your GUI.
You want to do this on multiple platforms, so I would suggest making a generic module (class or namespace of functions, whatever fits you best) that allows using the OS terminal agnostic of the actual underling OS. Then. when you want to port your app to another OS, you just change the implementation of this module.
Note: Boost has (had?) a library under development that made running shell commands easier, Boost.Process. But it's currently on version 0.4 and hasn't been updated since October 4, 2010 (even though its status is still "on going").
I want to hide my console of C when I run my application. How can I make my application run in the background?
Programs with main() by default are compiled as SUBSYSTEM:CONSOLE applications and get a console window. If you own the other processes your application is starting, you could modify them to be windowed applications by one of the following methods:
Modify them to use WinMain() instead of main(). This is the typical approach but requires modifying code. (If the reason for using main() is for easy access to argc/argv, MSVC provides global __argc/__argv equivalents for windowed applications.)
Explicitly specifying the subsystem and entry point via /SUBSYSTEM:WINDOWS /ENTRY:main arguments to link.exe.
Use editbin.exe (from the Windows SDK) to change the subsystem type after the fact. This one might be useful if you don't have source code access to the spawned processes.
The easiest way to do this is to use a Windows Forms project rather than Console and then hide the startup form. The other option of course is a Windows Service, but this might be overkill ...
Use CreateProcess with the DETACH_PROCESS flag.
If I remember correctly, there's no way to do it programmatically. There are options to do it. I think I have done it in the past by creating a Windows project, but having no Windows Forms code (I am just including the files from my console application). No console window popped up. I believe I did it in Code::Blocks once by changing an option in the GUI. I am sorry I can't be specific, but I am using Visual Studio 2010 RC and the way I do it there may not be the same as yours.
Your comment makes me think that you're spawning processes. You do it by the function you call. I don't know what language you're using (I'll assume C, because you said you're launching a C application you created?), but there is either a flag to say hide the window or (or a flag you don't set to not show it) or use an alternative function which does the same thing, but launches the process a different way. Try shellexecute and system().
Context : programming a c/c++ win32-mfc library
How to know whether we are in a console or a windowed app?
You can determine if there is a console currently attached to the process by calling the win32 function GetConsoleWindow. If it returns NULL then there is no console attached to the process. However this will not necessarily tell you if you are running in a windowed app or not. For example I could have a windowed app that uses AllocConsole on start-up to allocate a console for debug output in which case you would have both at the same time. The other problem I can see with what you describe is an application might have no windows and no console attached (A windows service for example).
I'm going to have to agree with litb and Martin on this one as well. If your library needs to know this then it probably isn't decoupled enough. If you are using this to determine where to send debug output for example the best approach would be to use cout or cerr and let the application that is using the library deal with redirecting the stream to where it wants it.
I'm not certain about this (without having tried it myself) but you can call the GetStartupInfo function which completes a STARTUPINFO structure.
Perhaps console and windows apps set the STARTF_USESHOWWINDOW flag of the dwFlags member differently and you could distinguish them like that.
As mentioned in the comments of your question, it is usually not a good sign when a library needs to know such things - the more decoupled you can keep it the better.
Hope that helps.