On Thu, 14 Oct 2004, Gary R. Van Sickle wrote: > > On Thu, 14 Oct 2004, Gary R. Van Sickle wrote: > > > > > [snip] > > > > >I thought if a GUI app called printf it generally caused a console > > > > >to be opened for it. Maybe that's only with msvcrt. In any case, > > > > >the fact is that it is being run from a cmdline and so it certainly > > > > >can communicate with the console. The presence of command-line > > > > >options in argc/argv could be taken as a fairly strong hint that it > > > > >was being run from a shell rather than an icon. And there's always > > > > >"isatty (1)" if you really really want to be sure. > > > > > > > > This is a windows limitation. GUI apps (apps created with > > > > -mwindows) can't send output to or receive input from the console. > > > > Of course, a GUI can interpret command line information. It just > > > > cannot send output to the console that started it. > > > > > > > > You could use AllocConsole to create a separate console which the > > > > GUI could then use, however. > > > > > > Here's a maybe-less-icky way to do it. Have two exes, one "setup.exe" > > > which is a 100% command-line program that normally just spawns > > > "winsetup.exe", the current GUI setup, and goes away. Give it > > > "--help", and it prints help in the regular command-line way and > > > exits. Yeah, two exes, but worse tragedies have happened. > > > > Well, running the command-line program will pop up a console > > window if it's not running from a console already. How's > > that different from just using AllocConsole in the GUI > > version? In fact, isn't this what MSVCRT does under the > > covers anyway? > > Igor > > AllocConsole can only pop up a *new* console (right?),
Quoting MSDN (<http://msdn.com/library/en-us/dllproc/base/allocconsole.asp>): A process can be associated with only one console, so the AllocConsole function fails if the calling process already has a console. A process can use the FreeConsole function to detach itself from its current console, then it can call AllocConsole to create a new console or AttachConsole to attach to another console. So, basically, if there's another console, that console will be used. > which doesn't buy anybody anything (it's worse than a dialog IYAM). > With the way I suggested you'd have: > > $ setup --help > Cygwin Setup Version blah blah blah > Usage: > -a Blah blah bl-blah blah blah. > ..... > > $ setup --option-one=Hello -XyZ > Doing command-line setup stuff, please watch the dots.....done. > > $ setup > << GUI version winsetup.exe is spawned >> > > Double-click on winsetup.exe ==> runs GUI version. > > Double-click on setup.exe ==> runs setup.exe which flashes a console (which > actually I think can be prevented), spawns winsetup.exe, and goes away. > > So in almost all (maybe even all) cases, you have no unused or new consoles > floating around and you get intuitive behavior. Yet another of "GRVS's Olde > Tyme Solutions Which Make Everybody Happy(TM)"! Or, we could just call GetConsoleWindow() and check for a NULL returned value (in which case we can even pop up a message box with help info). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
