Stealing Focus

No. The only time I get peeved when something steals the focus is when the computer is starting and I''m trying to select something from the start menu.

Yes, I know what you mean. Sometimes like you said, I want to write something while reading something else, and then of course, the window you are typing in gains focus. It usually takes some clever manuevering of windows to get something suitable. Could you possibly write a system hook that would intercept and kill any SetFocus()? calls? Just a random thought of the day

EDIT: I actually did a little research into the idea... wouldn't a window receive the WM_SETFOCUS message if it was going to be granted focus? If so, like I said before, I would think a system-wide hook should be able to intercept the message, and subsequently discard it. I'd write it myself, but I have no idea how to write a hook

[edited by - Peon on August 29, 2003 4:00:17 AM]

I agree, there are times when I will be writing something when another program will get focus and half my message will end up in the wrong program. Or worse, I just executed a bunch of random hotkeys and have no idea what I did. This is especialling true with AIM. Other times I will want to surf the web while watching something in Window media player. Fortunately WMP has a setting so it always stays on top, but I do wish that there were a way so that the current program you are working with keeps focus no matter what.

"I may not agree with what you say but I will defend to the death your right to say it."
--Voltaire

quote:

---

Original post by Oluseyi
Which idiot "software engineer" thought that having applications steal focus was a good idea? It's one of my ultimate Windows pet peeeves, since I tend to multitask. The other (flip side of the same pesky coin) is not having control over focus independent of window order. While it may be sufficient for the average desktop user to have input focus go to the top window, it's not enough for me. Ever since I experience the rapture that is being able to place a source window on top and type into a destination window below it (thank you, Linux/Unix WMs!), this missing feature has irked me no end in Windows and OS X.

The Unix dudes got it right. Even if you want to simplify things for desktop users, leave it in as a poweruser switch! Unfortunately I can't install a desktop mod/Explorer replacement shell.

Am I alone in this, or are there others who find this "feature" similarly irritating?

---

Clicky

TweakUI. It's under the general tab: "Prevent Applications from Stealing Focus"

AFAIK it only works on XP though.

[edited by - lnxwndusr on August 29, 2003 4:07:42 AM]

I can think of one situation where stealing focus is potentially a good idea: to ensure the user doesn''t type a password where it shouldn''t go. Of course, this is only required at all because an application might steal the focus from the password entry whatever in the first place...

Sloppy focus without raising is great, but I haven''t grown so addicted to it where I cannot manage to live without it relatively easily still (how long I''ll last, I don''t know ).

Not that you asked, but two things I find extremely annoying in UI design that''s more common in Windows that my own preferred desktop environment:

• Modal dialog boxes that have absolutely no reason to be modal. (I think this is commonly found in Windows because, at least in my vague memory of Win32 API work, it was a lot easier to do a modal dialog box than a non-modal dialog box.)


• Dialog boxes and windows that do not allow resizing. (Again, I think this is commonly found in Windows because of the added difficulty of using the Win32 API to make UIs that resize properly. GUI libraries that handle layout are indispensable.)

One major example for me is loading web pages in two or more tabs in Firebird and then being interrupted by an alert from another tab telling me something I don''t care to know, like "the document contained no data." SO?

quote:

---

Original post by Peon
Could you possibly write a system hook that would intercept and kill any SetFocus()? calls? Just a random thought of the day

---

It''s worth a try. You''d want to look for messages that accomplish the equivalent of SetWindowPos and SetFocus. It''d take some Spy++''ing, which I''m just not ready to do right now (not least of all because I lack the appropriate tools at the moment).

quote:

---

EDIT: I actually did a little research into the idea... wouldn''t a window receive the WM_SETFOCUS message if it was going to be granted focus? If so, like I said before, I would think a system-wide hook should be able to intercept the message, and subsequently discard it. I''d write it myself, but I have no idea how to write a hook

---

You don''t want to summarily discard the message, otherwise you''d never be able to switch apps. The smartest way to do it is to test whether the mouse is within the titlebar of the focus target window. If so one can assume the user clicked and alter the window positioning (bring to top) as well as set focus, and if not one can complete the focus switch but maintain the window order. This creates a system where you can reoder windows and switch input focus by clicking on their titlebar and switch input focus alone by clicking within their context areas.

