[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] zoomDocProc() bug?



Chris Nandor writes on Sat, 7 Mar 1998 13:13:27 -0500

>$win = MacWindow->new(
>  Rect->new(50,50,300,100), 'Welcome to MacPerl',
>  1, zoomDocProc(), 1
>);
>
>The above code fails with zoomDocProc() (hard crashing).  On two different
>PPC machines.  Any thoughts?

The problem was reported some time ago -- by Philippe de Rochambeau I
think. Both zoomDocProc() and kApplicationWindowKind() return the constant
'8', and both cause a crash when used as the 'PROC' in MacWindows(). A
PowerMac here and a 68k Powerbook crash similarly.

However, '8' may be used as the 'PROC' argument in MacDialog() or
NewWindow() with no problem, so I suspect the bug lies somewhere in
MacWindows().

>Also, any thoughts why zoomNoGrow() does not end in 'Proc' like all the others?

No.  PlainDBox() is another.

The five 'constants' (you pointed out some time ago that they are not
really 'constants' but functions which return a constant) which serve the
same purpose do not end in 'Proc' either, namely:

        StandardWindowDefinition
        kRoundWindowDefinition
        kFloatingWindowDefinition
        kModalDialogVariantCode
        kMovableModalDialogVariantCode
        kSideFloaterVariantCode

The matter is somewhat confusing since several of the window definitions
return the same number (and therefore draw the same window):-

Constant == 0     documentProc()
                  kStandardWindowDefinition()

Constant == 1     kRoundWindowDefinition()
                  kModalDialogVariantCode()
                  dBoxProc()

Constant == 2     plainDBox()
                  kDialogVariantKind()

Constant == 8     zoomDocProc()
                  kApplicationWindowKind()
                  kSideFloaterVariantCode()

Also zoomNoGrow() (returns 12) and kFloatingWindowDefinition() (returns
124) both appear to produce the same window.

There is another point about MacWindows() which it might be helpful to
mention here, namely that  MacWindow() draws a GrowBox by default, even in
windows without a 'grow' capability, for instance zoomNoGrow().

This is not a bug in MacWindows(), since the drawing of the GrowBox icon
can always be overridden to avoid a dysfunctional icon, but just the way it
behaves.

However, MacWindows() does not attempt to draw a GrowBox icon in the
'nogrow' floating pallettes (1985-1989, and 1993-1997).

The 'floating pallette' type windows developed later in the hitory of the
MacOS do exactly what their names lead you to expect. That cannot be said
of the earlier ones. The muddle probably reflects the history of the MacOS,
which Windows.pm is forced to inherit.

I made some notes about what the various definitions do which I have
e-mailed to Chris but would be happy to send to anyone else interested.

Alan Fry



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch