Wanted: auto-focusing behavior

Vladimir Ignatov wrote:

Hello!
What is the best/recommended/working approach for gaining the
"auto-focusing" behavior? I want focus that "follow" the mouse cursor so
every controls became "focused" once I point to them. ( I try handle
"EVT_ENTER_WINDOW" but they don't work for grid (google tell me this event
is broken under Windows) ).

wxGrid is composed of several windows. Try binding the event to grid.GetGridWindow() instead of just grid.

And another question. Is it possible to scroll (with mouse wheel) control
that pointed by cursor (the cursor is "over it") but not yet focused?

Depends on the platform and probably the control, and if some other window has the mouse captured, etc.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

> What is the best/recommended/working approach for gaining the
> "auto-focusing" behavior? I want focus that "follow" the mouse cursor

so

> every controls became "focused" once I point to them. ( I try handle
> "EVT_ENTER_WINDOW" but they don't work for grid (google tell me this

event

> is broken under Windows) ).

wxGrid is composed of several windows. Try binding the event to
grid.GetGridWindow() instead of just grid.

Thank you, Robin. This works. But I am run in another troubles. What object
I should bind for SET_FOCUS/KILL_FOCUS events (the Grid itself or
Grid.GetGridWindow() )? And what object shoud be targeted for switching
focus manually (via .SetFocus() ) ?

Actually I am test the both objects and see a strange behavior.

1) I can't receive any FOCUS events for the Grid itself.
2) I receive FOCUS events fine then Grid.GetGridWindow() is binded, EXCEPT
the one case:
    shifting focus with TAB key does not trigger SET_FOCUS event. ( but
shift+TAB work okay and does trigger event)

    Vladimir Ignatov, KMI Software

Vladimir Ignatov wrote:

Actually I am test the both objects and see a strange behavior.

1) I can't receive any FOCUS events for the Grid itself.

Because it never gets it.

2) I receive FOCUS events fine then Grid.GetGridWindow() is binded, EXCEPT
the one case:
    shifting focus with TAB key does not trigger SET_FOCUS event. ( but
shift+TAB work okay and does trigger event)

The grid captures TAB and uses it to change cells, and it retains the focus. It should behave the same with Shift-Tab, I'm not sure why it doesn't.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

<Control_1> -> <MyGrid> -> <Control_2>

Then Control_2 is focused, then pressing SHIFT+TAB does trigger SET_FOCUS
event for MyGrid.
But then Control_1 is focused, then pressing TAB does NOT trigger focus
event for MyGrid.

I noticed this earlier this year and entered a bug report about it, but it
seems to have fallen through the cracks because it continues to come up as
an issue fairly regularly.

Is it on the radar screen to fix it?

-Rick King

Rick King wrote:

<Control_1> -> <MyGrid> -> <Control_2>

Then Control_2 is focused, then pressing SHIFT+TAB does trigger SET_FOCUS
event for MyGrid.
But then Control_1 is focused, then pressing TAB does NOT trigger focus
event for MyGrid.

I noticed this earlier this year and entered a bug report about it, but it
seems to have fallen through the cracks because it continues to come up as
an issue fairly regularly.

Is it on the radar screen to fix it?

I don't know. You can check if there are any comments or status changes on the bug report, or ask about it on wx-dev.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Frank Millman wrote:

Hi all,

A little while ago I reported some problems using a customised grid cell
editor. The problems occur only with MSW, not with Linux. Platforms are
Windows 2000, Python 2.2.2, wxPython 2.4.0.2u, and RedHat 9, Python 2.2.3,
wxPython 2.4.1.2u.

1. Pressing "enter" on a cell normally takes you to the next row. If you are
inside a customised grid cell editor, and if there is a default button on
the panel, pressing "enter" activates the button instead.

2. Pressing "tab" on a cell normally takes you to the next cell. If you are
inside a customised grid cell editor, you are taken to the next control
outside the grid. If you continue tabbing until you reach the grid again,
the cell editor completes correctly. Even if there are no other controls on
the panel, you still have to tab at least one extra time.

Robin advised adding the following style to wxTextCtrl -

wxTE_PROCESS_TAB|wxTE_MULTILINE|wxTE_NO_VSCROLL|wxTE_AUTO_SCROLL

It works, but I have now come across a side-effect. On pressing F2 to enter
edit mode, the left/right/home/end keys no longer work.

Within the edit control or once you return to the grid? Do any of the grids in the demo have this problem?

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Frank Millman wrote:

I wanted to use keyboard shortcuts for the two icons. As far as I can tell,
you cannot do this without adding a menu bar, but I found a neat (ugly?)
solution. I created two wxButtons, set up event handlers to invoke the same
methods as the icons, and positioned them at (1000,1000), which is off the
screen so they are invisible. I created an Accelerator Table to set up the
shortcuts - Alt-P and Alt-N.

There is no need for the buttons. Using a wxAcceleratorTable will deliver EVT_MENU events even if there is no menu. Just adding the following in MyToolBar.__init__ is enough:

         EVT_MENU(panel, prev_id, panel.grid.OnPrev)
         EVT_MENU(panel, next_id, panel.grid.OnNext)

So far so good. However, I also use a grid cell editor, so pressing Alt-P or
Alt-N gets processed by the editor first. This is where the problem arose. I
traced the problem to the following method.

    def IsAcceptedKey(self, evt):
        if sys.platform == 'win32':
            return (not (evt.ControlDown() or evt.AltDown()) and
                evt.GetKeyCode() != WXK_SHIFT)
        else:
            return evt.GetKeyCode() not in (WXK_SHIFT, WXK_ALT, WXK_CONTROL)

You will see that I use different routines for MSW and GTK2 - this is my
workaround. Without it, the first routine causes GTK2 to crash with a
segmentation fault, and the second routine causes MSW to crash with
'Python.exe has generated errors and will be closed by Windows'. If I omit
the method altogether, GTK2 still crashes, but MSW works ok without it.

Both work okay without it for me.

On both platforms, the crash occurs inside the NewPage() routine, at the
point where it is appending rows. If I comment out the calls to NewPage(),
no errors occur.

Adding this to the begining of NewPage will probably help:

         if self.IsCellEditControlEnabled():
             self.DisableCellEditControl()

An afterthought - it is possible that the problem is caused not by the
different platforms, but by the different versions of wxPython. You will see
above that I am using 2.4.0.2u on MSW, and 2.4.1.2u on GTK2. Can anyone
confirm this? If so, my workaround must test for the version instead of the
platform. What is the correct syntax for testing for 'version < x'? I seem
to recall a recent discussion about getting at the underlying components of
the version number.

Before 2.4.1.2 the only thing available with all version components is the wxPython.wx.__version__ string. Starting with 2.4.1.2 you also have a wxVERSION tuple and a wxVERSION_STRING string.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!