Comment 7 for bug 1092873

On 01/09/2013 09:20 AM, Wayne Stambaugh wrote:
> On 1/3/2013 6:44 AM, Jacobo Aragunde Pérez wrote:
>> I have updated the .fbp to derive from DIALOG_SHIM and select the "save
>> & exit" button, and re-generated the .cpp and .h files. Unfortunately,
>> the focus doesn't work as expected. It doesn't work either in other
>> dialogs derived from DIALOG_SHIM, for example, in "Page settings" (e.g.
>> you can't press ESC to close it). It looks like the problem is
>> elsewhere, at least in my system.
>>
>> BTW I can attach the patches, but I noticed that the existing files had
>> windows-style line breaks, so my patches rewrote the files completely.
>> Is that a problem for you?
>>
> I finally figured out (remembered) what is going on here. You cannot
> simply set the focus to the dialog window to get the the escape key to
> work with wxGTK. You must set the focus to one of the child controls in
> the dialog. This problem goes all the way back to when I first joined
> project. I should have remembered this. Your assessment is correct
> that dialogs derived from DIALOG_SHIM do not honor the escape key
> correctly unless the focus is set to a child control elsewhere. We
> could modify the DIALOG_SHIM constructor to set the focus to the first
> child control using wxWindow::GetChildren() but this may yield some
> unexpected behavior if the user expects a control other than the first
> control in the list to have the focus. The other option is to update
> the constructors of every dialog box derived from DIALOG_SHIM (even
> dialogs that are not derived from DIALOG_SHIM can suffer from this
> problem) to set the focus to the appropriate control. My preference is
> the latter. I have updated DIALOG_EXIT_BASE and DIALOG_EXIT to confirm
> this behavior. I can commit the changes if you would like.

I need time to digest this. The idea of DIALOG_SHIM is it is to do the work for us.

I am going to challenge some of your assertions here, but don't have time now.

I think it has to do with whether you are using standard window IDs and what type of
buttons are in play.

I will resist any solution which does not comprehend the problem.

Later.

>
> Are the files with the windows style line breaks generated by
> wxFormBuilder? If so, I wouldn't worry too much about it. I haven't
> found way to force wxFormBuilder to use a given line break style. If
> the files are normal source files that you modified with your editor,
> then you need to configure your editor to honor the file's current line
> break style.
>