[Gambas-user] setfocus eats way too much time

[Doriano Blengino]

Jean-Yves F. Barbier ha scritto:
> Doriano Blengino a écrit :
>   
>> Jean-Yves F. Barbier ha scritto:
>>     
>>> Jean-Yves F. Barbier a écrit :
>>>   
>>>       
>>>> Hi list,
>>>>
>>>> I've got a popup that is a small frame containing a TextArea & 2 buttons.
>>>>
>>>> In order to do things right, I've got a default text into TextArea; but to
>>>> make sure typing will fill the TextArea, I must do 2 things: 
>>>> TextArea1.SelectAll()
>>>> TextArea1.SetFocus()
>>>>
>>>> however, SetFocus() introduce a waiting time up to 1.5 seconds before frame shows!
>>>>     
>>>>         
>>> This only happen the first time: next invocations don't have this delay
>>>
>>>   
>>>       
>> May be because the first time the whole window is invisible, and the 
>> following times is not?
>>     
>
> I don't think so, here's the process: 
> Lanch open FMain that wait for input,
> btn Ok opens a 2nd window that 1st seek a DB to recover languages, procedure names,
>   schemas & user names,
> I left-click on an item and choose an action in popup,
> The small frame that input data for choosen action takes ~1.3sec to show @ 1st 
>   (further uses are instantenous!)
>
> A timer is runnig on the 2nd Form to drive the selection bar of popup (25ms).
>
> Code is quite simple
> without:
>   blah blah process
>   frm_Group.Visible = TRUE   ' Frame that contains next textbox
>   txb_GroupName.SelectAll()  ' Select all default text in input zone
>   
> with:
>   blah blah process
>   frm_Group.Visible = TRUE
>   txb_GroupName.SelectAll()
>   txb_GroupName.SetFocus()   ' Aaarghhh
>
> For ergonomy I must do that, otherwise the focus isn't on text at opening
>
>   
>> You could also set up a timer (a few milliseconds) and posticipate the 
>> setfocus.
>>     
>
> I don't think so because the procedure isn't that long and that complex, so if
> I setup a timer, it must be in another place than this procedure; this is the
> beginning of a future whole mess.
>
> JY
>
>   
Fabien was asking what toolkit you are using: GTK or QT?
Try the other one, who knows... it's a quick way to know if the problem 
is in the toolkit.
In QT I experienced similar delays whith message boxes - I think those 
delays are related to sound (yeah, it's very important to play a sound 
together with a popup... and I don't know how to disable sound).

I understand one doesn't want to mess with the code, especially a timer 
when there is no reason. But sometimes it solves. For example, once I 
wanted to close a tabstrip from a button sitting on the tabstrip itself. 
It was impossible without using a timer, because the tabstrip refused to 
destroy while executing an event from a gadget owned by the tabstrip. 
Too long to explain - I had to "unrelate" the button and the tabstrip - 
I did it with a timer. Now I am playing with GTK, and I see that focus 
and visibility of gadgets (and other things) behave strangely. Trying to 
use a timer is a 4-lines piece of code: instead of doing a thing, you 
start a timer. In the event of the timer you do what you want to do, and 
disable the timer; you don't even need to put the timer in the form; you 
create it on the fly in the program, and destroy or stop it after it has 
done the job. The reason for all this is that when you execute 
somthing.show(), a lot of things must happen; these things sometimes are 
deferred, but you, just after show(), want to focus a gadget that 
perhaps is not even visible. By exiting the event handler, you give the 
toolkit the CPU time to show the window and do whatever it needs.

I am not sure, but 4 or 5 lines of code can worth the time.

Regards,

-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."