Recent Posts

3376

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 29, 2017, 09:40 AM »

3rd day in a row, working perfectly.

3377

N.A.N.Y. 2016 / Re: NANY 2016 Release: Automatic Screenshotter - v1.06 - May 7, 2017

« Last post by mouser on July 28, 2017, 11:18 PM »

Sorry I've been wrapped up in other projects.. But I will try to get it done this weekend.

3378

Clipboard Help+Spell / Re: CHS - Paste File Location

« Last post by mouser on July 28, 2017, 11:12 AM »

See this discussion: https://www.donation....msg410283#msg410283

3379

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 28, 2017, 06:53 AM »

I've also added command line options
-load <filename> -save <filename> -sleep -help -exit

Nice!!

Maybe the menu should say "Put monitors to sleep" then, not just "sleep".

3380

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 28, 2017, 02:39 AM »

I am absolutely giddy to have a fix for my window scrambling problem.. 

3381

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 28, 2017, 12:20 AM »

Nice -- looks like this could become a mutlti-faceted tool..

More importantly though: Second night of real-world deployment of WinPosSaver(M)  worked flawlessly. 

ps.
In your menu I see the entry labeled "Sleep"... I assume that puts the COMPUTER to sleep.  It would be nice to have another menu item for just putting the MONITORS to sleep, which is the function that people with my affliction will need for testing.

3382

Screenshot Captor / Re: Settings are reset to default

« Last post by mouser on July 27, 2017, 04:42 PM »

See if the D:\MY_DATA\ works and let's go from there.
The only thing I can think of is if your other directory is somehow not "ready" at startup time...

3383

Finished Programs / Re: FINISHED: Hourly chime software (like Cuckoo for Mac)

« Last post by mouser on July 27, 2017, 11:11 AM »

 

3384

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 27, 2017, 10:54 AM »

First real life report: program worked perfectly for me this morning to restore window positions.  Felt like magic. 


ps. For those who might be wondering why I've made such a big deal about this problem of moving windows on wake, let me explain:  I have a tiny netbook computer on the bedside table next to my bed.  It stays connected to my desktop in my office with a remote view of the desktop..  As soon as I wake up in the morning, I lean over from bed and tap the keyboard to turn on the netbook monitor and then look to see what new mail and forum activity there is.  The remote view of my desktop only focuses on a small area at a time because the netbook resolution is so small, and it's difficult to move the view around the 4 high-res screens of my desktop -- especially since one of my desktop monitors is in portrait orientation.  So when the window positions scramble, it means I spend the first several seconds of my waking mornings barely conscious and sliding my finger on the mousepad in what seems like an endless futile search for where my mail and browser windows have gone.. And sometimes they are moved under other windows, etc..  Not exactly how I want to spend the first moments of the morning.  So having this problem fixed is so wonderful.

3385

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 27, 2017, 03:42 AM »

Yep, easy to do.

Since I'm not an ahk person, I will wait for skrommel or someone else to add code to the ahk that can detect a commandline arguement of -load or -save and if found just do that and exit.
That way we can use the same ahk/exe tool both for commandline saving and loading, and also for it's current resident use.

3386

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 27, 2017, 03:29 AM »

The way i have resolved it is, at 6:58pm, a scheduled task run with nircmd to put the computer into sleep (without this power is cut and WinPosSaver wont know the state of the windows)

Just a note that WinPosSaver doesn't need for the COMPUTER to go to sleep/hibernate (though that may work too), it just needs the MONITOR to go to sleep, which is a separate thing.

Note also that skrommel's code (and my tweaks to it), could very easily be modified to work as commandline function for saving windows and restoring them on command, regardless of monitor status.  So that would be an easy functionality to add if it would be useful.

3387

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 27, 2017, 02:46 AM »

Skrommel -- If you are looking for features to add, another feature that would be nice to add to this tool is a menu item to put the monitors to sleep -- nircmd has a function for this but i think it's a naturally feature to add to this tool's tray menu if it's easy to add, and it would definitely help others test the tool.

3388

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 27, 2017, 02:45 AM »

Welcome, Andy. 

Skrommel is the magical creature who deserves the real thanks here.  I am happy to be able to take his work and improve it.
I myself can't wait until I see how this performs tomorrow morning.

And it's nice to see that there is someone else who will benefit from this tool.

By the way -- how did you discover this thread so quickly?


I can already say that it works well enough in my testing that even if the current version isn't perfect, it soon will be -- which is a nice feeling.

Once the program is all cleaned and polished up, I hope we can spread the word to others who have been suffering with this problem.

3389

General Software Discussion / Re: AVG sntivirus possible false positive report this morning on win 7 system files

« Last post by mouser on July 27, 2017, 12:19 AM »

Just a follow up, official response from AVG (see that thread), has confirmed that it was a false positive mistake.  No actual threat.

3390

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 26, 2017, 11:57 PM »

I'm uploading a new version which has some options at top of file regarding delays and methods.
I think my new code to quickly cycle until the screen resolution is back to where it was, may not be all that useful because I suspect that the virtual screen size does *not* change when the weird window moving event happens.

