QuickSnap : Released Oct 12, 2006

[Blue]

Very, very nice variation on an old (good) idea.
(what follows is still based on the code presented in the code box.
Is there an updated Zip file somewhere ?)

---------------------------
Bug:
Here's a Control-C copy of the messagebox when attempting to save the resulting image:

Code: Select all

Error
---------------------------
Unable to save to C:\Documents and Settings\ [userName] \My Documents\My Pictures\QuickSnap_001.bmp
---------------------------
OK

The explanation is simple (and maybe obvious to you): my "My Documents" folder is NOT located in the assumed path!

Your Procedure LoadPreferences() makes a false assumption at line #4:

Code: Select all

  Folder$ = GetEnvironmentVariable("USERPROFILE") + "\My Documents\My Pictures\"

All documents on my machine are regrouped at
D:\Documents\[userName]\

There's no getting around it: you have to check the registry key [HKCU\...\Explorer\Shell Folders] to get the correct path after all!
---------------------------

Keep up the good work.

---------------------------
possible solution to path bug:
I have used the following to solve the path problem:

.

Code: Select all

Procedure.S Read_stringKey(key$, subKey$)
;; input 1:    key = the registry key holding the information we need
;; input 2: subKey = the value we're looking for
;; output: the value of the subkey, or an empty string
   Protected r.L, hKey.L, keyType.L
   Protected buffer.S, bufSize.L

   hKey = 0    ; handle of the registry key

