From: Julian Mensch on
I hope I have the right group for this; I think so, because
it's fundamentally about Win32 API calls.

I currently have a large C++ application which, on startup,
launches a GUI using the third-party Allegro graphics library.
To work correctly doing this, I understand it need to be a
Windows Application, not a Console Application. There's a
few assorted reasons it needs to be a WinApp, anyway.

However, it also has a secondary use as a development
tool, for which I would like to support a command-line
interface. I would think this wouldn't be a problem, since
I can just bypass starting my graphics library and use the
standard C++ libraries like cout or printf() -- but of course I
can't, because it's a Windows Application and to support its
main functionality can't be made into a Console Application.
Essentially, it needs to decide right on startup whether it is
going to behave like a Windows Application or a Console
Application, based on argc/argv command-line parameters.

Note that since this is a command-line development tool,
it's not good enough for it to spawn a console window and
write to that -- it has to be able to deal with output being
redirected so that, for example, if it is run from an IDE like
Visual Studio to compile some script code, the error messages
get redirected correctly to VS's Output pane, or if I run it
from cmd.exe like so:

mytool.exe -c myscript.is > output.txt

All the output goes to a text file rather than the screen. Is
it even possible to do this with a Windows Application, and
if so can someone tell me which API calls I need to research
in order to achieve it?

Thanks graciously for any help anyone can provide here!
From: Leo Davidson on
On Dec 10, 5:38 pm, Julian Mensch <jmen...(a)shaw.ca> wrote:
>   However, it also has a secondary use as a development
> tool, for which I would like to support a command-line
> interface. [...] but of course I can't, because it's a Windows
> Application and to support its main functionality can't be made
> into a Console Application.

One way to tackle this, which I've had success with in a couple of
projects, is to keep the main app as a Windows Application and create
a very small Console Application wrapper .exe which can be used to run
the main app as a console app.

The wrapper .exe redirects the main app's stdin and stdout, so they're
hooked up to the command prompt it's run from (or to the text files
it's been redirected to, if you do that). The other thing it does is
wait for the main app to finish, so that you get the synchronous
behaviour that's expected from console apps.

Short & simple source code to a wrapper exe which does all this can be
found here:

http://vips.svn.sourceforge.net/viewvc/vips/nip2/trunk/src/nip2-cli.c?view=markup

Note the comment near the bottom about closing the write end of the
pipe before reading from it. That's vital, else the whole thing will
stall (from what I remember, at least).

Of course, you may still have to modify your main app so that it
doesn't display message boxes, and maybe UI in general, when run in
this mode. This technique just takes care of allowing you to run a
Windows Application as if it was a Console Application.
From: Leo Davidson on
See also:

http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx

I just noticed that the MSDN page has some extra calls to prevent
unwanted handles from being inherited by the child process (which is
usually harmless but can cause problems, so it makes sense). That's
missing from the sample code I linked (I'll report it to the
maintainer) so you might want to add those calls.
From: David Lowndes on
Julian,

>Essentially, it needs to decide right on startup whether it is
>going to behave like a Windows Application or a Console
>Application, based on argc/argv command-line parameters.
>
> Note that since this is a command-line development tool,
>it's not good enough for it to spawn a console window and
>write to that -- it has to be able to deal with output being
>redirected so that, for example, if it is run from an IDE like
>Visual Studio to compile some script code, the error messages
>get redirected correctly to VS's Output pane, or if I run it
>from cmd.exe like so:

I think you can use AttachConsole something like this:

AttachConsole( ATTACH_PARENT_PROCESS );

int hCrt;
FILE *hf;

hCrt = _open_osfhandle( (intptr_t)
GetStdHandle(STD_OUTPUT_HANDLE), _O_TEXT );
hf = _fdopen( hCrt, "w" );
*stdout = *hf;
int i = setvbuf( stdout, NULL, _IONBF, 0 );

SetConsoleCtrlHandler( HandlerRoutine, true );

.... though I don't know if it'd work for the VS output pane.

Dave
From: Pavel A. on
Console and GUI apps are not strictly separated.
You can create a console (even several of them) from a GUI app,
or create windows & dialogs from a console app.

If all you want from a console is displaying some debug trace,
you don't need a console at all. Just use any tool like dbgview.

--pa


"Julian Mensch" <jmensch(a)shaw.ca> wrote in message
news:98576c42-462b-4a73-9b86-7b65daa921f5(a)d9g2000prh.googlegroups.com...
> I hope I have the right group for this; I think so, because
> it's fundamentally about Win32 API calls.
>
> I currently have a large C++ application which, on startup,
> launches a GUI using the third-party Allegro graphics library.
> To work correctly doing this, I understand it need to be a
> Windows Application, not a Console Application. There's a
> few assorted reasons it needs to be a WinApp, anyway.
>
> However, it also has a secondary use as a development
> tool, for which I would like to support a command-line
> interface. I would think this wouldn't be a problem, since
> I can just bypass starting my graphics library and use the
> standard C++ libraries like cout or printf() -- but of course I
> can't, because it's a Windows Application and to support its
> main functionality can't be made into a Console Application.
> Essentially, it needs to decide right on startup whether it is
> going to behave like a Windows Application or a Console
> Application, based on argc/argv command-line parameters.
>
> Note that since this is a command-line development tool,
> it's not good enough for it to spawn a console window and
> write to that -- it has to be able to deal with output being
> redirected so that, for example, if it is run from an IDE like
> Visual Studio to compile some script code, the error messages
> get redirected correctly to VS's Output pane, or if I run it
> from cmd.exe like so:
>
> mytool.exe -c myscript.is > output.txt
>
> All the output goes to a text file rather than the screen. Is
> it even possible to do this with a Windows Application, and
> if so can someone tell me which API calls I need to research
> in order to achieve it?
>
> Thanks graciously for any help anyone can provide here!