Is it possible to have "console+menu" using ProjectBuilder?

Somewhere in the E.U., le 24/10/2003


In article <BBBE2051966812E9E1 RemoveThis @10.0.1.3>,
slavins RemoveThis @hearsay.demon.co.uk@localhost (Simon Slavin) wrote:

 > In article <Hubert.Holin-71FFD2.17492821102003 RemoveThis @mi.cerfacs.fr>,
 > Hubert Holin <Hubert.Holin RemoveThis @meteo.fr> wrote:
 >
  > > Using MetroWerks tools I could build an app which had a GUI
  > >(mainly a menu bar, and which allowed to chose files and such in a
  > >traditional GUI way), and a console-like window for std in/outputs.
  > >
  > > It is possible to do the same using only Apple-supplied developer
  > >tools (and if yes, how?)? Relaxing the conditions slightly, is it
  > >possiblee to do this using Apple-supplied tools and third-party tools,
  > >except MetroWerks' (and if yes, which ones and how?)?
 >
 > Write your application as a standard GUI application, but use
 > calls to a text interface engine which can handle the character-
 > based input and output.

Thanks

However, that's precisely what I want to avoid.

More precisely, the (portable) guts of the app can only make use
of ISO-C++ calls, such as writing to ::std::cout, and I do not want to
wrapp those with roll-your-own-this-is-text-output-as-per-your-platform
functions.

At this point I could go the way of a console tool. However I do
want to chose files in a platform-dependant maner, in the wrapping of
the guts, meaning I want a GUI (the guts only see streams, of course),
which is not possible with cconsole tools.

In short, I am seeking some kind of control which intercepts calls
to ::std::cout et al..

CodeWarrior has a tool which enabless me to do just this kind of
mixture app (because it has just that kind of component, even if it is
somewhat broken). The problem is that I understand less and less where
MetroWerks is going, if anywhere, and thus seek a possible way out of
that dependency. Additionally, testing code with more than one compiler
usually makes it more robust (this only apply to the guts portion, but
that of course is the most important part).

I could perhaps write a GUI front-end for choosing files and
spawning a console (or terminal, more appropriately) tool for the guts,
but then the passing of parameters between them would I assume (perhaps
erroneously) be quite constrained by the format of a command line.

Merci

Hubert Holin<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Is it possible to have "console+menu" using ProjectBuilder? 

In article <Hubert.Holin-9E9F6D.10434524102003.DeleteThis@mi.cerfacs.fr>,
Hubert Holin <Hubert.Holin.DeleteThis@meteo.fr> wrote:

 > More precisely, the (portable) guts of the app can only make use
 > of ISO-C++ calls, such as writing to ::std::cout, and I do not want to
 > wrapp those with roll-your-own-this-is-text-output-as-per-your-platform
 > functions.

In the future, it would probably be better not to hard-code ::std::cout
and friends, but instead use a parameter or a global variable that
contains the streams to use. That way you can redirect them painlessly
simply by changing what you set the global to, or by passing in a
different parameter.

 > At this point I could go the way of a console tool. However I do
 > want to chose files in a platform-dependant maner, in the wrapping of
 > the guts, meaning I want a GUI (the guts only see streams, of course),
 > which is not possible with cconsole tools.
 >
 > In short, I am seeking some kind of control which intercepts calls
 > to ::std::cout et al..

It's quite easy to redirect your program's standard input and output to
somewhere else in UNIX, see 'man dup2' for example. You could probably
point them to pipes and then have a very easy way to display all of your
stdin/out in a window.

 > I could perhaps write a GUI front-end for choosing files and
 > spawning a console (or terminal, more appropriately) tool for the guts,
 > but then the passing of parameters between them would I assume (perhaps
 > erroneously) be quite constrained by the format of a command line.

You can spawn the guts as a subprocess inside your own application and
redirect the subprocess's standard IO to pipes that you control, again.
This gets more complicated, but may be a better architecture for you. If
you're using Cocoa for the front-end, NSTask can make this fairly easy.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Is it possible to have "console+menu" using ProjectBuilder? 

In article <Hubert.Holin-9E9F6D.10434524102003 DeleteThis @mi.cerfacs.fr>,
Hubert Holin <Hubert.Holin DeleteThis @meteo.fr> wrote:

 > More precisely, the (portable) guts of the app can only make use
 > of ISO-C++ calls, such as writing to ::std::cout, and I do not want to
 > wrapp those with roll-your-own-this-is-text-output-as-per-your-platform
 > functions.
 >
 > At this point I could go the way of a console tool. However I do
 > want to chose files in a platform-dependant maner, in the wrapping of
 > the guts, meaning I want a GUI (the guts only see streams, of course),
 > which is not possible with cconsole tools.

You haven't said whether you're married to any particular API for your
GUI. If you aren't you could use Cocoa's NSTask class to launch your
command-line tools, writing to their stdin and reading from their
stdout. NSTask saves you from all that messy stuff like having to escape
parameters for the command line, and with Cocoa your GUI would be a lot
easier to write.

Otherwise you could drop down to the POSIX layer and use popen() or
fork()/exec() to do something similar with more manual labor.

I don't think there's a cross-platform way to replace stdin/stdout with
your own while the app is running, but you could search in the POSIX
docs. All I know about POSIX, I picked up on the go, and I might have
overlooked something. At worst, you could try looking at the Darwin
sources, maybe something there shows how you'd redirect stdin/stdout to
some other stream.

Hope any of this helps.

Cheers,
-- M. Uli Kusterer
<a style='text-decoration: underline;' href="http://www.zathras.de" target="_blank">http://www.zathras.de</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Is it possible to have "console+menu" using ProjectBuilder?