Of course, this is assuming that the underlying Windows implementation has separate code paths for the two actions. Since they are fundamentally tied by design, developers may have locked them together. A few apps which to present "Keep on top" options (like MSN Messenger) give reason for hope, though.

I agree 100%.

How does typing into a window below another window work? Do you tell the top window to always be on top, or is it something with the destination window? I''ve wished there was a universal "always on top" option in windows for years.

As for that hook idea, it seems like that would eradicate legitimate app switching. Setting focus isn''t the problem, as that happens everytime you visit a window. Stealing focus is what sucks. A generic hook would probably fail miserably for that reason. Plus, if it were possible, I imagine pr0n sites would have figured it out by now. They are pretty tricky with their ads, and I''m sure they''d simply turn off task switching all together if they could.

CM

quote:

---

Original post by lnxwndusr
Clicky

TweakUI. It''s under the general tab: "Prevent Applications from Stealing Focus"

AFAIK it only works on XP though.

---

I know about TweakUI. I''m just wondering why the design decision was made that way in the first place. And why TweakUI doesn''t come with XP.

Thanks for the link anyway.

quote:

---

Original post by Null and Void
I can think of one situation where stealing focus is potentially a good idea: to ensure the user doesn''t type a password where it shouldn''t go.

---

Actually, stealing focus has caused me to type password in cleartext on a number of occasions (entering passwords into webpages, with the browser being preempted by Word or Notepad...)

quote:

---

Modal dialog boxes that have absolutely no reason to be modal. (I think this is commonly found in Windows because, at least in my vague memory of Win32 API work, it was a lot easier to do a modal dialog box than a non-modal dialog box.)

---

I agree with both your peeve and your reasoning. Creating a non-modal dialog box in Win32 is significantly more work, so modal dialogs are an easy cop out even when they hurt the UI design and usability. It''s irritating having your workflow halted over nothings just because the tool author or platform were not smart/robust enough to give you a more intelligent alternative.

quote:

---

Dialog boxes and windows that do not allow resizing.

---

In especially bad cases the fixed size window mandates either excessive scrolling on constant screen repositioning to be any use (just because one chooses to work at a lower resolution, for whatever reason).

absolutly the worst ever possible focus-related thing:

Internet explorer when downloading. Once a download finishes, it opens up a single "copying file" dialog (that gets focus), and has a single button: cancel. It is responsible for copying the file to it''s final destination.

Yep.

I''ve clicked that cancel button so many times.

Basicly, if you are typing anything that contains spaces, enters or the letter c, and that dialog pops up - bye bye download.

Of course, for larger files (like ones that take hours to download), the longer the box is there, and the eaiser it is to click.

---

Free Game: Yet Another Falling Block Game

quote:

---

Original post by Oluseyi
You don''t want to summarily discard the message, otherwise you''d never be able to switch apps. The smartest way to do it is to test whether the mouse is within the titlebar of the focus target window. If so one can assume the user clicked and alter the window positioning (bring to top) as well as set focus, and if not one can complete the focus switch but maintain the window order. This creates a system where you can reoder windows and switch input focus by clicking on their titlebar and switch input focus alone by clicking within their context areas.

---

You''d want to add in ALT-TAB support as well somehow. I imagine it should bring the new window to the top, so that you don''t have to use the mouse when you actually need to switch windows. But maybe not...at the very least, an option that can be toggled.

CM

quote:

---

Original post by Conner McCloud
How does typing into a window below another window work? Do you tell the top window to always be on top, or is it something with the destination window?

---

The window manager on intelligently designed platforms inherently separates focus from raising, thus giving the user the option to combine them in any way that suits him: sloppy focus means that focus follows the mouse about a second after it points at any window, including the desktop (like hyperlinks on the Windows desktop when you choose the single-click execution option). Focus can be combined with raising so that setting focus brings that window to the foreground, with the exception of the desktop which merely becomes active. By default on Unix traditional systems and some others, though, focus and raising are separate, with raising accomplished by clicking on the titlebar); raising always sets focus.