From: Julian Mensch on 10 Dec 2009 12:38 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 10 Dec 2009 18:39 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 10 Dec 2009 18:49 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 10 Dec 2009 18:50 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 10 Dec 2009 18:46 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!
|
Next
|
Last
Pages: 1 2 3 Prev: How to read a symbolic link? Is there a POSIX readlink() equivalent? Next: win7 service popup |