Tk Source Code

Attached patch winscrollbar-bindproc replaces the TkBindEvalProc ScrollbarBindProc with an ordinary event handler.

(Description to follow).

> backport candidate?

Not really.  A simpler and much less intrusive workaround for the bug that prompted it  has already been committed (#3006842, see below), this patch series was more for cleanup moving forward.

backport candidate?

Patch committed; closing.

... and if there are no further comments in the next day or two I plan to commit the patch, before it goes stale.

Notes from tcl-core mailing list: 

[ ~2 Jun 2010]
Jeff Hobbs asked:
> I read the comments, but I wanted to just check that in testing of this
> patch, should we expect/see _any_ difference in UX?

Confirmed: the patch should cause _no_ discernable difference in
user interaction with Tk scrollbars.

(There may be some program-visible differences, but -- I believe --
only under very unusual circumstances.)

[ ~7 Jun 2010]:

One programmer-visible change I thought of:

At present, under Unix and Windows -- but not Cocoa --
it's possible to completely override scrollbar behavior
by changing [bindtag]s.  With the patch, this will no
longer be possible under Windows or Carbon either,
since the built-in behavior is more deeply baked in.

(I don't think this is _too_ big a deal; as above, this
is already how things work under Cocoa, and if anyone needs this
type of thing it's still possible with the ttk::scrollbar.)

For further background, see Tk bug#3006842.   A workaround for that bug has been committed, but the intent of this patch series is to fix the underlying problem by removing the internal routine TkCreateBindingProcedure() altogether.  It's quirky (see e.g. header comment in Tk_DeleteAllBindings()), little-used, and adds significant hairiness to tkBind.c.

Second patch in series carbonscrollbar-bindproc.patch does something similar for the obsolete Carbon-native scrollbar: it replaces TkCreateBindingProcedure() with an ordinary event handler.

This is the last place in the Tk core (besides the test suite) that calls the internal routine TkCreateBindingProcedure().  

The only other place it has ever been used in the core was in win/tkWinMenu.c starting in release 8.0; that usage has since been replaced with ordinary binding scripts:

2003-04-14  Mo DeJong  <mdejong@users.sourceforge.net>
        * win/tkWinMenu.c (MenuKeyBindProc, TkWinMenuKeyObjCmd)
        (TkpInitializeMenuBindings): Rename MenuKeyBindProc to
        TkWinMenuKeyObjCmd and convert it into a Tcl command named
        tk::tkWinMenuKey. Bind keyboard accelerator actions to this Tcl command
        instead of using a native C binding. This makes it possible to extend
        the existing binding with Tcl code and makes the Windows version work
        just like the unix version.

File Added - 375876: carbonscrollbar-bindproc.patch

Notes: win/tkWinScrlbr.c is the only place where the TK_DEFER_MODAL / ClassProcs.modalLoopProc() machinery has ever been used in Tk.   carbon/tkMacOSXScrlbr.c (formerly macosx/tkMacOSXScrlbr,c, formerly mac/tkMacScrlbr.c) has similar environmental constraints as the Windows-native scrollbar, but it calls the tracking loop directly from ScrollbarBindProc.

I can't tell what the current macosx scrollbar implementation is doing, but all of the other Windows and Carbon native controls that require a modal loop enter it directly from a command procedure, event handler, or (in one case, see next patch) a binding procedure.

Current control flow in response to a ButtonPress event is:

- Tk_HandleEvent() calls TkBindEventProc calls Tk_BindEvent,
- which queues and later calls ScrollbarBindProc (binding procedure on "Scrollbar" bindtag)
- which sets the TK_DEFER_MODAL flag and returns.
- Later, Tk_BindEvent sees that TK_DEFER_MODAL has been set 
- and calls winPtr->classProcsPtr->modalProc()
- which is ModalLoopProc in win/tkWinScrlbar.c,
- which passes (what it assumes is a) ButtonPress event to TkWinResendEvent
- which reformats it as a Windows message and passes it to the Windows L"ScrollBar" WndProc,
- which enters a modal loop.


After the patch, the control flow is:

- Tk_HandleEvent() calls WinScrollbarEventProc (registered event handler),
- which calls ModalLoop() directly
- which passes the ButtonPress event to TkWinResentEvent ...
- which proceeds as before.

File Added - 375874: winscrollbar-bindproc.patch