[[Describe.]] Three senses: * Tk within frame of other application (written in, for example, Visual C++). So far, only works--barely--with IE. * [Embedding Windows applications in Tk frames] * Tk application that also invokes, say, MFC widgets. This might involve, in particular, [Using MFC Controls as Tk widgets]. [Jeffrey Hobbs] and [David Gravereaux] know the most about these. None of them really work as of January 2002 without a lot of fiddling ... ''(except for MFC widges in Tk, see below)'' [Arjen Markus] There may be a connection with [Drawing Into Foreign Windows]. [Frame] and [toplevel] bear on this topic. If an external X11 application has a command-line option to configure its placement (as, for example, xanim's +Wid), then mumble-mumble used with the -container of toplevel and frame. "man [winfo]" gives information on X11-id-s. Credit [Andreas Leitgeb] with this observation. ----------------------------------------------------- placing the Tk widgets in IE has been simplified by using the TclControl activeX. Using the IE version 6.0, I have found it to be the most stable... TclControl can be found at: http://www.sys.uea.ac.uk/~fuzz/optcl/default.html I have made little to no changes to many Tcl/Tk apps that can run within the IE window... Yes you still need to have a copy of Tcl/Tk installed (but so does java requires a VM to be resident)...Of coarse you need to worry about security issues by allowing the activeX to access Tcl... James Garrison [[Explain tangential connections of [TclScript] and [GPS] work.]] ---- The point of TclScript is to plug in the Tcl '''language''' as an IE extension. This would mean that IE would be able to parse pages with the following type of script code:
This isn't quite the same as the ActiveX component which has more to do with placing a Tk toplevel widget onto the browser window and processing Tcl script within itself. Of course at present (Jan 2002) TclScript remains vapour-ware (or maybe liquid-ware as there is code, it's just not useable :) ) but I hope to find the time to continue at some point this year. [PT] ---- '''Using MFC Controls as Tk widgets (MS Windows only)''' I wrote a C++ class that allows the use of any MFC based Windows control as a pseudo Tk widget. The class is based on a proprietary library so I cannot disclose the source code, but it was pretty straightforward, and makes only minimal use of Tk's internals. Here's some code to get the CWnd* for a Tk widget: (''Path'' is a char* with the widget path name, or NULL for get the application's main window): Tk_Window const tkmainwin = Tk_MainWindow(interp); if (tkmainwin==NULL) return NULL; Tk_Window const tkwin = Path==NULL ? tkmainwin : Tk_NameToWindow(interp,Path,tkmainwin); if (tkwin==NULL) return NULL; Tk_MakeWindowExist(tkwin); Window const window = Tk_WindowId(tkwin); if (window==NULL) return NULL; HWND const hwnd = Tk_GetHWND(window); if (hwnd==NULL) return NULL; CWnd *const Wnd = CWnd::FromHandle(hwnd); if (Wnd==NULL) return NULL; return Wnd; Use this to find the parent window which you pass to CWnd::Create. After that, the MFC control will mostly take care of itself. In order to get geometry management right, I demand all of those MFC widgets to be the child of a standard Tk frame widget, and I use ''bind NameOfTheFrame '' to trap moves and resizes of the frame in order to move resp. resize the MFC widget along with the frame. The MFC control isn't a real widget, e. g. it's not managed by a geometry manager (but its parent frame widget is) and it can't be removed with the ''destroy'' command (but it will be removed when its parent frame is destroyed), yet the look and feel is identical to both pure Tk and a native Windows dialog. The whole class is less than 300 lines of C++ (including comments). I successfully used it to embed a complex custom MFC widget (derived from CComboBox with a custom CEdit-derived edit control) in a Tk program. Terminology note: ''control'' = user interface element in Windows/MFC, ''widget'' = user interface element in Tk. ''Wolfram Roesler , 12-July-2002''