So I wrote some new code that basically run the window position restore(load) function TWICE:
First as soon as it gets the signal that a monitor has turned on.
Second, after some delay after a monitor turns on.

The idea being that most of the time the first method works, which makes it so that you don't even notice the fix.
But sometimes this fast restore does not work and windows moves things around after it triggers.  So the second call is a kind of backup restore that will kick in if first one was too quick to take effect.

3391

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 26, 2017, 09:14 PM »

I have code added now to check virtual screen (desktop) configuration and skip restoring unless it matches, but in initial tests it's not quite clear that this is going to work.. the thing i don't know is if the OS reports a different screen size when this weird OS wakeup moving windows behavior happens.. Stay tuned.

3392

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 26, 2017, 09:00 PM »

I have code added now to check virtual screen (desktop) configuration and skip restoring unless it matches, but in initial tests it's not quite clear that this is going to work.. the thing i don't know is if the OS reports a different screen size when this weird OS wakeup moving windows behavior happens.. Stay tuned.

3393

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 26, 2017, 08:00 PM »

One nice refinement to the tool might be if the load process checked if the monitors were back in the same position they were in when settings were saved, and if not, waited another X MS and tried again, up to some max time.
That would eliminate the need to set a long delay waiting for the monitors to come back online and be available, and would let you start trying to restore the layout right away, and it would also avoid trying to restore a layout if the windows would be put offscreen.  Just checking total workspace x,y,w,h for a match with saved settings would be fine -- no need to iterate all the monitors..

3394

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 26, 2017, 07:32 PM »

New version with substantial bug fix attached.

I was not performing my hex->dec process id check and dupe window avoidance at load time only save time.
This meant some windows would not be "seen" by the script.

The reason for this code is that there were dupe entries in the list of processes/windows which was causing the script to process windows twice.  It happened with some ids being hexadecimal and being dupes with their decimal versions.  I don't understand why but normalizing everything to decimal ids, and then making sure they aren't duplicate id that was just previously written out solves the problem.

3395

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 26, 2017, 07:17 PM »

Some serious logging there, mouser!

Hey I learned to code in the 1970s -- log statements are my main method of debugging

AHK is not a language I am comfortable with so I kept running into confusing issues where things were not behaving as I expected and I had to log info to see what was going on.

As an example, this line in your original code had me flummoxed for quite a while:

Code: Autohotkey [Select]

1. If monitorStatus=Off

3396

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 26, 2017, 07:13 PM »

Your manual save and load functions should work well in my version.

Because this version NEVER saves window positions except when you trigger via tray menu or when monitors turn off (testing via nircmd), it should be easy to use the tray menu to save your layout via tray menu, then move around some windows, then load configuration from tray menu.

No need to mess with the automatic restore when monitors power on and off, just experiment with the ability to manually save and load layouts.

Hopefully that will work for you with my version?

3397

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 26, 2017, 06:39 PM »

And here's a version without any window flickering, by directly restoring the maximized (real) window locations as WELL as the normal restored window locations when it finds a maximized window.
No flickering restore-maximize process needed anymore.

[OLD FILE REMOVED SEE SUBSEQUENT POST]

3398

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 26, 2017, 06:29 PM »

ps2. Skrommel - I think my new code that checks for maximized window position and does a restore-maximize cycle is needed even if you don't have my OS problem, if you wanted to properly restore a window that was saved maximized on one monitor and is newly maximized on a different monitor.  But it may be possible to avoid the restore-maximize cycle by just directly setting the window position while it's maximized to bring it back to the old monitor?

Another nice feature would be if the app checked to make sure that the restored positions were actually "visible" -- otherwise the app could end up moving things off screen if the old monitors did not all get reconnected, etc.  Not a concern for me just a future idea..

3399

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 26, 2017, 06:24 PM »

And here is the new code that does just what I suggested -- saves both maximized and normal window positions for each monitor, and then for windows that have mysteriously stayed maximized but moved to a different monitor, those are first restored before they are remaximized.  Other windows are left alone, which makes for much visual ugliness on screen.  (it might be possible to improve this further by making window invisible before unaximizing and remaximizing but that as this is only running on monitor wakeup i think it's no big deal).

I am really excited to try this for real when i wake up tomorrow.

[ps. I have been testing it using nircmd to put monitors to sleep -- my earlier reports that this did not reproduce the problem were wrong; turns out i just needed to give the monitors at least 30 seconds or so to go into power saving mode before waking them up).

I will report tomorrow on real-world test of the tool. 

[OLD FILE REMOVED SEE SUBSEQUENT POST]

3400

Post New Requests Here / Re: Desperate app request - restore window positions after wake from sleep scrambles

« Last post by mouser on July 26, 2017, 06:06 PM »

ps I think the most likely solution to avoiding the unmaximizing-moving-remaximizing fix that is needed for the scrambled windows, is to try to DETECT when a window has been IMPROPERLY MOVED by the OS.. Im thinking now, based on watching how the code works, that this might be possible.  Perhaps by saving in the ini file the MAXIMIZED (not normal) window location and checking that against the current one to see if it has moved physical maximized locations even if it hasn't changed the restored-state location..  But there may be an easier way.