; *** access the requested registry key
   r = RegOpenKeyEx_( #HKEY_CURRENT_USER, @key$, 0, #KEY_ALL_ACCESS, @hKey )
   If r <> #NO_ERROR
     ;;Debug "Erreur à l'ouverture de la clé"
     ProcedureReturn ""
   EndIf

   bufSize = 255                 ; length of buffer
   buffer.s = Space(bufSize)     ; buffer for returning data
   keyType = #REG_SZ             ; type of data we're looking for

; *** read the value of the subKey
   r = RegQueryValueEx_( hKey, @subKey$, 0, @keyType, @buffer, @bufSize)

; *** release this resource immediately
   RegCloseKey_(hKey)
   
   If r <> #NO_ERROR
      ;;Debug "ERREUR: Clé vide"
      buffer = ""
   EndIf

   ProcedureReturn buffer
EndProcedure

Then, of course, line 4 of LoadPreferences() is replaced by :

Code: Select all

Folder$ = "Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" + Chr(0)
Folder$ = Read_stringKey(folder$, "My Pictures") + "\"

It works... sort of!
The path obtained from the registry is certainly the correct one, the backslash gets appended properly, and everything looks kosher, until I actually save the image. Then the final backslash evaporates from the end of the path variable.

How ? Where ? When ? Don't know. And it's killing me

Meantime, instead of solving the problem, I went around it.
I've added a check on line 13 of SaveScreenShot(), which looks like this:

Code: Select all

  If Right(Folder$,1) <> "\"
      folder$ + "\"
  EndIf 
  saveloc.s = Folder$ + "QuickSnap_001" + ext$

However, I'd really like to understand when and where the backslash disappears from the end of the Folder$ variable.

Any explanation for this apparently perfectly idiotic behaviour ?


.

[Blue]

--------------------------
Oups
The messageBox that appears in answer to a click on "About QuickSnap" is titled "About Shooter"
--------------------------

I'm sure you had something more appropriate in mind, like " Oupsy " or ...
"About QuickSnap", perhaps ?

.

[Blue]

---------------------------
possible bug:
certainly not a feature !

When i move the selection window, the highlighted area, which will end up being saved as the image file, stays behind while the outline of that area moves obediently to my newly chosen area. The little disk icon, in the middle of the frame, moves with the outline...

Can you see the problem ?

On my machine (as you may have guessed by now), the option to show the contents of a window when moving it is OFF. So the behaviour of QuickSnap is intelligent and consistent with the expected behaviour of windows on this system. However, Surprise! surprise! what gets saved is not the area within the outline (and under the disk icon) but the highlighted area, the one that stayed back at the previous position, on the other side of the screen !!!

---------------------------

Is that a feature ?
Really ?

[Character]

I cannot see the problem.. when I take a snapshot I am not moving around the selection window.
(why would I? Yes ok, for testing, that's fair)

OK, when I do, there is some delay indeed (like a 1/4 sec) but when I stop moving around,
the selections merge again and the taken snapshot is reflecting the correct area.

@ Blue: are you taking the snapshot WHILE moving around the windows?

Maybe the problem related to hardware performance?

[Blue]

Character:

Why don't you read my post again ? Figure out what the 3rd paragraph is describing...

Nobody in his right mind (and that includes me) would attempt to take a snapshot as the selection window WHILE moving the selection window around. Not even for testing purposes. It simply does not and would not make any kind of sense. Besides, how would that be achieved ? The application is busy dealing with an event (moving a Window) and couldn't possibly be treating another one pertaining to the same area at the very same time.

Look at this picture:

The selection frame on the left of the "screen" (as shown by the outline box) has just been moved to that position. It is NOT moving; the mouse button has been released and the frame is in its NEW final stationary position. The white highlighted area is on the right, still in the previous positon occupied by the QuickSnap selection frame. It has remained behind (litterally!).
Clicking on the Save icon will save the highlighted area to the file, not the area delimited by the selection frame and containing the "Save" icon.

Understand now?

(Besides, if you cannot see the problem, good for you.
But then why even bother addressing it?...)

.

[netmaestro]

Blue, thanks for the excellent report. I didn't test it that way earlier. I've fixed it, and the fix also corrects the "dragging lag" for two birds with the same MoveWindow_(). The about box is titled correctly now too. I'm still looking at options for the save folder, which is why I haven't done that part yet. Your help in this project is very much appreciated.

[Character]

the option to show the contents of a window when moving it is OFF.

that was the part I didn't realize. I my case it was ON. so that explains the total different behaviour ... oeps

Understand now?

(Besides, if you cannot see the problem, good for you.
But then why even bother addressing it?...)

take it easy Blue.. I'm just trying to help that's all --- I must admit you have a sharp eye for things

[Blue]

take it easy Blue.. I'm just trying to help that's all

Sorry character.
I read and answered your question at the end of an evening in the company of characters all very busy talking, but not interested whatsoever in listening. Your question appeared at the tail end of a simmering fire... and the fuse went off.
Anyway, you do have the grace to recognize that you had not read entirely the information provided.
That's rare. My hat off to you...

Good advice, about taking it easy. i'll try (;>) hard! Harder!!!

[Blue]

[...]I've fixed it, and the fix also corrects [...] The about box is titled correctly now too. [...]

Great.

There are many things to like about the code you produce, but what I personnaly like the best is how cleanly and clearly organized it is.
It's very rare to actually find pleasure in reading someone else's source code! No smal feat in producing that.

A favour, please:
Consider adding a line to that neat header you write at the beginning of your source code.
It would be useful if line 3 of the header, right below version became build (or some such thing). A single integer or letter, or the current time and date, would do. Just something, not intellectually straining, to determine at a glance whether the current text has changed since the last read.


For instance, with the current header being the same as it was the day before yesterday, i wasn't sure whether I was looking at a version incorporating the changes discussed just now . So I searched the source text to see if the "about text" was the corrected one or the same old same Of course, I could have looked at the bottom of your post: it indicates clearly when you last modified it, but I didn't think of that (too simple!) Now, finding that info in the header would truly bring us -- well, at lest me! -- close to paradise...

So, come on. be a good sport and give us one more line.

(Besides you've already spoiled us. Now we're being choosy and we'll only accept the best. Sorry. )

.

[netmaestro]

Good suggestion, it's implemented. I'm glad you like it, and it's the kind of help you're giving that will make it a solid product when it gets released. Thanks a million.

[Blue]

From testing RC1 build 0.940
-------------------------------------------------
preferences window
(1) a personal preference: label the menu entry "QuickSnap preferences" rather than "Set QuickSnap preferences"

(2) If you make the Path label an input box (String Gadget?), users who prefer keyboard operations could type in directly their preferred "Save" path. Of course, you then have to keep an eye on keeping that tightly synchronised with the ExplorerTree Gadget, ( or rather the other way around), but what the heck! Plus, users could very well enter a non-existent path. You then have to ask if they're screwing up again or if they actually mean to create a new path... But like I said, what the heck !

(3) At present, upon entry in the Hotkey panel, the Hotkey input box does not reflect the existing hotkey. Which, of course, could be exactly what you in mind. But i, for one, was expecting the input box to display my current hotkey.

-------------------------------------------------
snap operations
in general: Truly fabulous! The remote operation (right-click thing) gives the whole thing an aura of great intelligence, which is always pleasant to find in any software. And there's something magic about how very finely the selection window can be controlled via the arrow keys. Clean, efficient, simple, and very intuitive. Perfect really.

... Well, almost !

(1) keyboard shortcut urgently needed for the Save icon! You could simply make it the same as the hotkey that calls Quicksnap into action. Unless i'm mistaken, at present, there is no key dedicated to that operation: we have to remove our fingers from the keyboard, start hunting for the mouse somewhere under under all those papers, and then click on the cute icon. Ah! My fortune for a shortcut.

(2)another reason to implement APS a "Click that shutter" shortcut: the selection area can actually be reduced down to a 1 X 1 zone ! And below a certain size, the Save icon becomes useless 'cause we can no longer find it. Ah! My fortune, again, for a shortcut.
Oh! and, yes, the only way (at present) to exit when the selection is extremely small is through an Alt-F4 combination.

(3) Brilliant and very useful how the selection box grows with the Shift modifier, and shrinks with the Alt modifier. But I think it would be more appropriate to attach the shrink operation to the Control modifier. More intuitive, less finger travel, and, mainly, a closer logical relationship to the operation of the arrow keys (i.e buttons clustered together). Does Windows forbid using the Control + Arrows combinations ?

-------------------------------------------------
There were a couple of other things, but I forget. (Very minor things)
No bugs anyway.

What do you think ?

[Psychophanta]

One more thing:
Detect if the app is still running to avoid to launch it more than once.

[netmaestro]

Thanks for the good suggestions. Keyboard shortcut and single instance enforced are both excellent ideas. Both are implemented, the pic-snapper key is the space bar. (but I may make selecting the key part of the preferences later)

[netmaestro]

Couple more small enhancements:

-Instead of just ignoring you, trying to start a second instance of the program brings up the About box in the existing instance. Just seems a bit more polished behavior like this.

-RunProgram for the website is altered to use any browser, not just ie.

Current build is 0.960

[mskuma]

netmaestro, thanks for sharing this - it's great.

Some suggestions/issues:

- I'd suggest mapping Esc to close button, so user can use a keyboard shortcut to close the capture window

- on the set hotkey panel, it would be better to avoid forcing the user to set the focus to the text box (to capture the new hotkey). I've seen some programs simply just capture the keystroke(s) on that form when setting a new keystroke (and the user can see the hotkey updated in a text field as they press).

- on the same panel, for me, pressing Ctrl or Alt-F1 brings up Ctrl-p or Alt-p in the 'Saved hotkey' notification text when the 'Set' button is pressed, likewise if I press Ctrl-F2, Ctrl-q is shown. However the hotkey keystroke works as pressed (e.g. Ctrl-F1).

- usually I have to press the hotkey twice to see the capture window (i.e. seems like the first one is ignored).

- in Save folder panel, in the folder tree perhaps it is good to show the current folder as an 'open folder' icon to emphasise the current folder.

- since there is no help, perhaps the first time that the user sees the capture window with the disk icon, some one-time text underneath it that explains the function would be helpful, e.g "click the icon or press space to capture". Probably from the second instance of the capture window, it's not necessary to display this text (or better still, you could put a checkbox underneath it saying 'don't show this text anymore'). There seems to be some extra subtle stuff in there like the arrow key functions that are not immediately obvious, so this needs explanation (maybe add another menu item for help, or add this info into the About menu. If you did that, it's worth adding that pointer to the one-time brief help text.

(edit: all this noted from the build prior to 0.960)