Remember window position?

Hi everybody.

First of all sorry for my bad english speak.

I came at this forum from a Google search because ...well, I have the same window-pos problem, the same problem as every Windows 10 user has (other thing is whether the user is too retarded to be unable to notice the problem by himself), then... after reading each comment of the 13 pages of this topic, I would like to launch some comments and questions... because this is not oficially fixed.

____________________________________________________________________________________________________

First of all, I'll remark this comment, which maybe is the most important and relevant comment made on this topic:

Mystere said:

Windows *does* remember its previous window position. That's the part most people don't seem to understand.

The issue is that File Explorer remembers your last position, then deliberately adjusts itself to be "cascaded" off of it. It's not that the position isn't remember, as it is. It's that Explorer decides to adjust itself based on that remember position.

Very good answer which is simple to understand, it's the reality, at least Windows 7/8/8.1/10 remembers all the Windows positions (keeping in mind the cache limit of course) the problem is that when you reopen the same window, it is shown in cascade view, this means that the position of the new window will be adjusted/modified, so we can say that the position is not preserved at all, because the cascade effect will give the Window a new position.

That thing never happened earlier in Windows, is a Windows 10 design issue (maybe intentionally, who knows, Microsoft team sometimes they are... well, you know, "hello start screen and goodbye start menu"), and it's really frustrating because well... the fuking cascade effect involves too much problems related about the user experience, and of course, its a very bad decission (or oversight) from Microsoft, very, very bad, because NO BODY WANTS NEITHER LIKES THIS BEHAVIOR!!.

____________________________________________________________________________________________________


Too much newbie users and not newbie users have interested in this issue but they didn't understood at all the problem that we talk about (please read the quote above), other guys have talked in this topic to say just weird things, to say that this problem is not real, or blah blah blah, sorry for this with all my respects but.... its incredible that some guys here claims to be a "Windows user" since they don't know anything about the O.S. that they are using.

Yes this problem is real.

I will give a brief example to demonstrate the steps to reproduce this issue that we are talking here in this topic:

( This is the "extreme" of the problem, the worst thing of the problem )

1. Make a shortcut to any folder and keep it on the desktop (just to have a short reference).

2. Open the shortcut/window, resize it to desired size (in normal view, not maximized), and move it to the bottom-right corner of the desktop, just exactlly at the corner.

3. Close the Window (no matter if you use the close button or the "close" option).

4. Reopen the shortcut/window, and see what happens.

At this point, you will notice the problem, the new window is shown in the TOP-LEFT corner of the screen instead of preserving the position in the BOTTOM-RIGHT corner. The reason of this new position is because the fuking cascade effect, as it didn'nt have avaliable client area space to perform a cascade on the bottom-right corner, then it returns to the start point, the top-left corner.

That is the biggest problem of this design issue of Windows 10, the retarded cascading effect is the problem at all, because as everytime that we reopen a window it will move a little down, this means we can't keep a personalized order of our windows.

Good job, Microsoft. (totally ironic)

I recorded a video that demonstrates this issue:



____________________________________________________________________________________________________

Now, go talk about the "solutions"....

With my respects, ignoring those users who told solutions that really don't work, or "solutions" that has nothing to do with the problem itself because those users didn't understood the problem, we can find two "real" solutions on this topic.

Before continue, I will give a big thanks to everyone, newbie or expert that has commented in this topic to try give a solution or an idea.

One solution is suppodsely based in click-tricks to maximize the window, then minimize, then resize, then move it, then touch the screen with your hands and give it a kiss with your lips... just nothing to do for an user that manages various Windows at once, because performing all those steps is really insane.

The second and realistic solution is using a 3rd party application, ShellFolderFix, ok, we can consider this as a solution because it resolves the problem, but we cannot consider it a solution since is not based on an O.S. registry hack or other built-in workaround, the main reason to avoid that app is the kind of app that it is at all, because all windows users should consider the value of a performance based PC, and having an application that is running always on background which its sucribed/hooked to intercept windows calls its a reason to slow performance.

Also, the app provokes an annoying effect because the cascade effect stills, the app cannot remove that, the app just intercept that and AFTER the cascade positioning is done, the app gives a new position to the window, this means in simply words x2 of work everytime a window is open plus the main work of the app, which who knows how much refactorized or spaghettized it is since any source code is provided?.

