topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Wednesday December 3, 2025, 8:18 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Recent Posts

Pages: prev1 ... 132 133 134 135 136 [137] 138 139 140 141 142 ... 1514next
3401
Just saw IdleWinPosSaver.ahk, let me download and look at that too.
3402
So it detects the monitor off and on correctly?
Yes it seems so..

Maybe a delay before moving the windows around is needed?
I think so.  The fact that nothing "seemed" to have happened after the monitor woke up makes me think that the script saved the "bad" positions.. possibly it tried to restore positions before the monitors were fully woken up and then the OS moved them around, and then the script memorized the bad positions..



I'm also thinking that if it reliably detects monitor  OFF and ON conditions, it might be possible to autosave positions ONLY at monitor OFF signal.

Let me experiment with your code and add some logging and see what I can see..
3403
Are we allowed give critical feedback on the visuals, or is that premature

Yeah probably best to wait.. When the new site is ready we will make it available for beta testing by folks, and then go through a period of testing and tweaking before it goes live.  That will be the time for people to make suggestions, etc.
3404
Ok so here are the results from waking up this morning:

The log does seem to have triggered an event when the monitors woke up:
20170726070222 - PBT_POWERSETTINGCHANGE - Monitor: Off <-- in the middle of the night
20170726111030 - PBT_POWERSETTINGCHANGE - Monitor: On <-- last event and when the monitors woke up

Observed behavior was as follows: When the monitors woke up this morning, window positions got moved around as they normally do.. WinPosSaver did not seem to do anything.



One thing I need some clarification on is as follows:
When I first tried WinPosSaver, I was testing the manual save and load functions.. But I see now that it's saving window positions to file on a timer.. So I guess I really should not expect to be able to save and load manually and have that work..  Perhaps for testing purposes it would be nice if the MANUAL save and load functions used a separate data file from the automatic system.  That would make it easier to test issues..



I'm ready to test the next version when you are ready..

ps. Manually putting the monitors into sleep mode does not seem to be a viable way of testing this issue, because if I manually send them to sleep (via nircmd for example), they wake up fine.  It's only after they've really been off for a couple of hours that they exhibit this wake problem..
3405
Just a quick first report:

Miraculously, using WinPosSaver to save window positions, and then moving them, changing min/max states  around, and then using WinPosSaver to restore them.. Worked flawlessly.  :huh:

I did not expect that at all.. I expected lots of problems with different windows not restoring their maximized state, and other oddities..

So yeah, great success so far..  Now it's a matter of getting it to automatically save before the monitor problem, and automatically restore after.
3406
Try the latest version. I added monitor sleep detection, and logs power events to log.txt.

Will do.
3407
And needless to say, your application would have other uses besides saving my sanity -- i'm sure there are people that would like to be able to save and restore window positions manually to help them with different tasks.  But let's leave those people for later -- I am the one in need of saving at the moment :)
3408
Ideally once the basic operations were working, one could experiment with ways to reduce unneeded operations and cpu usage..  That is, it would be nice if one could find ways to only have to save window positions once right before the problem (which might be possible if one could get a signal that happened when monitors fall asleep, or only once after the computer has been idle for at least monitor-sleep-time, say 30 minutes), so that window positions would not have to be saved frequently during normal pc use.

And another tweak would be to eventually not use my suggestion of the user specifying when the monitors are in the the "normal" configuration, perhaps by this same mechanism -- by assuming that when you do your one-time save of window positions after some long idle time (or after monitor sleep time), then THAT is the normal configuration, and updating what you consider the normal configuration when the monitors fall asleep...

Again both ideas are based on my observation that the problem happens at the time that the monitors WAKE UP from being asleep -- not when they fall asleep.
3409
Let me get skwire to upload the tool he wrote for me to WM_DISPLAYCHANGE events and log monitor positions, it's what we used to try to figure out what was going on..

Let me try to describe my setup:

I have 4 monitors.  My pc never sleeps or hibernates, but the monitors to go to sleep and turn off after about 30 minutes.  So when I wake up after 8 hours, and first come to the pc, that is when windows move all over the place.  Presumably because one or more of the monitors does not wake up in time.

Importantly: The movement of windows seems NOT to happen when the monitors first go to sleep.. it happens only at the time of waking up(!)
It seems at wake up time is when windows gets confused.

Here is what we saw one day when looking at the WM_DISPLAYCHANGE events:

The situation after a few hours of sleep:

