Wish as a shell for C/C++ app
W. Olin Sibert
C/C++ application. The project has two goals:
1) Replace the application's existing toy command interpreter with Tcl,
and replace the commands with Tcl-invoked command procedures, to
allow a familiar style of command-line interaction but with the more
powerful Tcl environment; and
2) Provide one or more GUI interfaces to various application functions.
I've started by defining commands in a DLL (linked with the rest of the
application) and "load"ing the DLL in a Wish shell. From there, the
user can invoke commands directly or interact with a GUI that is defined
by the script Wish starts up with. All this works as expected, but
there are a couple of things I haven't figured out how to do:
- When Wish is started without a script, it returns but leaves the Wish
window running. When a script is specified, the Wish command doesn't
return until Wish window exits. Is there any way to get standard
Wish to return immediately when started with a script, so that
multiple instances could be started from a batch file? (This is a
Windows question, of course; on Unix the answer is ampersand). It'd
also be nice if Wish could be made to print its prompt after running
a startup script.
- The existing application code is chock full of printfs that report
various internal activities. When it runs in a console environment,
those just produced console output, but when running under Wish, the
output never appears. What's the best way to get such output to
appear on the Wish console, interspersed with the commands that
caused it? Some of the commands are long-running and produce
intermediate output during execution, so it's not enough to capture
all the output and see it at the end--it should appear on the Wish
console as it's generated. I'm looking for a solution that will work
both for commands invoked directly from the Wish prompt and commands
executed during GUI interactions.
- Because some of the commands are long-running, I'd like to be able to
interrupt them and get back to the top level Wish prompt, much like
^C gets back to a shell prompt (essentially, I want Wish to act like
a regular shell). I understand that there are some synchronization
difficulties here (like recognizing ^C at all), but it's OK if the
application has to poll for those. The question here is how to
unwind past one or more levels of Tcl interpreter (because the
commands may themselves invoke other Tcl scripts) and get back to the
top level in Wish without the interpreter deciding it's been left in
some kind of "active" state. The few experiments I've tried produced
results like an error message from Tcl_DeleteInterpreter.
I'm sure someone has dealt with these issues before, so if there's
anyone who can point me at existing solutions or techniques, I'd greatly
appreciate it. Please CC me directly (w...@world.std.com) as I do not
always have access to the newsgroup.
The work is being done with Tcl 8.0.3. The initial port is for the
Windows environment, but eventually the application needs to run on Unix
again; are there any special peculiarities there? Is the DLL technique
appropriate, or should I have my own Tk_AppInit? Should I be using
something other than Wish for the "console" interaction?
Thanks -- Olin Sibert (w...@world.std.com)
--
Olin Sibert |Internet: Sib...@Oxford.COM
Oxford Systems, Inc. |UUCP: uunet!oxford!sibert
Robin Becker
<w...@world.std.com> writes
>I want to integrate a Tcl/Tk-based user interface into a large existing
>C/C++ application. The project has two goals:
> 1) Replace the application's existing toy command interpreter with Tcl,
> and replace the commands with Tcl-invoked command procedures, to
> allow a familiar style of command-line interaction but with the more
> powerful Tcl environment; and
> 2) Provide one or more GUI interfaces to various application functions.
>
>I've started by defining commands in a DLL (linked with the rest of the
>application) and "load"ing the DLL in a Wish shell. From there, the
>user can invoke commands directly or interact with a GUI that is defined
>by the script Wish starts up with. All this works as expected, but
>there are a couple of things I haven't figured out how to do:
>
> - When Wish is started without a script, it returns but leaves the Wish
> window running. When a script is specified, the Wish command doesn't
> return until Wish window exits. Is there any way to get standard
> Wish to return immediately when started with a script, so that
> multiple instances could be started from a batch file? (This is a
> Windows question, of course; on Unix the answer is ampersand). It'd
> also be nice if Wish could be made to print its prompt after running
> a startup script.
.bat command script. Under Unix you could always background the jobs.
With win32 you could do this with a tcl script execcing in background
mode.
>
> - The existing application code is chock full of printfs that report
> various internal activities. When it runs in a console environment,
> those just produced console output, but when running under Wish, the
> output never appears. What's the best way to get such output to
> appear on the Wish console, interspersed with the commands that
> caused it? Some of the commands are long-running and produce
> intermediate output during execution, so it's not enough to capture
> all the output and see it at the end--it should appear on the Wish
> console as it's generated. I'm looking for a solution that will work
> both for commands invoked directly from the Wish prompt and commands
> executed during GUI interactions.
direct yourself. I've used this technique to direct (using Tcl commands
the output into Log windows etc).
>
> - Because some of the commands are long-running, I'd like to be able to
> interrupt them and get back to the top level Wish prompt, much like
> ^C gets back to a shell prompt (essentially, I want Wish to act like
> a regular shell). I understand that there are some synchronization
> difficulties here (like recognizing ^C at all), but it's OK if the
> application has to poll for those. The question here is how to
> unwind past one or more levels of Tcl interpreter (because the
> commands may themselves invoke other Tcl scripts) and get back to the
> top level in Wish without the interpreter deciding it's been left in
> some kind of "active" state. The few experiments I've tried produced
> results like an error message from Tcl_DeleteInterpreter.
won't get acted on if the underlying wish is busy.
The problem is then how to signal your long running process/dll command.
If the process is internal then you'll need to poll both the GUI (using
update to check for ^C etc) and the signal. When the signal is detected
you have to force an error exit from the outermost DLL routine. Raise an
error if in Tcl etc.
>
>I'm sure someone has dealt with these issues before, so if there's
>anyone who can point me at existing solutions or techniques, I'd greatly
>appreciate it. Please CC me directly (w...@world.std.com) as I do not
>always have access to the newsgroup.
>
>The work is being done with Tcl 8.0.3. The initial port is for the
>Windows environment, but eventually the application needs to run on Unix
>again; are there any special peculiarities there? Is the DLL technique
>appropriate, or should I have my own Tk_AppInit? Should I be using
>something other than Wish for the "console" interaction?
tkCon from Jeff Hobbs
>
>Thanks -- Olin Sibert (w...@world.std.com)
>
--
Robin Becker
W. Olin Sibert
W. Olin Sibert <w...@world.std.com> wrote:
>I want to integrate a Tcl/Tk-based user interface into a large existing
>C/C++ application.
> window running. When a script is specified, the Wish command doesn't
> return until Wish window exits. Is there any way to get standard
> Wish to return immediately when started with a script, so that
> multiple instances could be started from a batch file? (This is a
> Windows question, of course; on Unix the answer is ampersand). It'd
> also be nice if Wish could be made to print its prompt after running
> a startup script.
This problem appears more subtle than I first thought; thanks to Robin
Becker for the Win 95 hint.
What appears to happen is that on Windows NT (4.0 SP3), but not Windows
95, when I start Wish80 (Tcl/Tk 8.0.3, just installed from the Tcl Blast
CD-ROM) in a batch file, the next command in the batch file does not
execute until after the Wish application has exited. If I run Wish80
from the NT Command Prompt command line, it works as expected, and both
the batch file and command line versions behave as expected on Windows
95 (i.e., the Wish window comes up, but the command prompt reappears or
the next command in the batch file executes). The problem does not
appear to have anything to do with having a startup script file for
Wish as I originally believed.
Any suggestions for an NT workaround? Does anyone else see this
behaviour? Or is this problem unique to my system?
Dave LeBlanc
wrote:
<snip>
>What appears to happen is that on Windows NT (4.0 SP3), but not Windows
>95, when I start Wish80 (Tcl/Tk 8.0.3, just installed from the Tcl Blast
>CD-ROM) in a batch file, the next command in the batch file does not
>execute until after the Wish application has exited. If I run Wish80
>from the NT Command Prompt command line, it works as expected, and both
>the batch file and command line versions behave as expected on Windows
>95 (i.e., the Wish window comes up, but the command prompt reappears or
>the next command in the batch file executes). The problem does not
>appear to have anything to do with having a startup script file for
>Wish as I originally believed.
>
>Any suggestions for an NT workaround? Does anyone else see this
>behaviour? Or is this problem unique to my system?
The NT equivelant of '&' is start:
start wish80 <args>
will start it in a new process and then execute the next command in
the batch script.