I am investigating how my code is losing focus. When the user clicks on an edit box, which sets focus, it then is creating a form which is parented on the same form, and the focus is lost from the edit with the click. If the child form is not created, that is, it already exists, then the focus stays just fine.

I added a few debug calls to the WebUI core code. It turns out that the problem is happening in TElement.UpdateFocus, and not SetFocus or RemoveFocus. If that function is not called, then it doesn't steal focus away. Does anyone (Tim?) know what can be done to stop this? Or how to overcome it.


--

Matthew Jones

Matthew Jones wrote:

> TElement.UpdateFocus

Is there a way to get the name of the component that the element is related to in this call? Hacks welcome, this isn't for release code. I can't see a "parent" or "owner".

--

Matthew Jones

Matthew,

<< I added a few debug calls to the WebUI core code. It turns out that the problem is happening in TElement.UpdateFocus, and not SetFocus or RemoveFocus. If that function is not called, then it doesn't steal focus away. Does anyone (Tim?) know what can be done to stop this? Or how to overcome it. >>

UpdateFocus is called when a) the tab order is changed for a control, or b) when an internal Boolean property called FocusEnabled is changed for UI elements.

However, none of these changes should cause the focus to actively change (they only affect the tab order and whether the UI element is focusable, not whether it *has* focus).  Otherwise, you couldn't add focusable UI elements to the application while another control has focus.  Obviously, that would break a lot of browser applications.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> none of these changes should cause the focus to actively change

Could you tell me what might do that? It isn't the calls to SetFocus that are doing it. The key here is that I am creating new forms, parented on a formlist (my variation on TList) in a panel on the form that contains a FormList which contains forms one of which has the focus.
It only happens when the FormList has to create a new form for a list value. I am not doing any explicit focus change.

--

Matthew Jones

Matthew,

<< Could you tell me what might do that? It isn't the calls to SetFocus that are doing it. The key here is that I am creating new forms, parented on a formlist (my variation on TList) in a panel on the form that contains a FormList which contains forms one of which has the focus.
It only happens when the FormList has to create a new form for a list value. I am not doing any explicit focus change. >>

If you're creating and showing new forms, then it's possible that the focus change is occurring when the form is shown, depending upon how the form is created.  If you parent the form into another control as part of the creation process (Parent=Owner), then you shouldn't have any issues. If you create the form, show it, and *then* parent it into another control, then you will see a focus shift if there are any focusable controls on the form and Application.AutoFocus=True (it's true, by default, for all non-mobile applications):

http://www.elevatesoft.com/manual?action=viewprop&id=ewb2&comp=TApplication&prop=AutoFocus

If you want to email me something, I can take a look and tell you what's causing the focus shift.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>  If you parent the form into another control as part of the creation process (Parent=Owner), then you shouldn't have any issues. If you create the form, show it, and then parent it into another control, then you will see a focus shift if there are any focusable controls on the form

Bingo! The key is "hidden" in your response, so I will make it explicit. My code was using the Panel/List etc as the parent, but the thing that was not mentioned is that my form is "visible" in the designer. So the first thing it is doing is showing itself, presumably before it is parented. By just changing the visible property to false in design, the code works perfectly without stealing focus.

Thanks for the information and hint.

--

Matthew Jones