lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Overriding wx member functions


From: Greg Chicares
Subject: Re: [lmi] Overriding wx member functions
Date: Tue, 29 Nov 2005 19:50:12 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

On 2005-11-27 14:58 UTC, Vadim Zeitlin wrote:
> On Sat, 26 Nov 2005 23:40:47 +0000 Greg Chicares <address@hidden> wrote:
[full context:]
>> 2. I noticed that the OnChildFocus() handler in 'xml_notebook.cpp'
>> doesn't call the base-class function of the same name, probably with
>> the ultimate effect that wxControlContainer::SetLastFocus() doesn't
>> get called. That seemed to be a possible explanation for this problem:
>>   File | New | Illustration
>>   Ctrl-Tab six times, to get to the 'Face' tab
>>   now Ctrl-Tab has no further effect; neither do Tab, Enter, or Cancel
>>     and I'm guessing that a wxPanel in the notebook has the focus
>>   activating another application, then reactivating lmi, gives focus
>>     to the 'Face' notebook tab; then keyboard navigation works again
>> I tried calling wxDialog::OnChildFocus() at the top of lmi's handler,
>> but that didn't solve the problem. Should I attempt to solve it in lmi,
>> or is this a wx library issue?
> 
>  Yes, it is quite possible. Please try adding event.Skip() to see if it
> fixes the problem.

No, it didn't help. I looked into it and here's what I found.

The 'Face' tab is selected (using the keyboard).

Its first control receives focus (as reported by diagnostic code I
temporarily added to the EVT_CHILD_FOCUS handler).

Then the EVT_UPDATE_UI handler is called. One of its effects is to
disable the focused control. At this point, temporary diagnostic
code in the EVT_UPDATE_UI handler reports that
  0 == FindFocus()
is true.

In your opinion should wx prevent this condition?

Anyway, to fix it now in the production version of lmi, I'll do:

    if(!FindFocus())
        {
        SetFocus();
        }

I had tried something fancier:

    if(!FindFocus())
        {
        SetFocus();
        // Try to find a window that should be enabled for input:
        wxWindowList::compatibility_iterator node;
        for
            (node = CurrentPage().GetChildren().GetFirst()
            ;node
            ;node = node->GetNext()
            )
            {
            wxWindow* w = node->GetData();
            if(w && w->IsEnabled())
                {
                w->SetFocus();
                break;
                }
            }
        }

but that didn't quite work: it "focused" a groupbox (that's what
it looks like--actually it's whatever this xrc code
  object class="wxStaticBoxSizer"
produces).

Is there an easy way to distinguish controls that would normally
accept input from things like groupboxes?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]