An efficient... I mean, the only efficient solution would be a simple patch, a patch in the explorer.exe file (or wathever file is the involved one in this) to ignore/bypass the win32 call that the file perform to wathever win32 function or internal method logic that the involved file uses to provoke that annoying cascade effect, simple as that.

Of course I'm not a reverse engineering guru, my assembler knowledges are poor so I cannot do nothing to help about that, but in terms of performance that will be the best solution because we are not adding a 3rd party app that consumes resources and performs I/O operations in background, we are not registering a 3rd party shell extension that integrates in the shell/explorer to slow our performance (as the other will do), we are not doing nothing more than changing some instructions of "X" code to avoid this horrible cascade-window feature and we will not loose performance doing that, more than that, we will gain the opposite doing that.

...But unfortunately no body did this patch yet ...maybe because it could be a little insane to do it or maybe the reverse engineering guys does not have any interest on this design issue of Windows.

____________________________________________________________________________________________________

Will Microsoft do things right about this problem?. I don't know, but I don't expect it.

Someone will report or has reported this design issue to Microsoft?. I don't know, but I expect any fix/improvement from Microsoft.

What I know?. I just know that Microsoft decisions sucks, but I'm addicted to Windows so... I can only complain about their bad decisions.

Have a nice day!

Elektro.

Jo Mei said:

For me, the above-mentioned ShellFolderFix (Download here) works flawlessly. With this fine little Tool, you may also keep up to 16 recent Folders, save & restore Desktop Icon Positions and many more.

It's a shame that Windows still needs a 3rd Party Tool to remember Window Positions.

ShellFolderFix isn't a proper solution, because more than a fix its a troublemaker in specific circunstances, its bugged.

--------------------------------------------------------------------------------------------

An example that demonstrates the imperfectioned behavior of this aplication, ShellFolderFix:

1. Create a random folder in a random directory, let's say: C:\Folder1\Folder2\Folder3

2. Create a Shortcut for 'Folder1', 'Folder2' and 'Folder3' on the desktop.

3. Open 'Folder3' shortcut, and "save" its position at topright corner by moving the window to that corner and closing the window.

4. Do the same with 'Folder2', but this time "save" its position at the middle of screen.

5. Do the same with 'Folder1', but this time "save" its position at top-left of the screen.

6. Now, reopen the 'Folder1' shortcut, an explorer window should open in 'C:\Folder1' location;
now manually navigate to 'Folder2' subfolder (C:\Folder1\Folder2)

At this point you will see that THE CURRENT EXPLORER WINDOW will move to middle of the screen.

7. Now, being at 'C:\Folder1\Folder2' location in the same Explorer window, manually navigate to 'Folder3' subfolder (C:\Folder1\Folder2)\Folder3).

At this point you will see that THE CURRENT EXPLORER WINDOW will move to top-right corner of the screen.

--------------------------------------------------------------------------------------------

What this means?.

This means that ShellFolderFix doesns't care about if you are manually navigating trough folders or not in an opened Exporer instance, so many times your explorer window will move to "random" positions (previously saved positions of other closed windows) like a retarded, so the user experience of Explorer navigation will become a nightmare, because ShellFolderFix doesn't prevent the repositioning of a window in that common and basic circunstances, which are using Explorer to navigate trough folders by doing clicks on the directory tree.

To understand, ShellFolderFix is an application that saves the position of the explorer instances that you close, to know which coordinates are associated to a window the app also saves the current directory path of the explorer instances that you close, so basically when ShellFolderFix detects an explorer instance where in its navigation bar contains a previously saved directory path, it repositionates the window.

In resume, ShellFolderFix logic is weird in this meaning, Its algoritm has any resolutive logic to prevent this behavior issue, its just a not implemented scenario.

Imagine that your ShellFolderFix cache have saved a different position for 200 different directories, now, you open explorer.exe and you will manually navigate to those folders (doing clicks in the directory tree), then your current Explorer window will move around the screen like a retarded because ShellFolderFix only will care about the directory path that you are in, so it will repositionate your current window everytime.

That behavior of this ShellFolderFix program its really CRAZY.

I still wonder for a real solution for this, an explorer.exe patch related to reverse engineering or a windows update that adds a ****in' option to disable this annonying design behavior.

Thanks for read!.
Elektro.