PDA

View Full Version : How to keep window from stealing focus?



dbassett74
8 Aug 2009, 9:20 AM
I did a quick search on this, and from all that I could tell, there was not an exact issue like mine, so I'll post it here.

When you have a window, that contains a panel, that contains fields (like TextField) and the text field currently has the focus, and you move the window, the window steals focus and you have to click back into the text field. This is slightly annoying for the end user. is there anyway (like in a regular windows app) to keep the focus inside the panel, even though the user may click on the window caption area to move it or resize it? Also, if the window loses focus (like to another window) and the user subsequently clicks back on the window (like the caption area, not inside the panel), can the panel inside the window, and the last field to have the focus automatically get focused again?

cjauvin
2 Sep 2009, 1:44 PM
Hi,

I have the exact same problem, and I am looking for a solution too.

Christian

Animal
2 Sep 2009, 9:26 PM
You see this issue with the latest download?

teddyjas
3 Sep 2009, 1:16 AM
I also had the same problem...
I fixed this by overriding the Ext.Window's focus function to:

focus : function(){
var f = this.focusEl, db = this.defaultButton, t = typeof db;
if(t != 'undefined'){
if(t == 'number' && this.fbar){
f = this.fbar.items.get(db);
}else if(t == 'string'){
f = Ext.getCmp(db);
}else{
f = db;
}
f.focus.defer(10, f);
}
},

Animal
3 Sep 2009, 1:25 AM
The latest code for Window has a show method which does not steal focus. This issue should not arise.

If it does arise with the latest code, can someone post a testcase?

teddyjas
3 Sep 2009, 1:36 AM
do u mean this code animal?


show : function(animateTarget, cb, scope){
if(!this.rendered){
this.render(Ext.getBody());
}
if(this.hidden === false){
this.toFront();
return this;
}
if(this.fireEvent('beforeshow', this) === false){
return this;
}
if(cb){
this.on('show', cb, scope, {single:true});
}
this.hidden = false;
if(animateTarget !== undefined){
this.setAnimateTarget(animateTarget);
}
this.beforeShow();
if(this.animateTarget){
this.animShow();
}else{
this.afterShow();
}
return this;
},


if it is, then it still arise on my end..

as for the testcase, mine is just simple window with multiple textfields in it. Just do type in any of the field and move the window. the focus will be gone after drag ends...

Animal
3 Sep 2009, 1:44 AM
This is the corrected method which used to steal focus:



toFront : function(e){
if(this.manager.bringToFront(this)){
if(!e || !e.getTarget().focus){
this.focus();
}
}
return this;
},

teddyjas
3 Sep 2009, 1:56 AM
hemmm... I got the same method on my end... means the problem still there...

Animal
3 Sep 2009, 3:54 AM
Yes, there's a bug in that "fixed" method!

Try this:



Ext.override(Ext.Window, {
toFront : function(e){
if(this.manager.bringToFront(this)){
if(e && !e.getTarget().focus){
this.focus();
}
}
return this;
}
});

dbassett74
3 Sep 2009, 3:58 AM
When you say latest, do you mean the public release or from SVN? If it's the public release, yes, still a problem. If SVN, I have no idea as I don't yet have the privilege to access yet.

Animal
3 Sep 2009, 3:59 AM
I assume they'll put a fix for that in the next patch release!

Animal
3 Sep 2009, 4:00 AM
When you say latest, do you mean the public release or from SVN? If it's the public release, yes, still a problem. If SVN, I have no idea as I don't yet have the privilege to access yet.

Did you miss the above exchange? There's a bug in Window.

cjauvin
3 Sep 2009, 5:39 AM
Yes, there's a bug in that "fixed" method!

Try this:



Ext.override(Ext.Window, {
toFront : function(e){
if(this.manager.bringToFront(this)){
if(e && !e.getTarget().focus){
this.focus();
}
}
return this;
}
});


Thanks for the help! I tried this override, with Ext 2.2.1, but it does not seem to solve the original problem of this thread though, which I restate: when you have a FormPanel inside a Window, for the FormPanel to have the focus (that enables for instance the catching of key sequences for saving the form values), it has to be explicitly set upon a widget, whereas it would be nice if the focus could be kept on the FormPanel when you simply click anywhere in the containing window/panel.

