>> And how the heck do I figure out *where* the corner of the screen is? 
> 
> I would ask for the coords of the window in the system tray and go from 
> there? I haven't done it, but it can't be all that hard. I'm almost 
> certain you can get the screen size in pixels from Tcl.

Right. And now how do I figure out how big the system tray is? (You 
realise it's resizable, right?)

> Now, that's assuming you only have one screen.

That's a safe assumption for the purposes of this project. ;-)

> To answer your question precisely, "winfo screenheight" and "winfo 
> screenwidth" are what you're looking for, I think. "winfo" and "wm" 
> control all that sort of stuff. (WM referring to the window manager, so 
> it controls borders and focus and such. The documentation doesn't 
> clarify for me how to avoid taking focus when you create a window.)

I find the documentation for Tcl/Tk to be especially difficult to 
follow. For example, I *still* can't figure out the correct way to 
specify a font name. The page that's meant to tell you just rambles on 
about a bunch of C functions... WTF?

>> (And, for that matter, avoid stealing the input focus when the window 
>> opens?)
> 
> I think Windows prevents this from happening in the first place in 
> general, but that's a good question.

I'll check later...

>> It's a scripting language. It doesn't really "do" error-handling. If 
>> something goes wrong, the script tends to just choke in an 
>> unpredictable way.
> 
> No. You're thinking of C. Tcl chokes in very predictable ways. Indeed, 
> at work, I use a Tcl monitoring process to restart all the craptastic 
> C++ stuff that dumps core about once a week.  (Not that C++ is 
> necessarily craptastic, but this stuff is.)

Right. So when the server runs out of disk space, my Tcl script 
unceremoniously halts, and rather than the interpretter shutting down, 
it just *sits* there. And since it's a background task, I have *no way* 
of discovering what the hell went wrong, and no way of shutting it down 
other than forcably killing the interpretter. Cool. Is that what the 
spec says?

> Between [catch] and [bgerror], Tcl should never do something 
> unpredictable. Maybe you don't know how Tcl behaves, but it really is 
> well-defined.

Frobbing bgerror is just painful. catch looks more useful...

>> Many of the Tcl scripts I run seem to leak memory pretty badly. I did 
>> have a Tcl script that did something every 5 minutes - but I 
>> discovered that the longer it runs, the more RAM it eats. I now rerun 
>> the script every 5 minutes using an external tool.
> 
> I have Tcl programs that run literally months without being touched. If 
> you're leaking memory, it's because you're storing stuff in globals and 
> not cleaning up after yourself.

No, not really. Just recursing over some directories. Memory usage 
starts at about 2 MB, and grows linearly by about 50 KB every second. 
Usually the script finishes before it actually reaches more than 8 MB, 
but on occasion it doesn't.

> Granted, there is occasionally a leak in Tcl's memory handling described 
> in the bug tracker. But it's rare, and they're all high priority to get 
> fixed because people build real systems with Tcl.

How would I know about that? I downloaded Freewrap a few years back and 
have been using it ever since. Still on the same version number.

So... you're saying that my particular Tcl interpretter just has a 
memory bug in it?

>> There are many, *many* things that work unexpectedly in Tcl. But then, 
>> the language isn't really set up for making production-grade 
>> applications, it's designed for quickly throwing things together that 
>> work on the day you test them.
> 
> I disagree. I've written all kinds of server stuff in Tcl that runs for 
> months without being touched, that automatically recovers from my 
> mistakes, and so on. If you can't get it to work for you, it's because 
> you don't know how, methinks.

The whole "hey, let's not bother with datatypes and stuff, let's just 
store everything as flat strings and reparse them every time we need to 
touch something" concept simply *wreaks* of quick and dirty prototyping. 
No sane person would design production-grade software this way, with no 
safety checks or anything.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message