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

Re: WDEF in Lisp!



>> MCL calls #_GrowWindow only if (grow-icon-p <window>) returns true,
>> i.e. you created the window with:
>
>I remember looking at this and thinking that it's entirely un-necessary
>since a window will _never_ return #$wInGrow unless it has a grow icon
>anyways, why have a check to see if the window has a grow icon?  what
>should really be happening here is a call to a customizable method
>called, say, handle-grow-click, or track-grow-select that, by default,
>handles clicks in the grow region in a default way, but allows users
>to customize that behavoir easily.

You're right that a WDEF won't return #_inGrow unless it has a grow
icon. For standard document windows, however, the grow icon won't be
drawn unless MCL calls #_DrawGrowIcon. Hence, if there is no visible
grow icon, MCL pretends that #_inGrow means #_inContent, as this is
correct behavior for the most common type of window. Designers of windows
that draw their grow icons outside of the content region in response
to, e.g., #_HiliteWindow, are responsible for ensuring that grow-icon-p
returns true. MCL's documentation on this point is sorely lacking (er...
non-existent).

If grow-icon-p returns true, MCL's event handling code calls
window-grow-event-handler, which you can specialize as you wish.
My statement that "MCL calls #_GrowWindow" was a description of the
behavior of the default window-grow-event-handler method.

>
>> Unfortunately, if (grow-icon-p <window>) is true, MCL will call
>> #_DrawGrowIcon with drawing clipped to the 15 pixel square at the
>> lower right hand corner of the window's view-size rectangle.
>> This will be wrong for a custom WDEF.
>
>if anywhere, this should be a :before or :after method for updating
>the content area of windows of type documentProc, since that is the
>_only_ place where it makes any sense for it to appear--afterall, you
>are drawing into the contents of the window when you ask for the
>grow icon to be drawn.  As well, this doesn't need to be done for all
>windows that have grow regions--wdef's will only draw a grow icon
>if the grow icon is in the content area--some wdef's draw their grow
>region in their struct region.

The call to #_DrawGrowIcon happens inside the default window-draw-grow-icon
method. See my message of last week where I talked about specializing
that method and the patch that makes a method out of invlidate-grow-icon.