Mail Archives: cygwin/2004/10/15/11:14:43
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/
|\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com
|,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/
- Raw text -