dbassett74
3 Sep 2009, 5:41 AM
Thanks for the help! I tried this override, with Ext 2.2.1, but it does not seem to solve the original problem of this thread though, which I restate: when you have a FormPanel inside a Window, for the FormPanel to have the focus (that enables for instance the catching of key sequences for saving the form values), it has to be explicitly set upon a widget, whereas it would be nice if the focus could be kept on the FormPanel when you simply click anywhere in the containing window/panel.

Correct. Even if clicking on the window to move/resize it, the field that was last focused inside the FormPanel (or Panel) that is in the body of the window, should keep focus.

Animal
3 Sep 2009, 6:14 AM
How?

When you click on an HTML document, any focused element is blurred.

cjauvin
3 Sep 2009, 6:30 AM
I understand and I really fear that what we have in mind could not be possible at all. It is however the "normal" behavior of a desktop application (when you give back the focus to a MS-Word window for instance, you are immediatly able to do CTRL+S to save the current document), and in my case, would be simply a "nice to have", but I can live without it.

Animal
3 Sep 2009, 6:43 AM
Use the defaultButton config:



var tf = new Ext.form.TextField();
new Ext.Window({
renderTo: document.body,
title: 'Test',
items: tf,
defaultButton: tf,
height: 400,
width: 600
}).show();
tf.focus();

dbassett74
3 Sep 2009, 6:48 AM
Its more than just the issue of a button. It's the whole user experience. Users expect the focus to remain on the last element they were in, even after moving/resizing a window. For example, they are currently typing in a field, need to move the window to see something, and then start typing, only to find out they have to click back in the field. This is completely unintuitive and intrusive. How does DoJo accomplish this? Their sample page that has a window with elements in it, do not blur the focus even when clicking on the window and moving it around. I understand it is not the default nature of HTML, but neither is most of the stuff that ExtJs is accomplishing, which is the very reason for this library in the first place, to accomplish what would normally be very difficult in HTML. Having said that, I'm sure there is some way to accomplish this. For example, some sort of buffer that remembers the last focused field, so that after the user's mouse is released after moving a window, it goes back to that focused field?

cjauvin
3 Sep 2009, 6:53 AM
I already did try "defaultButton" (setting it to the id of an already existing button inside my FormPanel), but then the problem seems to be that the window is not firing any focus event (that would actually call win.focus() like your example) when I click for instance on its caption bar or on the FormPanel's "background" (i.e. anything not a widget). I also tried the approach of attaching a "click" listener to the window's element itself, to explicitly trigger the focus call, but it has the extreme opposite effect: whenever I click on anything (including a widget) the focus is redirected to the defaultButton.

Maybe the fixes that you submitted earlier would then enter into play?

Animal
3 Sep 2009, 6:55 AM
cjauvin if you are using Ext 2, then I don't know.

dbasset, maybe you want to implement some scheme for somehow saving the last focussed Component?

dbassett74
3 Sep 2009, 7:02 AM
cjauvin if you are using Ext 2, then I don't know.

dbasset, maybe you want to implement some scheme for somehow saving the last focussed Component?

I guess I'll have to, but it would've been nice (not only for me), if it was built in behavior in ExtJs. I'm thinking something like:

1) Component gets focus
2) A reference to that component gets stored in the Window that contains it
3) Window is moved/resized by user
4) On mouse up of the window, focus is set back to the previously referenced component.

Seems simple enough to me.

Animal
29 Sep 2009, 7:00 AM
rev 5345 reverted the fix due to unspecified issues.

There's still a focus stealing bug in Ext.Window

dbassett74
29 Sep 2009, 8:18 AM
rev 5345 reverted the fix due to unspecified issues.

There's still a focus stealing bug in Ext.Window

Thanks for the confirmation. Will the fix be included in the November release?

pkmiec
6 Jan 2010, 6:10 PM
Has the focus stealing bug in Ext.Window been fixed?

pkmiec
6 Jan 2010, 6:34 PM
And BTW, I do agree DoJo has the correct behavior implemented as someone previously pointed out.

http://dojocampus.org/explorer/#Dijit_Dialog_Basic