mirror of
https://github.com/quasar/Quasar.git
synced 2026-04-25 23:35:58 +03:00
[GH-ISSUE #225] remote desktop bug- does not respond after ctrl alt del #99
Labels
No labels
bug
bug
cant-reproduce
discussion
duplicate
easy
enhancement
help wanted
improvement
invalid
need more info
pull-request
question
wont-add
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Quasar#99
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 @rabbitsmith on GitHub (May 27, 2015).
Original GitHub issue: https://github.com/quasar/Quasar/issues/225
if we press ctrl alt delete while the remote desktop session is started and then escape key is pressed, remote desktop window in xrat.exe does not respond. no input can be sent to client and then the picture does not update even after stopping and starting the remote desktop session. the only way to get it to work again is to close the remote desktop window and opening it again.
@ghost commented on GitHub (May 27, 2015):
O_o, just tried this and it kills my client, it just crashes
@ghost commented on GitHub (May 27, 2015):
fixed
@yankejustin commented on GitHub (May 27, 2015):
Hold on. I re-wrote some of it.
@yankejustin commented on GitHub (May 27, 2015):
This way, the client will continue attempting to use Remote Desktop while it is still active, even if something happens in between transfer (likely the client can't correctly handle it correctly).
@ghost commented on GitHub (May 27, 2015):
@yankejustin, yeah, its because graphics.copyfromscreen cant find the handle when the ctrl + alt+ delete screen is open, throwing a win32exception
@yankejustin commented on GitHub (May 27, 2015):
Yeah I know. I just didn't realize at first what the ctrl+alt+delete screen does to the operating system.
@ghost commented on GitHub (May 27, 2015):
Perhaps there is some alternatives to graphics.copyfromscreen? I don't think a try catch block would affect performance too much, or would it?
@yankejustin commented on GitHub (May 27, 2015):
Think of it this way: performance is not comparable when the output is not right. If try-catch blocks aren't there, we can't say it is more efficient or works faster because it will not be the right end result. An end result that is not correct is infinitely slower in my eyes.
@yankejustin commented on GitHub (May 27, 2015):
As for try-catch blocks, it ends up being almost the exact same speed. If an exception is thrown, it is a tiny bit slow, but it is desirable thing to have 1/2 a millisecond of performance hits at max instead of a crashed application. :)
I have tested try-catch blocks and there is no difference.
@ghost commented on GitHub (May 27, 2015):
That makes sense! I couldn't notice a visible performance hit either :P
@yankejustin commented on GitHub (May 27, 2015):
As a reference, the reason we do not surround every method in try-catch blocks is because it is important to handle the exceptions in the correct spot. Otherwise, behavior is not enforced, GUIs are not set to the correct state, and the upset client gets frustrated. :)