| launching native apps and redirecting stdout to a console view [message #258295] |
Mon, 05 July 2004 01:26  |
Eclipse User |
|
|
|
How can win32 application be started using launch configuration delegate
and have its stdout redirected to a console view? Eclipse launch
configuration framework approach is preferred to external tools approach.
win32 app is not jvm.
It was very straightforward to create a launch configuration delegate in a
non-ui plugin as well as launch configuration tabs and shortcuts in ui
plugin counterpart. I have also found how to activate console view, create
my own MessageConsole class and its message streams by looking at the
examples in eclipse tests plugin.
However, activating console view from launch configuration delegate does
not seem appropriate since we start introducing ui classes to a non-ui
plugin. How can console be activated/created upon native application
launch and have native application connect to a message stream of a
console while keeping ui and non-ui classes separate?
All the best,
Vladimir
|
|
|
| Re: launching native apps and redirecting stdout to a console view [message #260227 is a reply to message #258295] |
Fri, 09 July 2004 13:03  |
| Eclipse User |
|
|
|
Vladimir wrote:
> (snip)
>
> However, activating console view from launch configuration delegate does
> not seem appropriate since we start introducing ui classes to a non-ui
> plugin. How can console be activated/created upon native application
> launch and have native application connect to a message stream of a
> console while keeping ui and non-ui classes separate?
I think this is a pertinent question, since searching the CDT, JDT, etc.
source base demonstrates that there are several approaches taken to
implement the launch + console + stream management + error message
parsing needed to integrate a command line tool into Eclipse.
I don't want to reinvent something that has already been done, but I
also don't want to create a plugin that depends on CDT just to get the
console and stream filtering behavior, ui.externaltools to get some
launcher constants, plus debug.ui in addition to debug.core. On top
of that, ui.externaltools is all "internal" code.
Basically it seems like I have to violate several Eclipse "best
practices" in order to reuse the existing classes, as Vladimir
points out.
It might help a little if someone on the development team would drop
a few hints on how to minimize future rework as the "external tools"
API grows some official "core" classes.
Thanks,
Tom Johnson
|
|
|
Powered by
FUDForum. Page generated in 0.02880 seconds
Home