Code: Text [Select]
  1. Hourly check...
  2. 2017-05-10 09:52:44 AM ------------------------------
  3.  
  4. Monitor Count:  4
  5. Primary Monitor:        1
  6.  
  7. Monitor:        #1
  8. Name:   \\.\DISPLAY1
  9. Res:    2560 x 1440
  10. Left:   0 (0 working)
  11. Top:    0 (0 working)
  12. Right:  2560 (2560 working)
  13. Bottom: 1440 (1410 working)
  14.  
  15. Monitor:        #2
  16. Name:   \\.\DISPLAY5
  17. Res:    2560 x 1440
  18. Left:   2560 (2560 working)
  19. Top:    0 (0 working)
  20. Right:  5120 (5120 working)
  21. Bottom: 1440 (1410 working)
  22.  
  23. Monitor:        #3
  24. Name:   \\.\DISPLAY6
  25. Res:    1440 x 2560
  26. Left:   -1440 (-1440 working)
  27. Top:    -601 (-601 working)
  28. Right:  0 (0 working)
  29. Bottom: 1959 (1929 working)
  30.  
  31. Monitor:        #4
  32. Name:   \\.\DISPLAY2
  33. Res:    1920 x 1080
  34. Left:   -3360 (-3360 working)
  35. Top:    180 (180 working)
  36. Right:  -1440 (-1440 working)
  37. Bottom: 1260 (1260 working)

Everything is fine at this point.. but here is what happens when i press keyboard and "wake up" the monitors:

Code: Text [Select]
  1. WM_DISPLAYCHANGE event...
  2. 2017-05-10 10:02:05 AM ------------------------------
  3.  
  4. Monitor Count:  3
  5. Primary Monitor:        1
  6.  
  7. Monitor:        #1
  8. Name:   \\.\DISPLAY1
  9. Res:    1920 x 1080
  10. Left:   0 (0 working)
  11. Top:    0 (0 working)
  12. Right:  1920 (2560 working)
  13. Bottom: 1080 (1410 working)
  14.  
  15. Monitor:        #2
  16. Name:   \\.\DISPLAY5
  17. Res:    2560 x 1440
  18. Left:   2560 (2560 working)
  19. Top:    0 (0 working)
  20. Right:  5120 (5120 working)
  21. Bottom: 1440 (1410 working)
  22.  
  23. Monitor:        #3
  24. Name:   \\.\DISPLAY6
  25. Res:    1440 x 2560
  26. Left:   -1440 (-1440 working)
  27. Top:    -601 (-601 working)
  28. Right:  0 (0 working)
  29. Bottom: 1959 (1929 working)


Note that it has actually "lost" one of my monitors at this point.. And even more frustrating, another WM_DISPLAYCHANGE event is *NOT* sent when it eventually sees it a few seconds later..



SO I am guessing that the procedure will have to look something like this:

1. Save windows positions occasionally.
2. When a WM_DISPLAYCHANGE event occurs, do NOT assume it is a correct thing.. Instead, use it to start a timer, which will RECHECK monitor situation after a few seconds.
3. After the delay has passed and the monitors come back, get current real monitor locations and restore any windows locations that have changed.



So I can think of a few ways a program could work that would make me happy, perhaps the simplest would be something like this:
a) let me tell the program when my monitors are in there "normal" configuration (ie just select a menu operation).
b) when the monitors are in this state, the program can save windows locations periodically -- or in fact since we know that the OS doesn't actually have any problem while the monitors are asleep, you could simply save window positions ONCE, when the monitors fall asleep]
c) when you get a WM_DISPLAYCHANGE message, set a timer that has you check monitor configurations occasionally, and WAIT UNTIL THE "GOOD" (normal) monitor configuration comes back
d) that is when the windows should be restored.

Step C is the key part -- you are essentially detecting a WM_DISPLAYCHANGE message as a "signal" that the monitors are in an UNSTABLE state that is likely to bounce around for the next few seconds, and cannot be trusted.  This is where MS Windows messes up windows positions.  So then the key is to just WAIT until the monitors come back to their "normal" configuration (and don't assume you will get a WM_DISPLAYCHANGE message when they do, you just have to wait a few seconds and/or check their state).  Then when the monitors are back to "normal" the window positions can be restored.

Does that make sense?
3410
ps. I would love the ahk code so I can help tweak and experiment!
3411
Ok well first of all, I am thrilled, thrilled, thrilled to see the amazing skrommel working on this idea.. I suffer from this problem to this day, and it drives me crazy.  I would love to have a solution.
I do imagine it will take some iteration and quite a bit of experimentation to get it working flawlessly, but Im happy to test.  Downloading now.

Just a heads up, before I even use it I will report one thing -- DC Members skwire (the *other* ahk master on this forum) worked with me a bit on trying to identify the nature of the problem, and one unpleasant thing we discovered is that the windows displaychange messages that are broadcast whenever resolution/monitor changes happen, would occasionally FAIL TO REPORT a change, at least on my machine.  This means that any solution to this problem cannot rely on those messages being 100% accurate.
3412
Screenshot Captor / Re: Settings are reset to default
« Last post by mouser on July 25, 2017, 11:04 PM »
My question, I suppose, is will SC always look in the right place given that are two My Documents folders?
as long as it's started by the same user it will look in the same place..

Regarding the ConfigDir.ini file, the important thing is to not have // at the start of the line you want to use -- as you guessed that indicates a comment.  Other than that it should just work.
It's easy to find out -- just try it and see if it saves it's settings where you told it :)
3413
Screenshot Captor / Re: Settings are reset to default
« Last post by mouser on July 25, 2017, 09:01 PM »
Can I use the    ConfigDir.ini    with    CONFIGDIR=D:\MY_DATA\   to force SC to find the ini file?
yes.

