Attach the console, but only if run from console

[Grzegorz Wróbel]

I have a windows application and I would like to print some output to
the console. But I want to do it only if my application has been run
from console. I don't want to create new console window, I want to
attach console output to this particular console window. Doable?

--
Grzegorz Wróbel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D

[Alf P. Steinbach]

* Grzegorz Wróbel:

> I have a windows application and I would like to print some output to
> the console. But I want to do it only if my application has been run
> from console. I don't want to create new console window, I want to
> attach console output to this particular console window. Doable?

Depends. For a console subsystem program the standard Windows command
interpreter will by default wait until the process completes, giving
that process sole control of the console window. Letting a process
display text when it's not in sole control of the console window would
probably result in mangled text from two or more sources.

The usual solution is to have a GUI subsystem main application and a
console subsystem small starter application that can be used from the
command interpreter, and that informs the GUI app of the console. A
variation is to have the main application as a DLL loaded by two
different starters, one console subsystem and the other GUI.

Another solution is to simply do the i/o from the GUI subsystem app
always -- it will fail silently if standard i/o streams are not
connected (no console) -- and provide a batch file like

@myGuiApp | cat

to be used from the command interpreter if one desires to see the output.

A third solution could conceivably be to make the main app a console
subsystem app and somehow detect whether it's run from an existing
console or not, and if not, hide the console window, but I haven't tried
that and don't even know whether it's technically feasible.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Grzegorz Wróbel]

The point is I have simple GUI app, but it needs to take few parameters.
If they are not provided I would like to display them if application is
run from command prompt. I find dialogboxes annoying when you run
something from console, but with AllocConsole() it doesn't make much sense.
ie:

if(argc<7){
AllocConsole();
freopen("CONOUT$", "w", stdout);
freopen("CONOUT$", "w", stderr);
freopen("CONIN$", "r", stdin);
printf("usage: %s filename timer_elapse amplitude multiplier
horizontal_only 0xRRGGBB\n",argv[0]);
FreeConsole();
return 1;
}

It will just open new console window, display the message and close it.
Not only annoying but also useless. The third solution you suggested
would be it, but even if feasible, it's ugly one.

[James Brown]

"Grzegorz Wróbel" </dev/nu...@localhost.localdomain> wrote in message
news:eip1bf$s92$1...@nemesis.news.tpi.pl...

The AttachConsole API should be suitable in this case. And if you are using
Visual C, a GUI program can access it's command-line using the __argc and
__argv global variables.

--
James Brown
Microsoft MVP - Windows SDK
www.catch22.net
Free Win32 Tutorials and Sourcecode

[Grzegorz Wróbel]

James Brown wrote:

> The AttachConsole API should be suitable in this case. And if you are using

How will I find out the process ID of the console from which my gui app
was launched, and that it was launched from the console at all? I think
such information is available only on the kernel level.

Let's see, I'll try to get an active window before creating any windows
in my gui app, and if it's a console - attach to it's process.

> Visual C, a GUI program can access it's command-line using the __argc and
> __argv global variables.

It's much neater to simply access argc and argv parameters of main() in
my GUI program.

[Grzegorz Wróbel]

Grzegorz Wróbel wrote:
> How will I find out the process ID of the console from which my gui app
> was launched, and that it was launched from the console at all? I think
> such information is available only on the kernel level.
>
> Let's see, I'll try to get an active window before creating any windows
> in my gui app, and if it's a console - attach to it's process.

AttachConsole((DWORD)-1) does fine. (I was confused by the fact that
ATTACH_PARENT_PROCESS is not defined anywhere in my SDK)

GetForegroundWindow() + GetWindowThreadProcessId() also works but prior
is obviously neater.

Thanks, James.

The only annoying thing that remains is that after calling FreeConsole()
and exiting, the console awaits for the return to be pressed, and does
not automatically restore command prompt.

[Grzegorz Wróbel]

Grzegorz Wróbel wrote:
> The only annoying thing that remains is that after calling FreeConsole()
> and exiting, the console awaits for the return to be pressed, and does
> not automatically restore command prompt.

I solved it by simulating the pressing of enter key.

if(argc<7){
if(AttachConsole((DWORD)-1)){

freopen("CONOUT$", "w", stdout);
freopen("CONOUT$", "w", stderr);
freopen("CONIN$", "r", stdin);
printf("usage: %s filename timer_elapse amplitude multiplier
horizontal_only 0xRRGGBB\n",argv[0]);
FreeConsole();

// simulate return pressing
INPUT input;
memset(&input,0,sizeof(input));
input.type=INPUT_KEYBOARD;
input.ki.wVk=VK_RETURN;
SendInput(1,&input,sizeof(input));
input.ki.dwFlags=KEYEVENTF_KEYUP;
SendInput(1,&input,sizeof(input));
}

return 1;
}

Works like a charm. :)