This Question is Answered

14 "helpful" answers available (3 pts)
3 Replies Last post: Mar 10, 2008 11:10 AM by Kamal

an AppletGraphic prevents controls from getting the keyboad focus

Mar 10, 2008 9:58 AM

Click to view fukuta's profile Level 6 fukuta 74 posts since
Oct 17, 2007
When a dialog is shown by its 'show' method, a first control on the dialog gets a keyboard focus automatically.
But I put an AppletGraphic on it and show it like this;

def ad = {AppletData
{AppletGraphic width={add-stretch}, height=10px},
{url "sub-applet.curl"}
}
def dialog =
{Dialog
{spaced-vbox
{TextField},
ad.ag
}
}
{dialog.show}

A TextField above doesn't get focus.
Is it possible to give the TextField focus?
Click to view Kamal's profile Curl Kamal 99 posts since
Oct 17, 2007
1. Re: an AppletGraphic prevents controls from getting the keyboad focus Mar 6, 2008 10:31 AM
First i would say that it is a bit strange for me to have an AppletGraphic inside a dialog. Any way I will attempt here to explain what is going here and then will give you a workaround.


When you add an AppletGrapic to a View (in this case when you call "show" method of the Dialog you are making a View where the Dialog in question will be shown), its child window is given the focus. Note that at this point of time there are two View's. The top level View that contains the Dialog and the AppletView that contains the AppletData.

In order to make the TextField in your Dialog take the focus, you will have to somehow make the Dialog's View take the keyboard focus (takeing it away from the Child View).

There are APIs for changing the object that has focus (see
request-key-focus for example) but there is no public API for
requesting a View's Window get the focus. There is aworkaround however, via our support for automated testing via
Mercury QuickTest. If you call prepare-test-parent on a View it
will take the keyboard focus in order to prepare for playing back arecorded script. The snippet below shows how you can use it.
Note that this is a workaround at best. It could interfere with the
use of QuickTest and if you should subclass View and override
prepare-test-parent the call might have undesired side effects(which you could avoid by calling (v asa View).prepare-test-parent).
Every workaround is a compromise of course, and this could be
sufficient to solve your current problem.

Here is the code that you will need to add to your Dialog constructor. Note that the DialogShow event handler is fired at the Dialog after the Dialog is added to a View and is shown.

{on DialogShow at d:Dialog do


|| We are adding an artificial delay here so that the focus is already given to the


|| AppletGraphic's child window by the gui-toolkit system before we take it away.


{after .2s do


{if-non-null v = {d.get-view} then


{v.prepare-test-parent}


}


}


}

Note that "prepare-test-parent" calls the method to set the focus to the View's Window and hence wll help us here to force the focus to the Parent view.

Message was edited by: Kamal

Message was edited by: Kamal

Click to view fukuta's profile Level 6 fukuta 74 posts since
Oct 17, 2007
2. Re: an AppletGraphic prevents controls from getting the keyboad focus Mar 10, 2008 9:57 AM
in response to: Kamal
Thanks. I was able to get the behavior I expected.

By the way, the code using some delay cannot ensure that view's window get the focus every time.
(but almost every time, it works fine)
Is this correct?
Aren't there any reliable way to do the same thing?

Thanks in advance.
Click to view Kamal's profile Curl Kamal 99 posts since
Oct 17, 2007
3. Re: an AppletGraphic prevents controls from getting the keyboad focus Mar 10, 2008 11:10 AM
Note that when a Curl windows gets the Focus it notifies each of its child windows "asynchronously" that it had got the focus. If a child window wants the focus, it will take the focus otherwise, if it has children, it will inform them that they can choose to take the focus. Since this is all done asynchronously, it is very difficult to solve this problem. Adding a small delay would almost always work. You can even try a delay of 0.5s. There are of course race conditions. Unless it is very important to not have this race condition, I would advice you to use this solution.