Re: Oakley combobox focus bug

Bryan Oakley wrote:
Kevin Walzer wrote: 
Bryan Oakley wrote:


I don't quite understand what you mean by "does not yield focus". Can you describe what is happening?


See http://www.wordtech-software.com/combobox_1.png and http://www.wordtech-software.com/combobox_2.png for an example. The first shows the combobox attached to its parent window; the second shows the combobox with focus even after I've changed applications.


So, by "focus" you really mean that the dropdown list isn't vanishing when the progam loses focus?

The root cause seems to be that a global grab is failing. The combobox does a global grab while the widow is visible and just about any event other than selecting something in the listbox should release the grab and hide the window. Apparently that isn't happening on OSX.

Looking through the code (wow, that was fun; haven't been here in years!)... apparently I assumed that mechanism always works so I don't explicitly handle <FocusOut> (which I assume the widget gets if you switch to a different window).

Interestingly, I included a comment that says, in effect, that on Windows you'll see the behavior you're seeing.

Here's a couple of possible fixes:

Look for this code, roughly line 633 or so:

    "<FocusOut>" {
        if {![winfo ismapped $widgets(dropdown)]} {
        # did the value change?
        set newValue [$widgets(entry) get]
        if {$oldValue != $newValue} {
            CallCommand $widgets(this) $newValue
        }
        }
    }

You might add an else clause, like so:

  if {![winfo ismapped $widgets(dropdown)]} {
    ...
  } else {
    # make sure the dropdown is unmapped if we lose focus
    WidgetProc $w close
  }

A different solution might be to modify ::combobox::SetClassBindings to include:

  bind Combobox <FocusOut> [list $this close]

I'm not sure if the latter will work; focus management is kinda weird inside the combobox to get bindings to work both in the entry and in the dropdown listbox at the same time.


If you remove the -command option, do you still see the focus problem? 


Yes. It is still there when I switch to another application.


Ok, so the -command is likely a red herring. I was guessing that while the command was running and you switched, the app isn't processing events and thus doesn't know to close the dropdown window.

If that's the case, my fixes above might not work, but maybe they'll help. If the fixes don't work, but adding the fixes and removing the -command *does* work, that will verify my theory. Then it's just a matter of writing your proc to service the event loop as it is running.

Is it possible to refactor DisplayPorts so that it does not take a long time to run? Does DisplayPorts execute some other process or is it just a bunch of Tcl code?


It's an external process.

If that's the case, run it in a pipe rather than exec it. That will solve the problem of the GUI being unresponsive while the proc runs. 
Bryan,

Thanks for these suggestions! I will give them a try and report back.

--
Cheers,

Kevin Walzer, PhD
WordTech Software - "Tame the Terminal"
http://www.wordtech-software.com
sw at wordtech-software.com
.

Quantcast