В Windows есть 2 способа получить изображение экрана:
1. Ставить свой видео-драйвер (Быстрый, но замороченный). Вроде как начиная с Vista и старше появился специальный API позволяющий также быстро получать изображения экрана, минуя установку видео-драйвера и все бы хорошо, но XP еще жива.
2. Через GDI экран копируется в память. Это медленней и грузит процессор, но на современном железе приемлемо и работает на любой версии Windows.
Дальше полученное изображение разбивается на блоки (например 32*32) и все блоки прошлого кадра сравниваются с блоками нового кадра, и те, что отличаются, сжимаются и отправляются клиенту. При медленном соединении можно еще добавить небольшой трюк: если блок был поставлен в очередь на отправку, но еще не успел улететь из-за тонкого канала, а уже еще раз поменялся, то можно не накапливать очередь, а просто обновить блок в очереди на более новый. В результате пользователь может увидеть неравномерное обновление блоками, зато какая-нибудь анимация не забъет весь канал своими бесконечными обновляемыми участками.
RDP работает не так, он не позволяет просто подключиться к локально залогиненной сесии. Он требует наличие пароля у виндового пользователя + при использовании вылогинивает его локально. На работе это нормально, но дома мне такое не нужно. Да и к тому же у меня дома 4 монитора, а на работе 2. Когда я подключаюсь по RDP — он переключает сессию делает 2 монитора и у меня все съезжает.
Поставил программу потестить и сразу же наткнулся на баг при использовании нескольких мониторов. Всего 4 монитора, рабочий стол сделан так: ________МОНИТОР
МОНИТОР МОНИТОР МОНИТОР
В результате кликает не по тем координатам, по которым кликаю я. И очень не хватает выбора монитора в свойствах подключения. Чтобы можно было выбрать: показывать все или какой-то конкретно. И еще бы это сохранить. А так очень рад появлению бесплатного Радмина. Сам в свое время пытался сделать, что-то подобное (и даже сделал и пользуюсь иногда), но завяз с тем, что взаимодействие с рабочем столом пользователя сложно было сделать из под службы, а пользовательским приложением нельзя залогинится. Для скорости, кстати, использовал LZO сжатие и 4/8 бит GrayScale. 16 цветов — все выглядит ужасно, но 16 оттенков серого :) — выглядит вполне прилично и сносно работает на медленных соединениях.
На самом деле, не смотря на то, что сервис, вроде как, пользовался исключительно публичной информацией, и никаких законов не нарушал, я был немного шокирован, когда увидел его в работе. Дело в том, что я в общем-то был не против того, что если кто-то зная мое ФИО или круг общения сможет увидеть и мои фото. Но то, что кто-то, имея мое фото, сможет узнать мое ФИО и мой круг общения — это очень плохо, потому что незнакомый мне человек может втереться ко мне в доверие используя полученную таким образом информацию. Но в общем-то подобные сервисы и открывают обратную сторону соц. сетей, не делая ничего противозаконного, поэтому иногда стоит задуматься, как лучше поделиться фотографиями/мыслями со своими друзьями/близкими: или замороченно но безопасно, или просто, но с возможными неприятными последствиями.
Ваш ответ третьей задачи хорош. А вот мне пришло в голову только это:
Убийственное решение
— Привязать веревку на верхний крюк
— Спуститься до нижнего крюка и привязать низ веревки (50й её метр) к нижнему крюку
— Снова подняться по веревке наверх на 49,5 метров
— Обрезать веревку и пролетев 99 метров, остановиться держась за веревку в полуметре от земли
— Спрыгнуть на землю :)
Для этого достаточно всего 50м веревки, а не 75. Вероятность выживания альпиниста не 100% :)
По ПДД вообще непонятно, как трактовать электросамокат. Споры по этому поводу не утихают на разных форумах уже долгое время. По идее он ближе к электроскутеру, чем к самокату. И когда на дорогах их станет больше, и больше станет ДТП с ними — тогда его наконец додумаются классифицировать в ПДД.
К пешеходам приравниваются лица, передвигающиеся в инвалидных колясках без двигателя, ведущие велосипед, мопед, мотоцикл, везущие санки, тележку, детскую или инвалидную коляску, а также использующие для передвижения роликовые коньки, самокаты и иные аналогичные средства.
Для велосипедиста, таки, как раз надо спешиваться, т.к. вести велосипед не равно ехать не велосипеде. К тому же в там перечислены «велосипед, мопед, мотоцикл». Не думаете же вы, что мотоциклист тоже может ехать по пешеходному переходу не спешиваясь?
Для самоката да, спешиваться не обязательно, но здравый смысл подсказывает, что в ПДД подразумевается обычный самокат, средняя скорость которого 8-12 км/ч, + пешеход должен удостоверится, что его видят и пропускают, а для этого перед переходом нужно, как минимум сбавить скорость. Вылет же на переход на электросамокате на скорости 25-30 км/ч — это ИМХО злоупотребление надоработками ПДД, которое может привести к печальным последствиям.
Лично, я в соответствии с ПДД на пешеходных переходах спешиваюсь, благо на самокате это сделать гораздо проще, чем на велосипеде. На большинстве переходах (в Питере), как правило, бордюр опущен для заезда инвалидных колясок. Но даже если и нет, ничего страшного в том, чтобы поднять на секунду 12 килограммовый самокат, нет. Вот подземный переход без рельс для колясок напрягает уже сильнее, особенно когда надо вверх :) Но таких очень мало.
Иногда комментирую старый код, который потом долго живет в проекте. Причина такая: Иногда сваливается баг и данные на которых его можно воспроизвести, под отладкой я смотрю входные данные в функции, исправляю чтобы все работало и благополучно об этом забываю. Через полгода или позже приходит новый баг с другими данными для воспроизведения, я снова под отладкой смотрю в чем проблема в той же функции и снова исправляю… на первый вариант, написав его один в один, как он был изначально. Поэтому иногда оставляю комментарии:
Среднестатистического пользователя вообще не волнует будет ли закрыт процесс или нет, он даже может не знать, что это такое. Ему важно, чтобы файлы с которыми он работал были сохранены и корректно закрыты. Если процесс повисит в памяти ещё какое-то время (особенно если памяти много) — ничего страшного не будет, даже наоборот, время запуска документов ассоциированное с этим приложением уменьшится и пользователь от этого только выиграет. При этом когда памяти останется мало, приложение может выгрузиться окончательно. Такое умное поведение программы у пользователя вызовет лишь положительные эмоции.
Давайте разделим приложения на два типа:
1) Приложение которые запускаются пользователем вручную, у которых есть главное окно в котором и работает пользователь, при закрытии которого приложение обычно завершает свою работу.
2) Приложения, которые, как правило, стартуют самостоятельно, показывая лишь иконку в трее. При двойном щелчке по иконке в трее или при щелчке по одному из пунктов трей-меню приложения, оно может показывать какие-то окна. Но при их закрытии приложение не должно никуда деваться из трея.
Т.е. грубо говоря, если при запуске приложения было показано окно, то при его закрытии, приложение в 99% завершает свою работу. Если же при запуске, никаких окон показано не было, и окна появлялись уже после взаймодействия с трей-значком, то при их закрытии приложение завершать свою работу не должно.
Но бывают и исключения, например, когда пользователю не нужно приложение в автозагрузке, и при запуске оно показывает главное окно, но при его закрытии уходит в трей, т.к. является ещё и фоновым сервисом.
Во всех случаях при нажатии кнопки закрыть окно — оно закрыватся. Было ли при этом завершено приложение? А должно ли пользователя это вообще волновать? И что значит приложение было завершено? Завершен ли процесс? А что если трей-иконка и окна открытые, при нажатии на нее это разные процессы? Можно ли считать приложение завершенным, если закрывая окно, процесс их породивший завршится, при этом другой процесс того же программного продута останется висеть с иконкой в трее? А если при закрытии главного окна приложения, оно не завершается еще какое-то время, чтобы при последующем запуске не тратить время на загрузку ресурсов? Возвращаемся к изначальному вопросу: должно ли пользователя это волновать, и если у него нет проблем с производительностью ОС? ИМХО — нет.
Но это же все равно не решает проблемы разного поведения кнопки закрыть. Например для дополнительных окон, кнопка закрыть будет закрывать только окна, для основного окна кнопка закрыть будет завершать приложение. Причем зачастую при закрытии главного окна работа приложения завершается, несмотря на то, что у приложения были открыты и другие окна. Мне кажется так, как сейчас уже сделано оптимально. Нужно понимать что окно — это не приложение, а всего лишь его часть, не всегда обязательная, т.к. не любое приложение обязано иметь пользовательский интерфейс. Кнопка закрытия всегда закрывает окно и если после этого приложению больше нечего делать — оно закрывается. А если у него осталась другая функциональность — оно продолжит работу. Такое понятие, как «свернуть в трей», придумали зря. Чаще всего, у приложения всегда висит иконка в трее, независимо от открытых окон. Такое приложение есть ничто иное как сервис, который позволяет показать некоторые окна с информацией и после их закрытия также продолжит работу. Почему это должно быть не так? И тогда сразу следующий вопрос: а если приложения из трея, по клику или из меню запустит другой процесс в котором будут окна, должно ли оно будет завершиться когда эти окна будут закрыты? :)
Тогда надо делать две кнопки «закрыть окно» и «закрыть приложение», но что делать если было закрыто последнее окно приложения и у него нет иконок в трее? Все равно ведь придется закрывать приложение :) Если только у последнего окна приложения, которое завершится после его закрытия, оставлять только кнопку «закрыть приложение» и не делать кнопку «закрыть окно».
Если окон несколько, никто ведь не ждет, что закрывая одно из окон, закроется вообще все приложение. Закрывается конкретно то окно, у которого была нажата кнопка. Вопрос возникает, когда «главное» окно было закрыто. Но во первых, не все приложения имеют «главные» окна, во вторых, если основная задача приложения работать в фоне, то закрытие главного окна не должно быть причиной для прекращения работы всего приложения. Если я закрыл окно торрента, это не значит, что не хочу чтобы они качались. Это значит, что я не хочу больше видеть его окно и я нажимаю его закрыть. Именно закрыть, не свернуть потому, что при сворачивании я ожидаю, что оно должно остаться на панели задач вместе с другими свернутыми окнами, а оно мне там не нужно. Я хочу его закрыть, полностью. Но чтобы торренты при этом продолжали качаться.
Иногда бывает ситуация, когда окно это не вся программа, а только вспомогательная её часть. Например вся программа сидит в трее, и что-то там делает (например, ожидает хоткеев для каких-то действий). Дваждый щелкнув по иконке в трее, я открываю окно настроек. Это единственное окно этой программы. Выставив настройки как мне надо, я нажимаю «применить», а затем закрываю окно настроек. И вот меньше всего я ожидаю, что при этом вся программа прекратит свою работу :) Да и вообще, крестик значит — закрыть окно. Вы его нажимаете, окно закрывается? Закрывается! Какое отношение закрытие окна имеет к прекращению работы программы? Тогда уже надо делать не кнопку «свернуть в трей», а кнопку «завершить программу»
У меня, в свое время, тоже была мысль сделать блокировщик, позволяющий делать SingleWrite и MultipleRead, и насколько я был рад тому что это уже сделано, настолько и разочарован, что увы, только в Висте. Подобную реализацию под XP видел, но мне в ней не понравилась одна вещь: если в потоке блокировщик уже открыт на чтение, то при открытии в нем же на запись будет дедлок. Вечное ожидание того, что количества ридеров будет равно нулю, т.к. один из ридеров и есть этот самый поток. Отчасти соглашусь, что при открытом на чтение объекте, открывать его на запись в том же потоке архитектурно неверно. Но тем не менее не хотелось бы попадать в дедлок в этой ситуации и я сделал похожую реализацию с использованием TlsSetValue и TlsGetValue чтобы записать в поток кол-ко его собственных ридеров для блокировщика и если оставшееся число открытых ридеров ему равно — то можно открывать на запись или выпадать в ассерт (мол, ты что творишь, ирод!)
С вашим примером я полностью согласен, но есть одно но: у вас идет речь об обслуживании людей, а в этом случае, действительно, недопустимо планировать свое время способом отличиным от жесткого графика работы. Кассир на кассе также не может скопить большую очередь, а потом быстро-быстро обслужить всех, или сотрудник поддержки, отвечающий на звонки, не может покинуть свое рабочее место без веской причины, т.к. не может знать, в какой момент времени могут понадобится его услуги. Но в случае же, когда человеку ставится задача, которая должна быть сделана к определенному сроку и её выполнение не завязано на других людей, то что плохого, в том, что он сам решает, в каком темпе и с какими интервалами ему работать? Чем неторопливая работа, равномерно распределяющаяся на весь период выделенного времени, лучше нескольких промежутков времени максимально сосредоточенной и эффективной работы (при условии, что качество выполненной работы в обоих случаях одинаково)?
1. Ставить свой видео-драйвер (Быстрый, но замороченный). Вроде как начиная с Vista и старше появился специальный API позволяющий также быстро получать изображения экрана, минуя установку видео-драйвера и все бы хорошо, но XP еще жива.
2. Через GDI экран копируется в память. Это медленней и грузит процессор, но на современном железе приемлемо и работает на любой версии Windows.
Дальше полученное изображение разбивается на блоки (например 32*32) и все блоки прошлого кадра сравниваются с блоками нового кадра, и те, что отличаются, сжимаются и отправляются клиенту. При медленном соединении можно еще добавить небольшой трюк: если блок был поставлен в очередь на отправку, но еще не успел улететь из-за тонкого канала, а уже еще раз поменялся, то можно не накапливать очередь, а просто обновить блок в очереди на более новый. В результате пользователь может увидеть неравномерное обновление блоками, зато какая-нибудь анимация не забъет весь канал своими бесконечными обновляемыми участками.
________МОНИТОР
МОНИТОР МОНИТОР МОНИТОР
В результате кликает не по тем координатам, по которым кликаю я. И очень не хватает выбора монитора в свойствах подключения. Чтобы можно было выбрать: показывать все или какой-то конкретно. И еще бы это сохранить. А так очень рад появлению бесплатного Радмина. Сам в свое время пытался сделать, что-то подобное (и даже сделал и пользуюсь иногда), но завяз с тем, что взаимодействие с рабочем столом пользователя сложно было сделать из под службы, а пользовательским приложением нельзя залогинится. Для скорости, кстати, использовал LZO сжатие и 4/8 бит GrayScale. 16 цветов — все выглядит ужасно, но 16 оттенков серого :) — выглядит вполне прилично и сносно работает на медленных соединениях.
— Спуститься до нижнего крюка и привязать низ веревки (50й её метр) к нижнему крюку
— Снова подняться по веревке наверх на 49,5 метров
— Обрезать веревку и пролетев 99 метров, остановиться держась за веревку в полуметре от земли
— Спрыгнуть на землю :)
Для этого достаточно всего 50м веревки, а не 75. Вероятность выживания альпиниста не 100% :)
Вот это условие как раз не факт, что соблюдается у всех электросамокатов :)
Для велосипедиста, таки, как раз надо спешиваться, т.к. вести велосипед не равно ехать не велосипеде. К тому же в там перечислены «велосипед, мопед, мотоцикл». Не думаете же вы, что мотоциклист тоже может ехать по пешеходному переходу не спешиваясь?
Для самоката да, спешиваться не обязательно, но здравый смысл подсказывает, что в ПДД подразумевается обычный самокат, средняя скорость которого 8-12 км/ч, + пешеход должен удостоверится, что его видят и пропускают, а для этого перед переходом нужно, как минимум сбавить скорость. Вылет же на переход на электросамокате на скорости 25-30 км/ч — это ИМХО злоупотребление надоработками ПДД, которое может привести к печальным последствиям.
1) Приложение которые запускаются пользователем вручную, у которых есть главное окно в котором и работает пользователь, при закрытии которого приложение обычно завершает свою работу.
2) Приложения, которые, как правило, стартуют самостоятельно, показывая лишь иконку в трее. При двойном щелчке по иконке в трее или при щелчке по одному из пунктов трей-меню приложения, оно может показывать какие-то окна. Но при их закрытии приложение не должно никуда деваться из трея.
Т.е. грубо говоря, если при запуске приложения было показано окно, то при его закрытии, приложение в 99% завершает свою работу. Если же при запуске, никаких окон показано не было, и окна появлялись уже после взаймодействия с трей-значком, то при их закрытии приложение завершать свою работу не должно.
Но бывают и исключения, например, когда пользователю не нужно приложение в автозагрузке, и при запуске оно показывает главное окно, но при его закрытии уходит в трей, т.к. является ещё и фоновым сервисом.
Во всех случаях при нажатии кнопки закрыть окно — оно закрыватся. Было ли при этом завершено приложение? А должно ли пользователя это вообще волновать? И что значит приложение было завершено? Завершен ли процесс? А что если трей-иконка и окна открытые, при нажатии на нее это разные процессы? Можно ли считать приложение завершенным, если закрывая окно, процесс их породивший завршится, при этом другой процесс того же программного продута останется висеть с иконкой в трее? А если при закрытии главного окна приложения, оно не завершается еще какое-то время, чтобы при последующем запуске не тратить время на загрузку ресурсов? Возвращаемся к изначальному вопросу: должно ли пользователя это волновать, и если у него нет проблем с производительностью ОС? ИМХО — нет.