BUT note that SC should be able to use it wherever it can write it -- so if its saving it in "D:\MY_DATA\DonationCoder\ScreenshotCaptor" there is nothing wrong with that, and that shouldn't cause any problems.
As long as applications have permission to write into that directory.
3414
Living Room / Re: Animal Friends thread
« Last post by mouser on July 25, 2017, 08:21 PM »
Bird opens box..

3415
Thanks for saying so  :up:
3416
Screenshot Captor / Re: Settings are reset to default
« Last post by mouser on July 25, 2017, 07:55 PM »
Check also for a Configdir_Default.ini file in the SC directory.
One of the ways this not-able-to-save problem can occur is if people move a portable configdir (or configdir_default) file from their old portable install to the new one.

The other thing to check is that it is saving its settings file (ScreenshotCaptor.ini) where you expect (by default: C:\Users\USERNAME\Documents\DonationCoder\ScreenshotCaptor\ScreenshotCaptor.ini).
3417
Screenshot Captor / Re: Settings are reset to default
« Last post by mouser on July 25, 2017, 07:22 PM »
Ok that suggests that the program may be having a hard time saving it's settings file, the question is why.

Are you using the portable version or the installer? Did you transfer your settings from one computer to another? If using the installer, did you install someplace other than the default location?

Try this first: Make a change to one of these settings (hotkey, starts with windows, whatever but something that you will remember), and then MANUALLY EXIT SC, and restart it.  See if the setting you changed gets reset or not.

And see if that setting gets lost the next time your others do.
3418
Screenshot Captor / Re: Settings are reset to default
« Last post by mouser on July 25, 2017, 07:06 PM »
Let me ask a question first, is it resetting stuff to defaults, or are your settings being completely blanked out.  Here's how to tell -- go to for example the "Hotkeys and Shortcuts" tab and look at the top set of dropdown boxes.  Are they BLANK or are they set to some default values?
3419
DesktopCoral / MOVED: Settings are reset to default
« Last post by mouser on July 25, 2017, 07:04 PM »
3420
Screenshot Captor / Re: Settings are reset to default
« Last post by mouser on July 25, 2017, 07:04 PM »
Ok moving this to SC discussion where we can continue.
3421
A little teaser image..
Modern fancy visuals are not really my strong-suit, so don't expect miracles, but I do think this is a little bit of an improvement over the current site:
dcblognew.png

Again -- this major transition to a proper CMS system for the DC website is not about improving the look of the site, it's mostly about making the long-term, back-end maintenance of the site significantly more flexible and sustainable, and make it much easier to add and modify content.  But some moderate attempt is being made to improve the look and feel of the site, while keeping the same "personality".
3422
Screenshot Captor / Re: Settings are reset to default
« Last post by mouser on July 25, 2017, 05:45 PM »
You've posted in the DesktopCoral thread but mention SSV.. Am I right in assuming you are talking about Screenshot Captor?
If so I'll move this post to the Screenshot Captor section.
3423
Find And Run Robot / Re: Assign hotkeys to user-toolbar items
« Last post by mouser on July 25, 2017, 04:44 AM »
You might want to try my LaunchBar Commander.  You can set up all manner of menus and docking bars, visible, automatically-hiding, system tray, with all manner of entries for launching files, etc..  All can be toggled-with custom hotkeys and each configured item can have a custom hotkey set for it:

https://www.donation...r/LaunchBarCommander

To emphasize, you don't have to have a visible docking bar with LBC, you can just have a menu in your system tray and trigger individual items with the hotkey, or use a hotkey to toggle a pop-up menu under the cursor.

3424
Non-Windows Software / Re: Android: (Wired) File Transfers from PC
« Last post by mouser on July 24, 2017, 10:52 PM »
I've been pretty happy with airdroid.
3425
You can now regularly pick up "Pandemic Legacy" for $30-$40 (for example here at coolstuffinc where I buy my board games: http://www.coolstuffinc.com/p/212613).

The best board game experience I have ever had, by far, in more than a decade of playing board games (I wrote about it here).

I think everyone on the planet should try this game..
Pages: prev1 ... 132 133 134 135 136 [137] 138 139 140 141 142 ... 1514next