Messages - kproth [ switch to compact view ]

Pages: prev1 2 3 4 5 [6] 7next
26
@jgpaiva: LOVE the Gui grid view! Testing on my multi-mon system and it's definitely much better behaved. I removed groups 5-10 that "shipped" with the script, keeping just groups 1-4 (all on my primary monitor), and then I added a single new group5 sized to show on my second monitor (Top@0, Bottom@700, Left@1281, Right@2304).

Group5 functioned just fine, but the number 5 wasn't visible anywhere (even though 1-4 were).

Also, will you handle odd-sized taskbars a little cleaner in the final product? Mine is two "rows" deep, so it's 50 pixels tall, at the bottom of screen 1. I added a variable called TaskbarSize and set it to equal 50, and then changed all the "30"s in your groups (e.g. GridBottom = A_WindowHeight - 30) to use it. Would it be possible to sniff out the actual position and size of the taskbar at runtime and automatically work around it?

27
I think there's a very minor multi-monitor bug in here. I have two monitors, one landscape mode (1280x1024) and the othe portrait mode (1024x1280). Thus, my PC thinks my desktop is 1280+1024x1280, or 2304x1280. But the bottom left rectangle (1280x256) is "missing". Looks a bit like this:

  [---------------][----------]
  [               ][          ]
  [               ][          ]
  [               ][          ]
  [               ][          ]
  [---------------][          ]
                   [          ]
                   [----------]

Your code for detecting the bottom and/or right edge of the screen (that sends LButton Up and snaps the window) won't allow a user in this situation to have a place at the bottom of the left-hand monitor for "dropping" windows. If it checks for MouseX >= 1280, you can't get that far down on the left monitor. If you check for MouseX >= 1024, it will prevent mouse drags in the bottom portion of the right monitor.

Is there any way to detect which monitor the mouse is in and behave differently in that situation?


28
Or could you change the order in which the preferences are applied? What I mean is, don't perform the auto-selection of the active window until *after* you finish saving the file to disk. Then, the two settings can peacefully co-exist without changing them to a combo box.

- Kevin

p.s. I noticed the active window is only located when grabbing full-screen screenshots; it's not located or auto-selectable when grabbing just a user-selected region of the screen. How tough would it be to code up the ability to identify the active window when grabbing regions or objects?

29
Oops, I just realized this isn't quite true (though it very much felt like it for a newbie). If I turn off "Reselect active region", then the auto-select settings works a little closer to "as expected".

I say a little closer because, if "auto select active window" is on and "reselect active region" is off, the behavior I see is that the screenshot comes up with the active window selected, but then as soon as it finishes saving the image, it de-selects the active region.

It seems that the "reselect active region" setting takes precedence over the "auto-select active window" setting in all cases, which makes it appear like the auto-select-active-window setting is broken.


30
Screenshot Captor / v2.15.01 bug? auto select active window...
« on: June 13, 2006, 01:22 PM »
Am trying out v2.15.01 some more, and it seems to be ignoring the "Auto Select Active Window" preference. Whether it's on or off, I still see that the active window gets auto-selected after shooting the entire screen (via PrtScrn key).


Pages: prev1 2 3 4 5 [6] 7next
Go to full version