mirror of
https://github.com/NickeManarin/ScreenToGif.git
synced 2026-04-25 23:25:52 +03:00
[GH-ISSUE #120] Snap to Window, doesnt capture whole windows or dialogs #108
Labels
No labels
copy cats
duplicated
future feature
pull-request
⬜ Accepted
⬜ Completed
⬜ Help Wanted 💪
⬜ In Progress
⬜ Missing Details
⬜ Pending
⬜ Waiting For Answer ⏳
🆕 feature preview
🔷 Bug 🐛
🔷 Out Of Scope
🔷 Out Of Scope
🔷 Question
🔷Enhancement
🔷Enhancement
🔷Invalid / External
🔷Knowledge Base
🔷Won't Fix
🕑 High
🕑 High
🕑 High
🕕 Medium
🕙 Low
🕛 Critical
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ScreenToGif#108
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ltc-data on GitHub (Apr 17, 2017).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/120
Originally assigned to: @NickeManarin on GitHub.
This has been a problem for many versions, Snap is essentially broken you cant select a whole Window or dialog only the inner portions of either, so if capture involves these parts they are left out.
Only way to get the whole area is by manually expanding ScreenToGif capture area.
ScreenToGif version: 2.7.1
OS: Windows 7 Ultimate Sp1 / Windows 10 1607 / 1703
Captures of problem.
Snap to whole dialog - Mission impossible 1

Snap to whole Window - Mission Impossible 2

Good capture examples - Expected area snap should snap to.
These were captured with Snipping tool to illustrate the expected areas of dialogs / windows to be captured by snap.
Dialog

Window

@NickeManarin commented on GitHub (Apr 17, 2017):
Oh, it's a problem with the rectangle that for some reason fails to be painted on top of the window chrome/border.
I tested with W10 1607, the app snaps to the entire window, just the rectangle that does not show.
But I realized that I can improve the snapping region, expand a little bit to fit the whole window + border.
@ltc-data commented on GitHub (Apr 17, 2017):
Ah right you are, so that is the actual issue, because I didnt see a painted area around the desired Windows/Dialog complete area, naturally assumed that it wasnt being selected.
As an offtopic: see https://www.windows10forums.com/threads/screentogif-if-a-picture-speaks-1000-words-a-sequence-speaks-volumes.12790/
@ltc-data commented on GitHub (Apr 17, 2017):
Actually there seems to be a bigger issue at least here.
I was just trying to capture my NIC properties dialog via snap and it will definetly not snap.
the only way was manually
@NickeManarin commented on GitHub (Apr 17, 2017):
Indeed, just tested.
Is it a window opened with admin rights? It looks like it's not working with any window like that.
@ltc-data commented on GitHub (Apr 17, 2017):
No admin rights on that one, there wasnt even UAC prompt.
@NickeManarin commented on GitHub (Apr 21, 2017):
Alright, it looks like I'm not able to get any MouseUp/MouseDown events while the cursor is on top of windows opened with admin rights (the adapter properties window follows the same rule, it just doesn't show any UAC dialog, you can see by the shield icon of the context menu)
So, in order to work, I had to make a little hack. For that kind of window, the Snap To Window will only work after you release the mouse button AND move the cursor after that.
Also I adjusted the region of snap, it will show the border of the window.
This fix will be available for v2.7.2 or v2.8.0.
Thanks for the feedback.
@ltc-data commented on GitHub (Apr 21, 2017):
No problem, and thank you for the fix. will be looking forward to see it.
@Partixel commented on GitHub (May 12, 2017):
@NickeManarin

The visual bug is still happening ( Doesn't have admin privileges ):
@NickeManarin commented on GitHub (May 12, 2017):
Looks alright. The small offset will not be recorded.
@Partixel commented on GitHub (May 12, 2017):
Sorry, I meant it doesn't show around the edge of the window when I hover over the top bar
@NickeManarin commented on GitHub (May 12, 2017):
Oh, that I could not fix... I'm not sure why. I'm using the a Windows API to draw the rectangle.
@Partixel commented on GitHub (May 12, 2017):
Very weird :(
@Partixel commented on GitHub (May 12, 2017):
I think I figured out what's going on.
You're creating it in the context of the window the mouse is over, which has a clipping zone around itself, not including the title bar.
Maybe create the rectangles in the context of the screen2gif window so it isn't clipped?
( I've never used VS before, this was just from a quick look around and google )
@Partixel commented on GitHub (May 12, 2017):
Working code snippet:
Change line 769 of Native to
var hdc = GetWindowDC((IntPtr) null);Remove line 775 of Native
Seems to cause a lot of lag when moving the mouse around though, No idea if that's because I'm running it from VS?
@Partixel commented on GitHub (May 12, 2017):
Also thanks to that fix I noticed you can select Screen2Gifs window.. Not sure if that's a bug?
@NickeManarin commented on GitHub (May 14, 2017):
Awesome, thanks. Which line exactly to remove? Looks like we have different source codes...
Yeah, it lags because of the MouseHook, the listener that capture mouse inputs outside the app. When running from the VS, it will lag a lot.
Indeed a bug.
@Partixel commented on GitHub (May 14, 2017):
The
OffsetRect(ref rect, -rect.Left, -rect.Top);line as it's now being drawn from the edge of the screen