QuickSnap : Released Oct 12, 2006

[Blue]

Yes, it's a builtin feature. I don't want to prohibit a second snapshot of the same area, the dimming is just a visual feedback that it shouldn't need done.

Disable it? No, of course. But notice how the behaviour of our shutterbug is not the same in both modes...

Open Quicksnap and take a snapshot of the default selection.
Press the spacebar again. Same area, but the snapshot is of the dimmed area.
Now right-click to switch into Outline mode.
Same selection area, same operations.
In this mode, the 2nd snapshot will be identical to the first since Quicksnap "lights" up the selection area before taking each snapshot.

It's not a bug. It's just an incongruity, something to know.

[netmaestro]

No, it's a bug all right. The second snapshot in framed mode from the same area was getting saved dimmed. That should never happen. Fixed now, both modes should work identically.

Current build: 0.983

[Blue]

No, it's a bug all right. [...]

* * * working on build 0.983 * * *

Oh! You removed the incongruity ? Nice work...
And yes, of course, you're right: the word "bug" types so much faster!

Ok. That's a much better snapshot moment. More consistent operation throughout. Plus, when the shutterbug does its thing, there's no mistaking it. The user is no longer left in the dark. Literally.

What next ?
Oh yeah...
That suggestion of combining the "About " and the preferences menus into a single one ("Settings..."), adding at the same time a one-panel blurb about the operations of Quicksnap.
You haven't forgotten that now, have you ?

Incidental benefit: we'd have a 5-lines menu. Big deal, you think? Actually yes. You may know that the human mind deals much better with groupings of 3, 5, or 7. That's why a 7-digit phone number is easier to remember than a 6-digit one. Or an 8-bit byte. We're wired funny that way. So a 5-lines menu would grasp the user's attention better and more quickly than the current 6-lines one.

[oldBear]

And if you do something on the preferences, a time "option" (allow us to set it to a variable, rather than 5 seconds) might be nice, but it's damn nice as it is.

cheers

[netmaestro]

Today brings RC2 and a new feature - WindowSnap mode. This will need a bit of explanation. How it works is, you choose "Enter WindowSnap Mode" from the menu and you will find a little window near your cursor. Simply move the cursor over any window on your screen and the little window will tell you what window you're over. When you want to snap a window, press the <SPACE> bar and wait for the flashing disk. When it's complete (just a second or two) the window you snapped will be saved in your save folder. You didn't have to select anything or resize anything, just a quick snap and you've got the window saved.

To exit WindowSnap mode, press <ESC> or choose the "Exit WindowSnap Mode" menu item.

One caveat: When saving the desktop window, it works but for some reason it takes several seconds and you may or may not see the flashing disk graphic. It works fine for all other windows, but I don't know why this is happening. If someone cares to help me debug it, that would be fantastic.

[Edit] The delay was caused by using a PNG for my desktop background. It's quite quick with a Jpeg or one of the Windows backgrounds. Not sure why a PNG is slower, I guess Windows has to decode it.

Current build is RC2 1.005

[netmaestro]

Fixed a couple of bugs relating to switching back to normal mode from WindowSnap mode.

Current version: RC2 Build 1.007

[thefool]

Quite handy. Thanks!

[oldBear]

Yes, I'm beginning to regret purchasing snagit.

cheers

[netmaestro]

Your idea for customizing the wait seconds for a delayed shoot is a good one, oldbear. I'm going to do it, I've just been wrestling with the WindowSnap mode and haven't gotten to it yet. (it had me in a headlock for a while there)

[oldBear]

Well, with the addition of "snap mode", the adjustable timer becomes a little less important.

cheers

[netmaestro]

Little fine-tuning, now the info window for WindowSnap mode shows size and classname in addition to handle and windowname.

Current Version: RC2 build 1.008

[Blue]

* * * build 1.008 * * *

Nice improvements, especially breaking down the menu into sections
And very nice addition, that WindowSnap Mode.

WindowSnap Mode ;
(1) If you call the menu entry "Auto Selection "or "Auto Select", you'd have a self-documenting name.
The closing menu for that mode would, of course, have to be renamed accordingly.
(2) It works well, even on the taskbar, where you can actually get an instant picture of the notification zone icons or the Start button. Great. I've always wanted to send a picture of the Start button to my mother However, it would be better if the description box had the ability (and agility ) to change its position so that it would remain visible even when the cursor partly disappears at the bottom or at the absolute right of the screen.

If I can figure out the cause of the slowdown you mention a few posts back, I'll let you know.
But I first have to find a slowdown...

Also, i've been wanting to ask you to insert a constant on the very first line of the code:
#Quicksnap = "Quicksnap 1.008" (for instance)

I've been adding that to every source file since the beginning to keep track of things in code. (For insstance, I paste it in the "About" box title var...)
Just a little prectical thing. Anyway...

Keep up the good work.

[Blue]

The delay was caused by using a PNG for my desktop background. It's quite quick with a Jpeg or one of the Windows backgrounds. Not sure why a PNG is slower, I guess Windows has to decode it.

Could it be simply due to the fact that your chosen snapshot format was different from your desktop picture format (PNG being saved to JPG in this case) ? Just an idea in passing...

[Blue]

If you're looking at trimming useless fat, you may want to implement a very simple change in
Procedure.s ParseHotkey(key) :
remove "Saved Hotkey: " from every line,
but add it to ProcedureReturn so it reads
ProcedureReturn "Saved Hotkey: " + Result$

Not much fat here, but it's a start.

[Blue]

* * * build 1.008 * * *

In WindowSnap mode, is it possible to intercept the action of the spacebar completely ? (i.e. so it's removed from Windows' message pipe)
Currently, when the SpaceBar is pressed to take a snapshot, its presence (action) gets transmitted to whatever undelying window is being photographed. No problem most of the time, but if you happen to be taking a picture of a block selection (in an editor, for example), the block gets replaced by a space because the app owning the window responds in a normal fashion to the Spacebar message.

I can't think of anyone wanting this feature.
(meaning the spacebar pass-trough, not the WindowSnap mode!!! )