tkcon in a C application
iu2
I'm adding tcl to my C application. I did it!
I also want to supply a decent console for invoking my C functions via
tcl. I'll appreciate if you could help me with this:
1. I tried Tcl_Eval("console show") but it didn't recognize the
"console" command.
2. I used tkcon like this: Tcl_Eval("exec wish tkcon.tcl &"). tkcon
showed up but it didn't recognize my newly registered commands.
I've noticed that tkcon doesn't recognize new commands even when
activated from a regular tcl script.
I'm not sure I initialized Tk from the C code preperly (I called
Tk_Init...) and if this is the reason I'll appreciate it if you could
show me how it should be done.
Thanks
MartinLemburg@UGS
the problem is, that you started a new process with the command ...
exec wish tkcon.tcl &
This new process is NOT able to communicate with your C application!
With this way you won't get a remote tcl console!
The next problem is, that you need Tk for the "normal" regular tcl
console!
So your using tkcon.tcl in your C application wouldn't be possible.
So some questions:
1. Is your C application a console application or has your C
application a console/terminal window (like on Unix/Linux)?
=> if so, use the console by generating a prompt with C or tcl to
evaluate the user input from the prompt.
2. Has your C application a GUI using on MS Windows e.g. WIN32 or on
Linux using e.g. wxWindows?
=> build your on text widget based dialog and connect the callbacks to
a loaded tcl script containing procedures to be connected with the
dialog callbacks.
The application I'm working on is an MFC based application, which has a
CEdit based dialog with C++ callbacks. The console works fine,
comparable to the tkcon and provides even breakpoint capabilities in
tcl via new tcl commands.
Good luck and much fun!
Martin
iu2
Hi Martin and thank you for your response,
Regarding my application, it is a GUI one written in Borland C++. I
first tested my registered commands using a simple dialog and and text
control. But I wouldn't like to build a gui around that (execute
command, show prompt, catch errors and print them). I prefer, if
possible, use a Tk component for this purpose.
MartinLemburg@UGS
> Regarding my application, it is a GUI one written in Borland C++.
Good - so you would have access to GUI components to build a prompt.
> I first tested my registered commands using a simple dialog and and text
> control. But I wouldn't like to build a gui around that (execute
> command, show prompt, catch errors and print them).
So the first step is done!
> I prefer, if possible, use a Tk component for this purpose.
You can try to load Tk into the tcl interpreter and than to source
tkcon.tcl.
I tried it with our MFC/tcl application. The "package require Tk" was
successfull, but there was no root window, and the console command
didn't work and threw no error.
Before extending our distribution to contain Tk too, before exploring
the problem, how to load Tk in an MFC application I decided to use the
MFC CEdit GUI component to create a MFC tcl console.
And it was not that problematic.
So ... you must first try to do a "package require Tk" inside you
application and see if it works. If it works just source tkcon.tcl and
you'll have your console, but I think it won't work, because Tk has its
event loop or must be included in the main event loop of the GUI, so
that Tk is really able to work!
For MFC there was a project introducing a second tcl thread with its on
event loop connected to the main thread event loop, but ... this model
create new problems.
Good luck and still much fun!
Martin Lemburg
Neil Madden
> Hi all,
> I'm adding tcl to my C application. I did it!
Consider turning this scenario around -- do you need your application to
be a C application that embeds Tcl, or can you design it to be a Tcl
application that [load]s some custom C code? Many people find the latter
option to be more satisfying. You can then load your custom code into
any Tcl interpreter (e.g. tclsh, wish, tkcon), rather than limiting it
to just your custom application. http://wiki.tcl.tk/11153 has become
quite a nice introduction to building a dynamically loadable Tcl C
extension, if you are already familiar with C. You might also like to
read http://wiki.tcl.tk/9303 for discussion of the pros and cons of
embedding vs extending.
Even with the embedded route you will likely want to structure your code
as a package with a Myext_Init(Tcl_Interp *) function, as tkcon creates
a slave interpreter for the actual console and you need to register your
commands in that too (probably via [load {} Myext]).
-- Neil
Stéphane A.
iu2 wrote:
> Hi all,
> I'm adding tcl to my C application. I did it!
> I also want to supply a decent console for invoking my C functions via
> tcl. I'll appreciate if you could help me with this:
>
> 1. I tried Tcl_Eval("console show") but it didn't recognize the
> "console" command.
Hi "iu2",
Maybe you should try Tcl_Eval("tkcon show") ?
This is AFAIK the standard to launch a new Tkcon session,
*embedded* into an application.
Indeed, I often use this scheme when I want to debug an application:
<TCL>
catch {source tkcon.tcl}
bind . <Control-d> {tkcon show}
</TCL>
Regards,
Stéphane
iu2
Hi guys,
Thanks for your help.
I spent a little while myself on that problem and I found some help in
the tkcon source code comments and on the wiki at
http://wiki.tcl.tk/1878.
Martin, I eventually managed using Tk by entering the event loop with
Tcl_Eval("vwait forever"); (forever is just a name, never defined
variable).
To use tkcon I created the namespce ::tkcon and set variable OPT(exec)
to {} (as explained in the above wiki page). After that sourced
tkcon.tcl and only then vwait forever. It recognized my registered
commands. The wiki page gives more details about possible problems.
Neil, thanks for the references, I would too prefer extending than
embedding, but I'm referring to an already existing full blown C app.
Having introduced to tcl, I don't know why bother programming in C for
PC in the first place...;-)
Stéphane, thanks. I wasn't aware of the "tkcon show"
Christian Gollwitzer
> Hi guys,
>
> Thanks for your help.
> I spent a little while myself on that problem and I found some help in
> the tkcon source code comments and on the wiki at
> http://wiki.tcl.tk/1878.
>
> Martin, I eventually managed using Tk by entering the event loop with
> Tcl_Eval("vwait forever"); (forever is just a name, never defined
> variable).
The only problem (maybe) here is, that this will stop your application
from responding to events to its own GUI. So if you have already buttons
etc., they will become irresponsive, and even if this is intended, the
application will not even repaint. In order to have your program respond
to both commands from its own GUI as well as commands sent by the tcl
console, you would have two merge both event loops. Regarding MFC, there
is some discussion on
However, even though the manpage of the Tcl Notifier promises that
external event loops can easily be coupled in, it is a complex task to
get it right.
Another possibility would be to run your Tcl interpreter in a second
thread, letting the OS do the scheduling. But then you must take care
that all functions, that can be called from tcl, are reentrant. YMMW
Christian
MartinLemburg@UGS
yes - a "vwait forever" will definitely freeze the application and its
GUI, so ending a kind of debug console with "console hide" or "tkcon
hide" must definitely change the variable forever to stop the "vwait"
command.
> However, even though the manpage of the Tcl Notifier promises that
> external event loops can easily be coupled in, it is a complex task to
> get it right.
With MFC it is impossible to get right to the source of the event loop
and to wheeve in the tcl/Tk event loop.
And it's not that easy to register an event handler to the main loop to
be called.
> Another possibility would be to run your Tcl interpreter in a second
> thread, letting the OS do the scheduling. But then you must take care
> that all functions, that can be called from tcl, are reentrant. YMMW
That's the reason, why we came back to a one-threaded application,
because we got stuck in "racing conditions".
Best regards,
Martin Lemburg
On Jan 23, 11:07 am, Christian Gollwitzer
<Christian.Gollwit...@uni-bayreuth.de> wrote:
> iu2 wrote:
> > Hi guys,
>
> > Thanks for your help.
> > I spent a little while myself on that problem and I found some help in
> > the tkcon source code comments and on the wiki at
> >http://wiki.tcl.tk/1878.
>
> > Martin, I eventually managed using Tk by entering the event loop with
> > Tcl_Eval("vwait forever"); (forever is just a name, never defined
> > variable).The only problem (maybe) here is, that this will stop your application
iu2
Christian Gollwitzer wrote:
> The only problem (maybe) here is, that this will stop your application
> from responding to events to its own GUI. So if you have already buttons
> etc., they will become irresponsive, and even if this is intended, the
> application will not even repaint. In order to have your program respond
> to both commands from its own GUI as well as commands sent by the tcl
> console, you would have two merge both event loops. Regarding MFC, there
> is some discussion on
>
> http://wiki.tcl.tk/15861
>
> However, even though the manpage of the Tcl Notifier promises that
> external event loops can easily be coupled in, it is a complex task to
> get it right.
>
> Another possibility would be to run your Tcl interpreter in a second
> thread, letting the OS do the scheduling. But then you must take care
> that all functions, that can be called from tcl, are reentrant. YMMW
>
> Christian
HI,
I havn't noticed any problem (yet) in the gui's responsiveness. Indeed,
in the beginning my C gui froze. This happend when I entered the Tk
event loop right upon my application window creation. I noticed another
thing, that with only Tcl_Main my entire app existed right after tcl
has been initiated.
Hence I changed tcl initialization, instead of Tcl_Main and Tk_Main I
wrote this
Tcl_FindExecutable("project1.exe");
app_interp = Tcl_CreateInterp();
Tcl_Init(app_interp);
Tk_Init(app_interp);
Swig_Init(app_interp); // my regsiter commands
Entering the Tk event loop with Tcl_Eval("vwait forever") is invoked by
a button press. No my app doesn't hang.
The init process is not 100% right though, I still have problems with
Tk libraries loading (tckIndex stuff and direcotories), maybe I'll post
a question here about it if I don't manage doing it right...
Israel