> "Harvey J. Stein" writes
>
> First, I make two entry widgets and a button, and pack the button
> between the entry widgets:
>
> (require "Tk-classes")
> (define e1 (make <Entry> ))
> (define e2 (make <Entry> ))
> (define b (make <button>))
> (pack e1 b e2)
>
> I find the tabbing a little weird in this situation. Even though the
> button is visually between e1 & e2, the focus moves from e1 to e2 to b
> & back to e1 when tabbing.
>
> I presume this is because the tk:focus-next gets it's order from some
> list of subwidgets of the frame, and this list is basically in the
> order that the widgets were created.
>
> So, first question. Is there any way to easily change this?
Yes, If you want to make a widget ignored by the Tab key you can
set it's take-focus option to #f. For instance, just making
(set! (take-focus b) #f)
does the job.
>
> Now, I try to set things up so that when I tab in one entry, the focus
> moves to the other entry, and the focus never moves to the button:
>
> (bind e1 "<Key-Tab>" (lambda () (focus e2)))
> (bind e2 "<Key-Tab>" (lambda () (focus e1)))
>
> Now for the first problem. After doing the above bindings, I would
> think that if I'm in 1 entry widget and I hit <tab>, I'd end up in the
> other entry widget. But, this doesn't happen! Instead, the focus
> still insists on going from the 2nd entry widget to the button!
>
This is not a bug but the way bindings works with TK4.x. The binding
is applied (in this order) to: the widget, the class ("Entry" here)
the toplevel which contains the widget and all. In this case, there is
a tab binding for your entry and for all (the default action for Tab
that you want to overwrite). So yopur code is executed AND the default
code. So you have to block the code which is executed to your binding only.
This is done by returning the symbo break in your ecah closure:
(bind e1 "<Key-Tab>" (lambda () (focus e2) 'break))
(bind e2 "<Key-Tab>" (lambda () (focus e1) 'break))
> Figuring there must be some other binding involved, I looked at
> the binding tag list for e2, and got:
>
> STk> (bindtags e2)
> (#[Tk-command .v2] "Entry" #[Tk-command .] "all")
Ooops, I should change this. Normally you should see something like
(#[<entry> 80c03e8] "Entry" #[<toplevel> 80d72e4] "all")
to be coherent with the rest of STklos/Tk code.
>
> Checking the binding for key-tab in each of these, I saw:
>
> STk> (bind "Entry" "<Key-Tab>")
> (#[closure 80d81bc])
> STk> (procedure-body (car (bind "Entry" "<Key-Tab>")))
> (lambda () (#quote ()))
> STk> (bind *root* "<Key-Tab>")
> ()
> STk> (bind *root*)
> ()
> STk> (bind "all" "<Key-Tab>")
> (#[closure 80d06f8] |W|)
> STk> (procedure-body (car (bind "all" "<Key-Tab>")))
> (lambda (|W|) (focus (tk:focus-next |W|)))
> STk>
>
> This makes it looks like the problem might be that after my binding on
> e2, the "all" binding for <key-tab> is getting run, which then flips
> the focus to the button.
>
Yes, see just before.
> So, I wiped out the binding for <key-tab> on all:
>
> STk> (bind "all" "<Key-Tab>" "")
> ()
>
> Then I verified that it was gone:
>
> STk> (bind "all" "<Key-Tab>")
> ()
>
> Then I hit tab in the STk window, and the binding for <Key-Tab> on
> "all" magically reappears:
>
> STk> (bind "all" "<Key-Tab>")
> (#[closure 8175d38] |W|)
> STk> (procedure-body (car (bind "all" "<Key-Tab>")))
> (lambda (|W|) (focus (tk:focus-next |W|)))
>
> So my second question is, why in the world does this happen?!?!?
I cannot reproduce this! When the binding is deleted it doesn't reappear.
> Also, how can I get the thing to tab from one entry to the other, and
> never to the button? I suppose I could redefine tk:focus-next, but
> I'd rather not override library functions...
>
See before the take-focus option. Note that take-focus can be a
closure (with one argument). In this case, the function will be called
(with the widget passed as an argument) to the closure. The closure
must return a boolean value telling if it takes the focus or not.
> Now for the second problem. When I'm holding down the tab key (so as
> to rapidly move the focus from widget to widget due to a fast
> autorepeat), and I also move around the mouse inside the STk window, I
> start getting errors such as:
>
> *** Background error:
> eval: bad function in : (#[unknown 19 80c2e98] .v1)
> **** Tk error ("") "\n (command bound to event)"
>
Something with 19 value always denotes a GC problem :-< (19 correspnd
top the code of a free cell, i.e. one which has been freed by the GC).
However, I'm not able to reprocuce this. What is the release you have?
Received on Sun Oct 20 1996 - 21:09:11 CEST
This archive was generated by hypermail 2.3.0
: Mon Jul 21 2014 - 19:38:59 CEST