Messages

26

Post New Requests Here / Re: IDEA: drag window to edge automatically resizes it

« on: July 03, 2006, 07:08 AM »

@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

Post New Requests Here / Re: IDEA: drag window to edge automatically resizes it

« on: June 16, 2006, 07:08 AM »

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:

[Select]

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

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

Screenshot Captor / Re: v2.15.01 bug? auto select active window...

« on: June 13, 2006, 01:41 PM »

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

Screenshot Captor / Re: v2.15.01 bug? auto select active window...

« on: June 13, 2006, 01:27 PM »

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).

31

Screenshot Captor / Re: Option to NOT save to file?

« on: June 12, 2006, 04:28 PM »

Good tip - I'll try that on for size.

I think it's perhaps more of a mental thing - if I don't want to save it, I'm thinking "why should I have to go clean it up at all"?

Also, I was initially testing within a Virtual PC, and there was a noticeable delay waiting for an image (especially full screen) to save to disk (I was using JPG format instead of PNG if that also makes a difference). Would the delay be reduced or eliminated if there existed an option to not save to disk?

32

Screenshot Captor / Re: please add rectangles to the editor

« on: June 12, 2006, 04:10 PM »

as for other shapes... is there really a need for other shapes?
(maybe a rounded rectangle would be nice)

-mouser (September 28, 2005, 04:52 AM)

I, for one, would really appreciate rounded rectangles!

33

Screenshot Captor / Option to NOT save to file?

« on: June 12, 2006, 04:05 PM »

Feature request: I'd enjoy an option to not save my screencaps to files. I would combine that the the existing option to automatically copy screencaps to the clipboard.

I still want to be able to preview and edit/annotate my screencaps in the built-in image editor, with the option to save if I choose, but most of the time I'm only grabbing screencaps to paste into emails and in that case I don't want to have to go back and clean out my captures folder...

Thanks,
- Kevin

p.s.: awesome app!

34

Finished Programs / Re: DONE: Dim rest of desktop/windows, except for focused window

« on: June 12, 2006, 03:10 PM »

Neat idea, but I'm seeing a couple issues with it:

1. I have a multi-monitor setup where the primary monitor is in landscape mode (1280x1024) while the secondary is in portrait mode (1024x1280). Even with the multi-monitor support turned on, it doesn't seem to dim anything on monitor #2.

2. If I change to showontop=1 (to always show the always-on-top windows), my task bar goes dim when the app first starts, and doesn't undim until the first time I click on it.