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).

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...

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:

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 [1]. 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 [2].

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

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. Also, it would make "Easy SDX" available to any other editor, as well. 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

console eval {wm geometry $geospec}
but that command would say
can't read "geospec": no such variable

If you want to pass a variable between interpreters, you need to do your call this way:

console eval [ list wm geometry $geospec ]

That will look up "$geospec" in the current interpreter, and format everything properly to pass it to "wm geometry" in the console interpreter.

Zipguy (2013-01-21) - RLE Thanks. I now know how to use the list function to supply the $geospec that has been calculated, as mentioned above. You can have a look at Console - getting width from console interp and see where I'm stuck at today. Sorry for continuing to have problems. :(