mirror of
https://github.com/NickeManarin/ScreenToGif.git
synced 2026-04-26 07:35:54 +03:00
[GH-ISSUE #485] Program Stops Responding While Entering File Name #403
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#403
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 @DommDynamite on GitHub (May 22, 2019).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/485
Originally assigned to: @NickeManarin on GitHub.
OS: Windows Server 2012 R2
While typing in a file name, the program will go into not responding status for around 5-6 seconds before entering each letter.
@michael-milette commented on GitHub (Jun 13, 2019):
OS: Windows 10
I have experienced something similar with very large video (about 10 minutes). As soon as I started entering the filename, it stopped responding. It took a while but it did eventually unblock after a few minutes and I was able to finish typing the filename.
@NickeManarin commented on GitHub (Jun 13, 2019):
Can you two share with us the path and filename being used?
@NickeManarin commented on GitHub (Jun 29, 2019):
Well, I changed the way that feature (that checks if a given filename exists already or not) works.
So instead of checking after every text change, the app will only make 1 check 500ms after the last letter that was typed.
@michael-milette commented on GitHub (Jul 2, 2019):
I don't think it is relate to the actual filename. I noticed this becomes problematic with longer videos (animated GIFs). For example, I had one that started off being 15 minutes and I was editing it down to about 8 minutes.
This was not a problem with short 2-3 minute videos.
@NickeManarin commented on GitHub (Jul 8, 2019):
Well, it makes sense that a longer recording would hang more than a small one, because there's more resources allocated to displaying more frames to the list.
Btw, I forgot to ask. What filename textbox are you referring to? The one inside the Editor window or the one inside a "Save as" dialog from Windows itself? The second one I have no controls over.
Anyway, I changed the way that I'm checking if a filename was used or not because the old way was not good.
@michael-milette commented on GitHub (Jul 8, 2019):
Thanks for fixing it. It was indeed the one in the editor window, not the Windows one.