RE: dynamic fonts change.

> By the way there is 2 way to fix it in win32: - Create a big offscreen
> buffer (Like the desktop size instead of window size) and use
> StretchBlt() to draw it resized(smaller) in the window.

Actually, I thought of this, and even tried it (but never released the
code) here were the problems with this method:

   -- the characters were hard to read when they had been resized too far.
   -- this allowed you to stretch the screen to any size, which meant you
        could stretch the characters out so they were very oblong and
        weird looking.  This isn't what people expect :)
   -- It ran significantly slower because StretchBlt is slower than
        BitBlt (for obvious reasons)


> - Update the font on resize and use the new adjusted font.

That's what I'm doing now.  That's the part that's "available but doesn't
work well."  What I really need to do is get a list of the possible window
sizes, and then check the WM_SIZING event so that the user will change the
size only to nice sizes.  (for example, the way the MS-DOS prompt works
when you drag the corner)

What happens now is that I use GetClientRect() to find out how big the
area is, and simply divide it by the columns/rows that I need.  I pass
these sizes to CreateFont() which returns a font that doesn't always match
the dimensions I gave it, so sometimes the font is too small, and
despite documentation to the contrary, sometimes it's too big.   This
leaves me with a font that doesn't actually fit in the Window, so
characters are getting chopped off.

So, to fix that, I resize the window to match the font...  You'd THINK
that this would cause the Window to simply grow to the new font size,
since the WM_SIZE event would then divide the clientrect and get the
correct sizes for the font -- but instead Windows will give me a different
font... it ends up doing a few resizes, and then finally settles on
something.

Of course, that causes problems because when they maximize and then
minimize, or when they switch from/to 80 & 132 columns, it doesn't always
end up with the same size.

With some particular fonts, this means that when the screen is maximized,
some letters may not fit on the screen.

With other fonts, the math ends up resizing to one font size down each
time you switch from/to 132 col mode... so this ends up with a "magically
shrinking window".

These are the problems I need to solve.  What I've got in my local source
tree right now is a routine that goes through all the possible sizes for a
font and loads them into a structure.   During WM_SIZING events it
searches the structure for a matching size.  During WM_SIZE events, it
simply uses the font found in WM_SIZING...   but this too casues problems,
since things like minimize and maximize don't generate WM_SIZING events.

But, my thought is that if I know the window sizes ahead of time, I won't
need to resize the window to match the font because I'll only use a font
that already matches the window size, thus solving the "magical font
shrinking" problem.   Plus, I can calculate for myself the largest font
that'll fit on a maximized screen without overflowing.

> Currently I use the 2nd method but I think the first is simpler to
> design, I just didn't though about it when I coded... :)

The first is certainly simpler!  But it doesn't work the way people
expect it to.   If you have nicely working resizing in your ActiveX
control, I'll have to look at that.  Maybe I can use it as an example for
how to fix the Win32 terminal.

Just thinking about it gives me a headache :)