Version 8 of console - work with the parent window

Zipguy (2013-01-15) - You can find out my email address by clicking on Zipguy.

I've been thinking about How do you make two windows act as one?, and I started wondering about having the Console work with the parent window (the same as described in that article when minimizing/restoring them).

I noticed the command used in console -font? which was

    console eval { font configure TkConsoleFont -size 10 }

and thought what if I put the commands

 bind . <Unmap>      "console eval { wm iconify   .console}"
 bind . <Map>        "console eval { wm deiconify .console}"

into the code of the application that brought up the console with a button (named "Console"). So I did. That caused the application to produce an error message like this about thirty+ times:

and when you hit the Detail button:

I knew it was not a toplevel window. I tried to make it one, but that still failed. I'm looking into Tkcon which may have a toplevel window, or other things to do what I want.

Any ideas on what I should do to get the Console to work with the parent window? Any help would be great!.

Zipguy (2013-01-15) - I tried some wm commands with no success. But I did try

 console eval { puts "winfo id .console [winfo id .console ]"}

which gave me different results each time I ran it.

 winfo id .console 0x00000000010C02E2
 winfo id .console 0x0000000000A20CD0
 winfo id .console 0x0000000000640B4E ...

I could use this, if I knew how to tell Windows to iconify/deiconify this in C++, or assembler etc.

MG The console runs in its own interpreter, and has its own main toplevel window ".":

  % puts [console eval {winfo parent .console}]
  .
  % console eval {wm iconify .}

Zipguy (2013-01-15) - Thanks MG, that code works great! I have it like this:

 bind . <Unmap>    "console eval { wm iconify   .}"
 bind . <Map>      "console eval { wm deiconify .} ; focus .toolbar "

which does it make it work like one group of windows. It does work well.

I only have one more problem. In fact, it always seems to initially be on the console at first. Also, when I've clicked on the Appliction's minimize button, and I've clicked on the Application's Name to Restore it, both windows come back, but the focus has switched to the .console Window (instead of the Application's main window). I tried making the bind Map into focus on .toolbar, the main window, but now it always seems to focus on the console instead, until I click on the Application's window. hmmmm...

Zipguy (2013-01-17) - I've looked into it and found some more on it. RLE posted this on How do you make two windows act as one?.

RLE (2013-01-15): Try replacing "focus .toolbar" with "focus .". Also try adding a "raise ." just before "focus .toolbar". Also try instead of "focus ." running focus upon the text widget within the main application window.

I tried it because I tried the .toolbar and the button, and they didn't work. "raise ." did an interesting thing. I literally did raise the the application window but did not change the focus at all. It looked like this:

What I had in mind, my objective was this:

I thought maybe because I didn't have a "entry" field on the screen, so, I changed it to one like this:

    set f .ftxt.ftxt0
    pack $f      -side top -fill x -pady 3m
    button $f.l1       \
        -text "File:"  \
        -command "open_file" \
        -anchor w  -justify left
#                          -bg $_EZS(bfcolor)  -fg $_EZS(bbcolor)
    pack $f.l1   -side left
    entry $f.fn                    \
        -textvariable _EZS(kitname) \
        -justify left    -width 75
#        -anchor w -justify left    -width 75
#         -fg $_EZS(ffcolor)  -bg $_EZS(fbcolor)
    pack $f.fn   -side left  -expand 0 -anchor w -fill both

And in the routine which is used by

        bind . <Map>                                        "mapwin"

is this:

   proc mapwin { {item .ftxt.ftxt0.fn} } {
        console eval { wm deiconify .}
        raise .
        focus .
        focus $item 
   } 

It looked like this:

and that did not work either. Dang! You can see that the focus is working (once you click on the main window):

MG I would guess that the 'focus' is taking place before the console has finished being deiconified, and Windows is automatically giving the console the focus when it finishes being mapped. You could try delaying the focuses (with a small-timed after, or after idle), or you could try using tk wait to check the console has been mapped - though, since it's in a different interpreter, I'm not sure off the top of my head how you'd do that. Probably have to do it all in console eval, and then use consoleinterp eval to run the focus in the main interpreter again. focus -force may also stop Windows giving focus back to the console when it's fully mapped, but I'm not sure without trying it.

Zipguy (2013-01-18) - I tried the "after idle" command and the "after 600" command, which I think is running in the main interpreter, and that did not work. The code I'm talking about was a "raise ." + "focus ." inside the after command. It was executed about 30 times in the "mapwin" procedure, all at the same second of the clock, according to the "puts_log" routine. I looked at the "grab" command, which does not look good, in this aspect. I'm also looking at the "winfo" and "wm" commands as well.

I did look at the console eval which is cool! Thanks for that. Not quite sure if I fully understand that yet. If I wrote a command like this:

 console eval {winfo geometry .}

it would not display in the console. However if I typed it into the console, it would display in there: 483x177+79+28 or something like that. One of the things on my to do list is to increase the width of the console, which would be nice to be able to retrieve the answer of 483 wide pixels from the console, and add 100 pixels to it, then format it to $geospec and give the command:

  console eval {wm geometry $geospec}

but that command would say

 can't read "geospec": no such variable

because it's running in the console's interpreter, and the variable is back in the main intepreter. So I think what you're saying is that I could use consoleinterp eval to retrieve the desired variable from the main intpreter from within the console eval command. So how would I code that? Like this?:

  console eval {wm geometry [consoleinterp eval $geospec]}

or would I have to have a procedure, called lookup_geospec, which returned the variable back as return value which I could do by?:

  console eval {wm geometry [consoleinterp eval lookup_geospec]}

I'm not sure of it yet.

Anyway, here's the program I've been trying to fix which is called ezsdxv76e.kit which is at [L1 ]. It is a little large (160k), because it also contains sdx.kit inside of it, zipped, which it will copy to your directory (in unzipped form) when you first run the "Easy SDX" program. After that, it will check to see if the sdx.kit is already there, which there will be, and it will say "No need to copy sdx.kit".

There is another program which is working just fine with two windows, which is extremely small (1.1k). You can Minimize one window, and the other one minimizes. If you restore the main window, the other one will restore also. It's called bindb.kit which is at [L2 ].

Another thing on my to do list is to have "Easy SDX" accept commands like

  ezsdx.kit D:\dl\dcl\mine\icons\fontman.vfs\lib\app-fontman\filename.tcl wrun

which the MLv125c would be editing, which would allow the editor to issue commands like this. ezsdx.kit would intpret it to change directoried and issue the commands

 sdx::sdx wrap filename.kit  
 exec D:\dl\dcl\mine\tclkit-8.5.8.exe D:\dl\dcl\mine\icons\filename.kit &

which would get it to run. Also "Easy SDX" would check it to make sure there was a .kit file, 3 directories up from where the filename.tcl was being editted. Then "Easy SDX" would terminate because it has an '&' to run the command. So that would make it easier to integrate it with MLv125c, or higher. It might not be worth it to do that now, but I hate having to save it it in the editor, and then clicking on the "Wrap+Run" button. Yes, I'm lazy, but creative. LOL