4.01 - Graphics Problem with Windows 98 but not NT or 2000

Friends,

My Dolphin app has a rather elaborate custom widget that paints lines and
text on a canvas. It is resizeable, so it determines the position of things
based on the size of the canvas.

When I run it on Windows98 the coordinates all seem to be measured from the
x/y origin of the monitor, rather than of the canvas. As a result, the app
is painting lines and text all over the screen, mostly near the upper
left-hand corner of the monitor - but not on the canvas itself. Even when I
move the shell around, the characters and lines are positioned relative to
the monitor.

Runs perfectly on NT and Win2000.

Any thoughts ? Am I using a bunch of deprecated methods ?

Best wishes, and thanks,

Ken

Ken,

> My Dolphin app has a rather elaborate custom widget that paints lines and
> text on a canvas. It is resizeable, so it determines the position of
things
> based on the size of the canvas.
>
> When I run it on Windows98 the coordinates all seem to be measured from
the
> x/y origin of the monitor, rather than of the canvas. As a result, the app
> is painting lines and text all over the screen, mostly near the upper
> left-hand corner of the monitor - but not on the canvas itself. Even when
I
> move the shell around, the characters and lines are positioned relative to
> the monitor.

You'll find that it will do the same thing on Win95 too.  I tracked this
down to Font>>initialize, which has been changed for the benefit of console
app stripping.  The following change:

Font>>initialize
 "Initialise the receiver."

 super initialize.
 (logfont := LOGFONT new) lfWeight: FW_NORMAL.

 "This is it:  revert to 4.0:
 resolution := Canvas forDesktop resolution."
 resolution := View desktop resolution.

fixed my app which was doing exactly what you describe.  Even though the
more stable OSs do ok with the 4.01 code, I think (if I'm following it) that
it should be changed, as it creates and finalizes an HDC every time a font
is created.

The part I don't understand is why Win9x machines draw all over the desktop,
why they don't seem to crash as a result, and why the behavior is so
consitent.  Did you also find that it tended to do the same thing every
time?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill -

> You'll find that it will do the same thing on Win95 too.  I tracked
this
> down to Font>>initialize, which has been changed for the benefit of
console the
> more stable OSs do ok with the 4.01 code, I think (if I'm following
it) that
> it should be changed, as it creates and finalizes an HDC every time a
font
> is created.
>
> The part I don't understand is why Win9x machines draw all over the
desktop,
> why they don't seem to crash as a result, and why the behavior is so
> consitent.  Did you also find that it tended to do the same thing
every
> time?

Yes, it was pretty consistent. However, I noticed that it painted all
over the desktop, and then also on the canvas, correctly, at times...oh
well.

In any event, your fix worked ! Thanks so much !

Best wishes,

Ken

"Ken Lee" <[hidden email]> wrote in message
news:99i53m$188tq$[hidden email]...
> Bill -
>
> > You'll find that it will do the same thing on Win95 too.  I tracked
> this
> > down to Font>>initialize, which has been changed for the benefit of
> console
> > app stripping....

Hats off to Bill for find the cause of the problem.

It is in fact a resource exhaustion problem, though not a resource leak. The
new Font initialize method is allocating a desktop Device Context, but
leaving it to be released by finalisation. Consequently the DCs are returned
to the OS as a "background" activity triggered by garbage collection.
Although this usually happens fairly quickly, it is not immediate. This is
fine on NT/2k, because there is no arbitrary limit on DCs, but on Windows
95/98 (to quote from MSDN): "Windows 95/98: There are only 5 common DCs
available per
thread, thus failure to release a DC can prevent other applications from
accessing one."

Now 5 is a very small number, and easily exhausted by a View which creates a
few Fonts when painting. For example if we modify the
HelloWorld>>onPaintRequired: method to include a loop as follows:

onPaintRequired: aPaintEvent
    ...."as before"...
    2 to: 20 by: 2 do: [:p |
        canvas font: (Font name: 'Arial' pointSize: p)
            text: 'Hello from Dolphin' at: rect center - (60 @ 10)]

And then do a 'HelloWorld show', at least one of the Hello messages will be
painted on the desktop (on Windows 95/98).

This is very easily fixed as follows:

Font>>initialize
    | dc |
    super initialize.
    (logfont := LOGFONT new) lfWeight: FW_NORMAL.
    dc := Canvas forDesktop.
    resolution := dc resolution.
    dc free

Running the same HelloWorld test now will work as expected.

Bill has quite rightly pointed out to me that it might be an idea to cache
the resolution for the sake of efficiency, and indeed it takes about 250
microseconds on a P133 running Win98 to retrieve the desktop resolution each
time. If one were creating a lot of Fonts, then this might be significant,
so when we patch Font>>initialize via LiveUpdate we will do just that. In
the meantime the attached at least leaves the desktop pristine!

Explained by the above I think?

Regards

Blair
























begin 666 Font_initialize.st
M(49O;G0@;65T:&]D<T9O<B$-"@T*:6YI=&EA;&EZ90T*"2));FET:6%L:7-E
M('1H92!R96-E:79E<BXB#0H-"@E\(&1C('P-"@ES=7!E<B!I;FET:6%L:7IE
M+@T*"2AL;V=F;VYT(#H]($Q/1T9/3E0@;F5W*2!L9E=E:6=H=#H@1E=?3D]2
M34%,+@T*"61C(#H]($-A;G9A<R!F;W)$97-K=&]P+@T*"7)E<V]L=71I;VX@
M.CT@9&,@<F5S;VQU=&EO;BX-"@ED8R!F<F5E#0HA("$-"B%&;VYT(&-A=&5G
M;W)I97-&;W(Z("-I;FET:6%L:7IE(6EN:71I86QI>FEN9R%P=6)L:6,A("$-
#"@T*
`
end

Blair -

> > Yes, it was pretty consistent. However, I noticed that it painted all
> > over the desktop, and then also on the canvas, correctly, at times...oh
> > well.
>
> Explained by the above I think?

Perfectly

- Ken