comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Problems with the "mwindows" switch
Date: Fri, 29 May 2015 16:24:37 -0500
Date: 2015-05-29T16:24:37-05:00	[thread overview]
Message-ID: <mkalel$7h7$1@loke.gir.dk> (raw)
In-Reply-To: 37731869-bfb2-47b1-b0cf-7e4e806019c1@googlegroups.com

<sbelmont700@gmail.com> wrote in message 
news:37731869-bfb2-47b1-b0cf-7e4e806019c1@googlegroups.com...
On Thursday, May 28, 2015 at 6:19:09 PM UTC-4, Randy Brukardt wrote:
>>
>> Of course there is, you just need some support from the runtime.
>>

>The ability of which I was referring was the ability to have a program that 
>can dynamically
> select whether to use the inherited console (i.e. if you run the 
> executable from a command
> prompt, to output the text to the existing console) or to open a new 
> window.  A GUI app
> that allocates its own console but is ran from the command prompt will 
> open a new window
> to print the text, which is normally not the desired behavior.

That's harmless, though, since the primary reason to use Text_IO in the 
first place is for error/crash reporting. Where that goes is not 
particularly relevant. And if you really mean to write to a console in the 
GUI program, a separate window is usually a benefit, as it is much more 
similar to the way the rest of the app works.

The one thing that I do want in some cases is to be able to capture the 
output (that is, redirect the output to a file), and that works on some of 
my machines but not others (even with the separate window, and differing 
even for the same Windows version). I'm not sure why that is, but it's 
clearly possible to redirect the output that is going to a separate console 
window.

> Making a CUI app will work right when spawned from the command line, but 
> will always
> open its own console when spawned by double clicking the icon, even if 
> there is no output,
> which is also normally not the desired behavior.

Agreed, although the problem there is that CUI apps should never be run by 
clicking on icons. That's fairly easy to do, too, don't register the silly 
icon to the desktop or the start menu -- it's not designed to be run there. 
(No one navigates to a directory to click something.)

So while I understand what you are thinking is missing, it seems pretty 
unnecessary to me.

                                  Randy.





  reply	other threads:[~2015-05-29 21:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-22 18:35 Problems with the "mwindows" switch NiGHTS
2015-05-22 19:24 ` sbelmont700
2015-05-22 19:51   ` NiGHTS
2015-05-23  5:33     ` Dmitry A. Kazakov
2015-05-23  7:20       ` NiGHTS
2015-05-23  8:06         ` Dmitry A. Kazakov
2015-05-28 22:19   ` Randy Brukardt
2015-05-28 23:49     ` sbelmont700
2015-05-29 21:24       ` Randy Brukardt [this message]
2015-05-29 21:36         ` Jeffrey R. Carter
2015-05-29 22:10           ` Simon Wright
2015-05-30  0:08           ` Dennis Lee Bieber
2015-06-01 21:24           ` Randy Brukardt
2015-06-01 23:12             ` sbelmont700
2015-05-29 11:00     ` Björn Lundin
2015-05-23 20:23 ` gautier_niouzes
2015-06-02 22:33   ` NiGHTS
2015-06-03  6:42     ` Simon Wright
2015-06-03  8:27       ` J-P. Rosen
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox