Bringing a window back on-screen

We got a call from one of our clients about an issue. Somehow they managed to get a window from an application off-screen so they couldn't use it. So I walked over to their office since it's only a block away. The window in question was a toolbox window for an application, like those external toolboxes you get in Paint.NET and many other programs. And sure enough, most of the window was "above" the desktop. You could only see the very bottom of it, and there was no way to drag the mouse off-screen to grab the title bar and bring it back.

Closing the program and relaunching didn't fix it. I tried restarting the computer. When I launched the application the toolbox was still off-screen. I tried using Windows' "Cascade Windows" feature. All the windows cascaded except the toolbox. I right-clicked on the program's entry in the task-bar and the "Move" menu item was grayed out. I tried Alt-Space, M and the "Move" item there was grayed out as well.

I was almost out of ideas. I had one trick left to try, but it was pretty solidly in WTF-land. This computer looked like it was probably pretty good back in 2002. It was running Windows XP and had the blurriest CRT monitor I've ever seen. Did it support dual monitors?

I crawled under the desk and had the good fortune to see an unused DVI port on the graphics card. I asked the client if they had any spare monitors, and sure enough they had half a dozen old 19" LCD screens in the closet. I grabbed one and thought I was going to break my back. You know it's an old LCD when it weighs just as much as a CRT.

I got the screen hooked up and restarted the computer. Windows recognized the dual screen setup, but the LCD didn't actually work. It just flashed the backlight about once every other second. Oh well, I guess it didn't actually have to work. I just needed some room to re-arrange screens, a lot like those puzzles with the sliding squares and you're missing one square so you have space to slide them around. I'm sure they have a name.

I launched the application again, then opened the screen resolution settings. I dragged the CRT to be the top of the desktop with the broken LCD below it, and set the LCD as the primary monitor. When I hit "Apply" the screens flashed and there was the top half of the toolbox coming up from the bottom of the CRT's display. The LCD was still dead.

I restored everything to normal and the toolbox stayed put. All I could do as I walked back to the office was shake my head.

TRWTF is that they somehow dragged this toolbox off-screen. None of us can understand how that happened.

Was it 3ds Max, by chance? They're on version 15 or so and it still does this. If it was, navigate to %APPDATA%/Local/Autodesk/3dsmax/$version-32-bit/$lang/ and delete the 3dsmax.ini file. 64 bit if it's 64 bit, obviously.

Was it 3ds Max, by chance? They're on version 15 or so and it still does this. If it was, navigate to %APPDATA%/Local/Autodesk/3dsmax/$version-32-bit/$lang/ and delete the 3dsmax.ini file. 64 bit if it's 64 bit, obviously.

I miss INI files.

NetBeans has similar issues when switching between 3 monitors at work and 1 at home. Not sure whether I blame NetBeans or the secure remote desktop implementation that won't let me scroll across the 3 physical screens.

For KDE at least there's one more way (that should work with WINE, too): you can define that the window managerkeeps a window (specified via class, title, host, etc.) always at the same position/size/workspace/foreground/background etc. - and these things can be given numerically, so if something is negative just fix the value.

Nice feature to get eg. browser windows opened on one workspace, consoles on another, and so on ...

Did you try setting their resolution to 1 step higher than it was currently set at? I have no idea how the window was positioned-- absolute "y", or "bottom of the screen + 10", but it might have worked.

Did you try setting their resolution to 1 step higher than it was currently set at? I have no idea how the window was positioned-- absolute "y", or "bottom of the screen + 10", but it might have worked.

Yes. It was positioned with a negative Y value, so any resolution had the problem.

Closing the program and relaunching didn't fix it.
I tried restarting the computer. When I launched the application the
toolbox was still off-screen. I tried using Windows' "Cascade Windows"
feature. All the windows cascaded except the toolbox. I right-clicked on
the program's entry in the task-bar and the "Move" menu item was grayed
out. I tried Alt-Space, M and the "Move" item there was grayed out as
well.

For the super-dense, Alt+Space opens the above menu, and M is the shortcut for "Move" as seen by the underline on "Move." The fact that "Move" is drawn with a muted gray color means it is not available.

For the pedantic dickweeds, this image was not taken from the offending application, but from a different one. So before you come up with some crazy explanation involving the grayed-out Maximize etc. meaning something, this isn't from the offending application.

This is the system menu for the main window, which is maximized at this moment. A tool window (owned by the main window, so it doesn't appear in AltTab and Task Manager app list) has its own system menu, of course if the app is not screwed up. You can't invoke the system menu for the tool window by clicking on the tasklbar. You have to activate the tool window by clicking on it.

For illustration, open Notepad, type some text and do Ctrl+F. This opens a Find tool window. If you activate the main window, and to Alt+Space, it will open the system menu for the main window. If you click on the tool window, Alt+Space will open the system menu for it.

This is the system menu for the main window, which is maximized at this moment. A tool window (owned by the main window, so it doesn't appear in AltTab and Task Manager app list) has its own system menu, of course if the app is not screwed up. You can't invoke the system menu for the tool window by clicking on the toolbar. You have to activate the tool window by clicking on it.

For illustration, open Notepad, type some text and do Ctrl+F. This opens a Find tool window. If you activate the main window, and to Alt+Space, it will open the system menu for the main window. If yu click on the tool window, Alt+Space will open the system menu for it.

Somehow they managed to get a window from an application off-screen so they couldn't use it. So I walked over to their office since it's only a block away. The window in question was a toolbox window for an application, like those external toolboxes you get in Paint.NET and many other programs. And sure enough, most of the window was "above" the desktop. You could only see the very bottom of it, and there was no way to drag the mouse off-screen to grab the title bar and bring it back.

Is this some sort of bug/feature of Windows XP or the application? On Windows 7 I can't reproduce this with any program. I can move windows and toolbars to the left, right or down, but I can't move them more than about 85% off screen -- there's always enough left showing that you can grab it and move it back. Also, I can't move them offscreen at all going up ("above") the desktop.

Somehow they managed to get a window from an application off-screen so they couldn't use it. So I walked over to their office since it's only a block away. The window in question was a toolbox window for an application, like those external toolboxes you get in Paint.NET and many other programs. And sure enough, most of the window was "above" the desktop. You could only see the very bottom of it, and there was no way to drag the mouse off-screen to grab the title bar and bring it back.

Is this some sort of bug/feature of Windows XP or the application? On Windows 7 I can't reproduce this with any program. I can move windows and toolbars to the left, right or down, but I can't move them more than about 85% off screen -- there's always enough left showing that you can grab it and move it back. Also, I can't move them offscreen at all going up ("above") the desktop.

While a human can't do it via the normal windows UI, programs can set their window positions anywhere they like. Many dubious applications like 3D Studio Max and Maya rely heavily on floating windows and editors, so they "remember" their locations when you open and close them. If you were working on a 2 monitor workstation and then unplug one monitor, several of the windows will remain outside your view space.

While Windows is generally good at about aggregating windows to the visible desktop, I wouldn't be surprised if someone came up with a "move everything to monitor 1" tool to deal with these misbehaving applications.

If you were working on a 2 monitor workstation and then unplug one monitor, several of the windows will remain outside your view space.

That's really annoying. With my home Windows 7 PC I have a 40" TV connected via HDMI to the "left" of the primary LCD: mostly used for XBMC. Sometimes windows get over onto that screen. Usually simply unplugging it will usually bring the offending windows onto the primary (toddlers and their random mouse movements can send windows over there). But usually the floating windows are still floating in the ether.

I have seen the positions get corrupted badly. Once I had a program (can't remember which one, it was probably using one of Blakeyrat's "favourite" licenses) that had its find window position saved at (-2147483648, -2147483648) so of course it never came up until I edited the ini file.

I didn't even know one could disable "move" on a window's system menu. Someone must have gone out of their way to do it, which means someone purposely wanted this window not to be movable by this command.

I didn't even know one could disable "move" on a window's system menu. Someone must have gone out of their way to do it, which means someone purposely wanted this window not to be movable by this command.

It's not a regular window, it's a tool window. It has a slightly different appearance (thinner titlebar, etc.) and slightly different rules. It's meant to be associated with a main window that will have a system menu and the associated bits.

As a guess to how this happened, the main window may have been dragged down at some point (say the user wanted to get to something on the desktop and just quickly dragged it down till it was mostly off-screen to the bottom.) Small tool window stayed where it was. When the program (or Windows itself) closed, it saved the 'layout' by recording the size and relative position of tool windows (but not its own absolute position). Next time the program starts it positions itself onscreen, maybe even centered. The tool window had been "high above" the main window last time, so that's where it goes.

Yes, there are ways to program around that, but it's an easy case to overlook. Windows typically aren't closed from that position... but of course they can be.

Nope, neither Macs support this. And that's one of the main reasons I can't use Windows nor Macs.

Also, in Windows, try the scrollwheel on an unfocused window or container: it doesn't work until you click on it. Now try it in any Linux. GNOME, MacOS and KDE simply do the scrolling of the windows/container without changing focus. XFCE gives focus and scrolls on windows, but only scrolls on containers.

Also, in Windows, try the scrollwheel on an unfocused window or container: it doesn't work until you click on it.

This detail is non-trivial and I agree that scrolling should scroll what you're pointing at, not what happens to have focus or is willing to receive scrolling regardless of where your cursor is. Many applications, including Windows Explorer, don't do this and it's immensely annoying.

Also, in Windows, try the scrollwheel on an unfocused window or container: it doesn't work until you click on it.

This detail is non-trivial and I agree that scrolling should scroll what you're pointing at, not what happens to have focus or is willing to receive scrolling regardless of where your cursor is. Many applications, including Windows Explorer, don't do this and it's immensely annoying.

Linux has a lot of time-saving features like this. Like the ability to just highlight something with a mouse and middle click elsewhere to paste it, which works alongside the standard clipboard quite nicely. These things don't seem like much on their own, but together they really help.

Linux has a lot of time-saving features like this. Like the ability to just highlight something with a mouse and middle click elsewhere to paste it, which works alongside the standard clipboard quite nicely. These things don't seem like much on their own, but together they really help.

I know how lots of details have lots of impact. That's because you use it a lot.

But like I said, you don't need a timesaver for dragging windows, because nobody is constantly dragging around windows.

I like the timesaver in Win8 where double-clicking an edge pseudo-maximises along that one axis. That's a good detail.

LinuxKDE/Gnome/whatever desktop manager I use has a lot of time-saving features like this. Like the ability to just highlight something with a mouse and middle click elsewhere to paste it, which works alongside the standard clipboard quite nicely. These things don't seem like much on their own, but together they really help.

I didn't even know one could disable "move" on a window's system menu. Someone must have gone out of their way to do it, which means someone purposely wanted this window not to be movable by this command.

Also, in Windows, try the scrollwheel on an unfocused window or container: it doesn't work until you click on it.

This detail is non-trivial and I agree that scrolling should scroll what you're pointing at, not what happens to have focus or is willing to receive scrolling regardless of where your cursor is. Many applications, including Windows Explorer, don't do this and it's immensely annoying.

This is unfortunate legacy of the first wheel scroll support library in NT4. Raymond Chen wrote about that. I think it's time to break with that legacy, and many apps already did. IE9, for example, forwards the scroll messages to the window under mouse cursor.

I worked in that group at MS when the scroll wheel was being added. If I recall correctly (it was a long time ago...), the system sends the scroll wheel mouse message to the window under the pointer; if it was not acknowldeged by that application, it then sends the keyboard message to the application with keyboard focus.

The behavior got stuck that way because changing it now might break existing apps, since so many of them only listen for the old keyboard-style messages still.

I tried using Windows' "Cascade Windows" feature. All the windows cascaded except the toolbox. I right-clicked on the program's entry in the task-bar and the "Move" menu item was grayed out. I tried Alt-Space, M and the "Move" item there was grayed out as well.

TRWTF is programmers who think they are being smart when they disable the "move" function in their applications. Program windows that don't respond to Cascade or Windows+Arrow are one of my pet hates. Hey, programmers, you are not being arty or clever - you are just being a jerk! For example - Google Chrome.

I like the timesaver in Win8 where double-clicking an edge pseudo-maximises along that one axis. That's a good detail.

KDE implements that (not sure about Gnome or any of the others) through the maximise button on the windows title bar. Left-click maximises as normal, right-click does it vertically, and middle-click does it horizontally. Use that all the time in console windows and the like. Another option is to allow a window to always sit on the top or bottom, something I think even Win8 needs another program to accomplish. Great for shoving a small window of a film playing over the top of Netbeans when I'm working, because the code rarely ever reaches the far right so it doesn't matter if something sits there, but I do need the menu bar to be full screen width.

Somehow they managed to get a window from an application off-screen so they couldn't use it. So I walked over to their office since it's only a block away. The window in question was a toolbox window for an application, like those external toolboxes you get in Paint.NET and many other programs. And sure enough, most of the window was "above" the desktop. You could only see the very bottom of it, and there was no way to drag the mouse off-screen to grab the title bar and bring it back.

Is this some sort of bug/feature of Windows XP or the application? On Windows 7 I can't reproduce this with any program. I can move windows and toolbars to the left, right or down, but I can't move them more than about 85% off screen -- there's always enough left showing that you can grab it and move it back. Also, I can't move them offscreen at all going up ("above") the desktop.

The only way I could think that it could be moved off is if the screen resolution was changed at some point after moving it. Maybe the program remembers the locations of its toolbars between instances and doesn't check that the current screen resolution is smaller than that?

Sure you don't have the option to auto-focus window the cursor is above turned on?

In my case... no.

That is: no, I'm not sure. I don't know what that option is, so can confirm I haven't turned it on but similarly cant confirm if it IS on.

All I can state is:

I click on my Putty window, see the title bar darken and FF title bar turn grey,

can confirm typing affects putty... but can still scroll FF whilst putty is receiving keyed input (yes, can type with one hand and scroll another app's window with the other).

I'm not going to do a spectateScreenvideoArtefact shoot.

Of course, I have some proprietry scrolling thing attached to my touchpad (does zoom with 2-finger pinch/spread) so I'm not convinced it's entirely native Win behaviour - it could be some Synaptics Touchpad wizardry at work.

Of course, I have some proprietry scrolling thing attached to my touchpad (does zoom with 2-finger pinch/spread) so I'm not convinced it's entirely native Win behaviour - it could be some Synaptics Touchpad wizardry at work.

Does sound like it is that. It's such a shame, because this is something I miss badly in Windows. Even within the same app this doesn't work. I have Outlook 2010 set up with a split view, email list on the left, and email previewarea on the right. Thing is, if it's a long email, and I want to scroll down it, I need toput the focus into that preview pane, but then switch the focus back to the email list to scroll through that. I guess this is probably a planned feature in Outlook 2020, based on how slowly it takes Microsoft to implement some of these things.

This detail is non-trivial and I agree that scrolling should scroll what you're pointing at, not what happens to have focus or is willing to receive scrolling regardless of where your cursor is. Many applications, including Windows Explorer, don't do this and it's immensely annoying.

This was the one thing I liked about OS X because it would do it consistently. I then asked around and found WizMouse which will bring this behaviour to Windows. Also one I use, VoluMouse, for controlling the volume with the mouse.

On Windows 7 I can't reproduce this with any program. I can move windows and toolbars to the left, right or down, but I can't move them more than about 85% off screen -- there's always enough left showing that you can grab it and move it back. Also, I can't move them offscreen at all going up ("above") the desktop.

This was introduced in Windows 7 as part of Aero Snap. Unfortunately, it's implemented slightly wrongly IMHO - they should've made it so that you align the titlebar with the top of screen, not the window border (as that'd make it easier to click the minimize/maximize/close buttons).@dhromed said:

This detail is non-trivial and I agree that scrolling should scroll what you're pointing at, not what happens to have focus or is willing to receive scrolling regardless of where your cursor is. Many applications, including Windows Explorer, don't do this and it's immensely annoying.

There's a bunch of programs that'll fix this for you, such as KatMouse and XMBC.